RE: Time Stamp: Usage of TDTs

[[e-mail]]

Bill,

Ok, another question: If one day NIST will implement TSA services itself,
would I, as a client, need a TDT in the TST produced by a NIST server? I
guess no.
In general case, if a TDA can attest to the quality of time (because it
knows it better, presumably), what stops it to provide TSA services itself?
So the clients can go 'right to the source', and get a 100% guaranteed pure
time reference, instead of having to worry about secondary verification,
etc.

Waiting for replies...

Regards
MichaelZ


-----Original Message-----
From: Bill Lattin [mailto:[e-mail]]
Sent: Thursday, July 01, 1999 7:12 AM
To: [e-mail]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
[e-mail]
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: RE: Time Stamp: Usage of TDTs


Michael,

Thanks for the feedback.

Depending on the application, a client could be very interested in
"certified evidence" being located in a TST.  For example, in a currency
arbitrage or stock trade situation one coud envisage being able to prove
that a trade was placed at a certain time.  The real question is what
evidence is good enough?  Is it a contractual agreement that the local
TSA's clock is sufficently accurate and precise or is will there be a
mandate to use the clock from a National Timing Authority?

The answer is both.  We are not advocating that this type of TDT replace a
local TSA clock; both models are valid.  We just want to enable the use of
the National Timing Authority clocks since we believe that a number of
applications will insist on having time traceable to them.  As a current
example (although one for which PKIX time stamps will be too late for the
initial phases) is the NASDAQ OATS system.  This order tracking system is
required to use timing from NIST (the US' NTA).  The healthcare system in
the US is also extremely sensitive to time, and we expect that many new
applications will need to be linked to an NTA timing source rather than a
local source.

Further, I'm sure we all agree that the timeStampToken needs to be a
persistent data object.  For example, e-mail would normally be considered to
have low requirements for time-stamp trust.  However, 3 years down the road,
a given e-mail and its time of origin may be pivotal in a legal case.  If
the trust of the time in the timeStampToken can be embodied with a party in
addition to the entity possessing the TSA, the timeStampToken can better
meet the requirement to be a persistent data object.

You are right that a request of a single TDT does not guarantee future
performance from the TSA.  For applications that need traceability to NIST,
a TDT will be needed per time stamp.  This is an important extra benefit, a
TST with its own instance of a TDT can provide 'guaranteed' time independent
of the clock within the TSA.  Other applications, which are not as
sensitive, can operate as you have suggested - by agreement on policy that
the TSA is doing the right thing.

The bottom line is that the use of a TDT in this manner enables a new class
of applications which require explicit, provable traceability (with
associated audit trails) to an NTA.  The TSA operation is enhanced because
it can offer multiple types of service.

Cheers,

Bill


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, June 29, 1999 23:10
> To: [e-mail]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Time Stamp: Usage of TDTs
>
>
> Must admit it makes more sense now.
>
> However, the question is why would a TSA's client require or be generally
> interested in a "certified evidence of the TSA's diligence"?. This is what
> you propose, isn't it? Sorry if I misunderstood it.
>
> Would it be sufficient for the TSA just to claim (out of band, using legal
> policy statement or else) that it is using such and such time source(s),
> with a timePrecision field present in each TST?
>
> A client would then decide, based on the policy information (clock
> resolution, synchronization with NTA, reliability, etc), if that
> particular
> TSA is suitable for use.
>
> I can anticipate an argument that the TDT can be requested by the client
> just once, to check how good is the TSA's timing. But this does not
> guarantee that the consequent TSTs will be issued using the same clock, or
> using the same clock-to-NTA synchronisation. If this is guaranteed by the
> TSA's policy, and we are going to trust to what the policy
> promises, then as
> well we can trust the rest of it (i.e. when/if it states that the clock IS
> synchronised with NTA).
>
> Probably, there are business cases where having TDT in a time
> stamp would be
> a nice feature. Looking forward to hear more.
>
> Regards
> MichaelZ
>
>
> -----Original Message-----
> From: Bill Lattin [mailto:[e-mail]]
> Sent: Wednesday, June 30, 1999 5:21 AM
> To: [e-mail]
> Cc: Dave Robinson; Ron Holm; Mike Duren; Greg Dowd
> Subject: Time Stamp: Usage of TDTs
>
>
> All,
>
> Over the last few weeks, there has been considerable discussion
> on the need
> for TDAs and their corresponding TDTs.  Much of the debate has been on
> whether or not TDAs really add anything essential.  The heart of the issue
> is whether or not the TSA is producing suitably trusted and accurate time.
> It has been argued that if the time is accurate and trusted, then TDAs are
> redundant (de la Vega and Zolotarev) and therefore should be eliminated.
>
> Rather than use TDAs to provide secondary non-time information to
> substantiate a TST, an alternative use is for a TDT to convey traceable
> trusted time certification from a National Timing Authority (NTA) (e.g.
> NIST) to the TSAs.  Rather than conveying something indirect like stock
> market closing data, this new type of TDT could be used to show, in a
> non-repudiatable manner, that: (i) a TSA's clock is accurately
> synchronized
> to the NTA's clock ; and/or (ii) the time of creation of a TST embedding
> such a TDT is traceable to the NTA.
>
> We are working with the S/Time group to create a protocol to reliably
> distribute time from an NTA to allow lower clocks in a timing hierarchy to
> be accurately and reliably synchronized to the NTA's clock.  The result of
> this process is a digitally signed certification that a clock is properly
> synchronized to the NTA.  This certification can be embedded in a TDT to
> prove that the time in the TDT or TST comes from a clock which has been
> synchronized to an NTA.
>
> Use of a TDT in this manner accomplishes a number of things:
>
> 1.  It directly enhances the quality of the TST by providing both
> a link to
> UTC and traceability to NIST (or appropriate NTA);
> 2.  It can be used to synchronize multiple TSA's to an NTA so
> that the TSAs
> can produce timestamps per NIST UTC (for instance) rather than their local
> clock.
> 3.  It will aid certain electronic commerce implementations since
> the TSA's
> clock can be shown to be directly traceable to an NTA.
>
> Thus, we urge the group not to abandon TDAs and TDTs, but to consider an
> alternative use for them that would contribute additional,
> directly relevant
> timing information to enhance the operation of the TSA and the quality of
> its TSTs.
>
> Regards,
>
> Bill
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA19543; Wed, 30 Jun 1999 17:22:24 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 30 Jun 1999 17:22:17 -0700
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA19512 for <[e-mail]>; Wed, 30 Jun 1999 17:21:50 -0700 (PDT)
From: [e-mail]
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA00561; Thu, 1 Jul 1999 10:25:28 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <N40L2793>; Thu, 1 Jul 1999 10:22:34 +1000
Message-ID: <[e-mail]>
To: [e-mail], "Denis.Pinkas"[[e-mail]], [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Time Stamp:  Usage of TDTs
Date: Thu, 1 Jul 1999 10:22:33 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 68bd9851ff3f3885e434c613a2cb982d

Bill,

Ok, another question: If one day NIST will implement TSA services itself,
would I, as a client, need a TDT in the TST produced by a NIST server? I
guess no.
In general case, if a TDA can attest to the quality of time (because it
knows it better, presumably), what stops it to provide TSA services itself?
So the clients can go 'right to the source', and get a 100% guaranteed pure
time reference, instead of having to worry about secondary verification,
etc.

Waiting for replies...

Regards
MichaelZ


-----Original Message-----
From: Bill Lattin [mailto:[e-mail]]
Sent: Thursday, July 01, 1999 7:12 AM
To: [e-mail]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
[e-mail]
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: RE: Time Stamp: Usage of TDTs


Michael,

Thanks for the feedback.

Depending on the application, a client could be very interested in
"certified evidence" being located in a TST.  For example, in a currency
arbitrage or stock trade situation one coud envisage being able to prove
that a trade was placed at a certain time.  The real question is what
evidence is good enough?  Is it a contractual agreement that the local
TSA's clock is sufficently accurate and precise or is will there be a
mandate to use the clock from a National Timing Authority?

The answer is both.  We are not advocating that this type of TDT replace a
local TSA clock; both models are valid.  We just want to enable the use of
the National Timing Authority clocks since we believe that a number of
applications will insist on having time traceable to them.  As a current
example (although one for which PKIX time stamps will be too late for the
initial phases) is the NASDAQ OATS system.  This order tracking system is
required to use timing from NIST (the US' NTA).  The healthcare system in
the US is also extremely sensitive to time, and we expect that many new
applications will need to be linked to an NTA timing source rather than a
local source.

Further, I'm sure we all agree that the timeStampToken needs to be a
persistent data object.  For example, e-mail would normally be considered to
have low requirements for time-stamp trust.  However, 3 years down the road,
a given e-mail and its time of origin may be pivotal in a legal case.  If
the trust of the time in the timeStampToken can be embodied with a party in
addition to the entity possessing the TSA, the timeStampToken can better
meet the requirement to be a persistent data object.

You are right that a request of a single TDT does not guarantee future
performance from the TSA.  For applications that need traceability to NIST,
a TDT will be needed per time stamp.  This is an important extra benefit, a
TST with its own instance of a TDT can provide 'guaranteed' time independent
of the clock within the TSA.  Other applications, which are not as
sensitive, can operate as you have suggested - by agreement on policy that
the TSA is doing the right thing.

The bottom line is that the use of a TDT in this manner enables a new class
of applications which require explicit, provable traceability (with
associated audit trails) to an NTA.  The TSA operation is enhanced because
it can offer multiple types of service.

Cheers,

Bill


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, June 29, 1999 23:10
> To: [e-mail]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Time Stamp: Usage of TDTs
>
>
> Must admit it makes more sense now.
>
> However, the question is why would a TSA's client require or be generally
> interested in a "certified evidence of the TSA's diligence"?. This is what
> you propose, isn't it? Sorry if I misunderstood it.
>
> Would it be sufficient for the TSA just to claim (out of band, using legal
> policy statement or else) that it is using such and such time source(s),
> with a timePrecision field present in each TST?
>
> A client would then decide, based on the policy information (clock
> resolution, synchronization with NTA, reliability, etc), if that
> particular
> TSA is suitable for use.
>
> I can anticipate an argument that the TDT can be requested by the client
> just once, to check how good is the TSA's timing. But this does not
> guarantee that the consequent TSTs will be issued using the same clock, or
> using the same clock-to-NTA synchronisation. If this is guaranteed by the
> TSA's policy, and we are going to trust to what the policy
> promises, then as
> well we can trust the rest of it (i.e. when/if it states that the clock IS
> synchronised with NTA).
>
> Probably, there are business cases where having TDT in a time
> stamp would be
> a nice feature. Looking forward to hear more.
>
> Regards
> MichaelZ
>
>
> -----Original Message-----
> From: Bill Lattin [mailto:[e-mail]]
> Sent: Wednesday, June 30, 1999 5:21 AM
> To: [e-mail]
> Cc: Dave Robinson; Ron Holm; Mike Duren; Greg Dowd
> Subject: Time Stamp: Usage of TDTs
>
>
> All,
>
> Over the last few weeks, there has been considerable discussion
> on the need
> for TDAs and their corresponding TDTs.  Much of the debate has been on
> whether or not TDAs really add anything essential.  The heart of the issue
> is whether or not the TSA is producing suitably trusted and accurate time.
> It has been argued that if the time is accurate and trusted, then TDAs are
> redundant (de la Vega and Zolotarev) and therefore should be eliminated.
>
> Rather than use TDAs to provide secondary non-time information to
> substantiate a TST, an alternative use is for a TDT to convey traceable
> trusted time certification from a National Timing Authority (NTA) (e.g.
> NIST) to the TSAs.  Rather than conveying something indirect like stock
> market closing data, this new type of TDT could be used to show, in a
> non-repudiatable manner, that: (i) a TSA's clock is accurately
> synchronized
> to the NTA's clock ; and/or (ii) the time of creation of a TST embedding
> such a TDT is traceable to the NTA.
>
> We are working with the S/Time group to create a protocol to reliably
> distribute time from an NTA to allow lower clocks in a timing hierarchy to
> be accurately and reliably synchronized to the NTA's clock.  The result of
> this process is a digitally signed certification that a clock is properly
> synchronized to the NTA.  This certification can be embedded in a TDT to
> prove that the time in the TDT or TST comes from a clock which has been
> synchronized to an NTA.
>
> Use of a TDT in this manner accomplishes a number of things:
>
> 1.  It directly enhances the quality of the TST by providing both
> a link to
> UTC and traceability to NIST (or appropriate NTA);
> 2.  It can be used to synchronize multiple TSA's to an NTA so
> that the TSAs
> can produce timestamps per NIST UTC (for instance) rather than their local
> clock.
> 3.  It will aid certain electronic commerce implementations since
> the TSA's
> clock can be shown to be directly traceable to an NTA.
>
> Thus, we urge the group not to abandon TDAs and TDTs, but to consider an
> alternative use for them that would contribute additional,
> directly relevant
> timing information to enhance the operation of the TSA and the quality of
> its TSTs.
>
> Regards,
>
> Bill
>


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA17672; Wed, 30 Jun 1999 14:10:12 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 30 Jun 1999 14:09:22 -0700
Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17627 for <[e-mail]>; Wed, 30 Jun 1999 14:09:21 -0700 (PDT)
Received: from lattin (1Cust221.tnt20.sfo3.da.uu.net [208.254.224.221]) by avocet.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id OAA24504; Wed, 30 Jun 1999 14:12:36 -0700 (PDT)
From: "Bill Lattin" <[e-mail]>
To: <[e-mail]>, <"Denis.Pinkas[Denis.Pinkas"@bull.net]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Time Stamp:  Usage of TDTs
Date: Wed, 30 Jun 1999 14:11:59 -0700
Message-ID: <001601bec33d$30fcfc60$25e6fed0@lattin>
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.2106.4
Importance: Normal
In-Reply-To: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: fcb7c1b8a8a2c3c8354bc345bf2d0a59

Michael,

Thanks for the feedback.

Depending on the application, a client could be very interested in
"certified evidence" being located in a TST.  For example, in a currency
arbitrage or stock trade situation one coud envisage being able to prove
that a trade was placed at a certain time.  The real question is what
evidence is good enough?  Is it a contractual agreement that the local
TSA's clock is sufficently accurate and precise or is will there be a
mandate to use the clock from a National Timing Authority?

The answer is both.  We are not advocating that this type of TDT replace a
local TSA clock; both models are valid.  We just want to enable the use of
the National Timing Authority clocks since we believe that a number of
applications will insist on having time traceable to them.  As a current
example (although one for which PKIX time stamps will be too late for the
initial phases) is the NASDAQ OATS system.  This order tracking system is
required to use timing from NIST (the US' NTA).  The healthcare system in
the US is also extremely sensitive to time, and we expect that many new
applications will need to be linked to an NTA timing source rather than a
local source.

Further, I'm sure we all agree that the timeStampToken needs to be a
persistent data object.  For example, e-mail would normally be considered to
have low requirements for time-stamp trust.  However, 3 years down the road,
a given e-mail and its time of origin may be pivotal in a legal case.  If
the trust of the time in the timeStampToken can be embodied with a party in
addition to the entity possessing the TSA, the timeStampToken can better
meet the requirement to be a persistent data object.

You are right that a request of a single TDT does not guarantee future
performance from the TSA.  For applications that need traceability to NIST,
a TDT will be needed per time stamp.  This is an important extra benefit, a
TST with its own instance of a TDT can provide 'guaranteed' time independent
of the clock within the TSA.  Other applications, which are not as
sensitive, can operate as you have suggested - by agreement on policy that
the TSA is doing the right thing.

The bottom line is that the use of a TDT in this manner enables a new class
of applications which require explicit, provable traceability (with
associated audit trails) to an NTA.  The TSA operation is enhanced because
it can offer multiple types of service.

Cheers,

Bill


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, June 29, 1999 23:10
> To: [e-mail]; "Denis.Pinkas[Denis.Pinkas"@bull.net];
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Time Stamp: Usage of TDTs
>
>
> Must admit it makes more sense now.
>
> However, the question is why would a TSA's client require or be generally
> interested in a "certified evidence of the TSA's diligence"?. This is what
> you propose, isn't it? Sorry if I misunderstood it.
>
> Would it be sufficient for the TSA just to claim (out of band, using legal
> policy statement or else) that it is using such and such time source(s),
> with a timePrecision field present in each TST?
>
> A client would then decide, based on the policy information (clock
> resolution, synchronization with NTA, reliability, etc), if that
> particular
> TSA is suitable for use.
>
> I can anticipate an argument that the TDT can be requested by the client
> just once, to check how good is the TSA's timing. But this does not
> guarantee that the consequent TSTs will be issued using the same clock, or
> using the same clock-to-NTA synchronisation. If this is guaranteed by the
> TSA's policy, and we are going to trust to what the policy
> promises, then as
> well we can trust the rest of it (i.e. when/if it states that the clock IS
> synchronised with NTA).
>
> Probably, there are business cases where having TDT in a time
> stamp would be
> a nice feature. Looking forward to hear more.
>
> Regards
> MichaelZ
>
>
> -----Original Message-----
> From: Bill Lattin [mailto:[e-mail]]
> Sent: Wednesday, June 30, 1999 5:21 AM
> To: [e-mail]
> Cc: Dave Robinson; Ron Holm; Mike Duren; Greg Dowd
> Subject: Time Stamp: Usage of TDTs
>
>
> All,
>
> Over the last few weeks, there has been considerable discussion
> on the need
> for TDAs and their corresponding TDTs.  Much of the debate has been on
> whether or not TDAs really add anything essential.  The heart of the issue
> is whether or not the TSA is producing suitably trusted and accurate time.
> It has been argued that if the time is accurate and trusted, then TDAs are
> redundant (de la Vega and Zolotarev) and therefore should be eliminated.
>
> Rather than use TDAs to provide secondary non-time information to
> substantiate a TST, an alternative use is for a TDT to convey traceable
> trusted time certification from a National Timing Authority (NTA) (e.g.
> NIST) to the TSAs.  Rather than conveying something indirect like stock
> market closing data, this new type of TDT could be used to show, in a
> non-repudiatable manner, that: (i) a TSA's clock is accurately
> synchronized
> to the NTA's clock ; and/or (ii) the time of creation of a TST embedding
> such a TDT is traceable to the NTA.
>
> We are working with the S/Time group to create a protocol to reliably
> distribute time from an NTA to allow lower clocks in a timing hierarchy to
> be accurately and reliably synchronized to the NTA's clock.  The result of
> this process is a digitally signed certification that a clock is properly
> synchronized to the NTA.  This certification can be embedded in a TDT to
> prove that the time in the TDT or TST comes from a clock which has been
> synchronized to an NTA.
>
> Use of a TDT in this manner accomplishes a number of things:
>
> 1.  It directly enhances the quality of the TST by providing both
> a link to
> UTC and traceability to NIST (or appropriate NTA);
> 2.  It can be used to synchronize multiple TSA's to an NTA so
> that the TSAs
> can produce timestamps per NIST UTC (for instance) rather than their local
> clock.
> 3.  It will aid certain electronic commerce implementations since
> the TSA's
> clock can be shown to be directly traceable to an NTA.
>
> Thus, we urge the group not to abandon TDAs and TDTs, but to consider an
> alternative use for them that would contribute additional,
> directly relevant
> timing information to enhance the operation of the TSA and the quality of
> its TSTs.
>
> Regards,
>
> Bill
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA04037; Wed, 30 Jun 1999 04:04:41 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 30 Jun 1999 04:04:33 -0700
Received: from irwell.zetnet.co.uk ([e-mail] [194.247.47.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA04015 for <[e-mail]>; Wed, 30 Jun 1999 04:04:32 -0700 (PDT)
Received: from dwc-acer (manr-058.dialup.zetnet.co.uk [194.247.43.188]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA20641; Wed, 30 Jun 1999 12:07:46 +0100
Message-Id: <[e-mail]>
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: Stefan Santesson <[e-mail]>, [e-mail]
Date: Wed, 30 Jun 1999 12:11:26 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Use of localityName attribute
Reply-to: [e-mail]
Priority: normal
In-reply-to: <[e-mail]>
References: <v04020a09b39070b60562@[128.89.0.110]>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 700bdd186ed2d8db26cafd81a32c9b71

Stefan,

I need to request a change to the qualified certificate draft to allow 
the use of the localityName attribute to be used to unambiguously 
identify a subject and issuer in a DN. The UK National Health 
Service Standard for Directory Services requires the use of locality 
name to unambiguously identify different organisational units within 
the NHS. For example, there are literally dozens of St Mary's 
Hospitals within the UK NHS, so that O and OU are insufficient as 
differentiators. Consequently localityName, based on the UK Post 
Office defined localities, is used to differentiate between them (we 
do not use the full postal address as this is too cumbersome.)

As the QC draft stands at the moment, (as I read it), the use of 
localityName as currently defined by the NHS would not be allowed 
as a differentiator.

The offending sections are:

3.1.1 Issuer -  allows for state or province name but not for 
localityName. We request that localityName be added to this section.

3.1.2 Subject - allows postalAddress but not localityName and states 
"Other attributes may be present but MUST NOT be necessary to 
distinguish the subject name from other subject names within the 
issuer domain."

This effectively precludes localityName from being used to 
unambiguously differentiate between hospital. We request that 
localityName be added to the MAY list.

Regards
David

***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
*NEW* Mobile [phone] *NEW*
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA17028; Tue, 29 Jun 1999 23:08:56 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 23:08:53 -0700
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA16957 for <[e-mail]>; Tue, 29 Jun 1999 23:08:41 -0700 (PDT)
From: [e-mail]
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id QAA23725; Wed, 30 Jun 1999 16:12:59 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <N40L27G7>; Wed, 30 Jun 1999 16:10:02 +1000
Message-ID: <[e-mail]>
To: [e-mail], Denis.Pinkas[[e-mail]], [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Time Stamp:  Usage of TDTs
Date: Wed, 30 Jun 1999 16:10:01 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 8a73a3fdb8e549db9dadd482910a4cd6

Must admit it makes more sense now.

However, the question is why would a TSA's client require or be generally
interested in a "certified evidence of the TSA's diligence"?. This is what
you propose, isn't it? Sorry if I misunderstood it.

Would it be sufficient for the TSA just to claim (out of band, using legal
policy statement or else) that it is using such and such time source(s),
with a timePrecision field present in each TST?

A client would then decide, based on the policy information (clock
resolution, synchronization with NTA, reliability, etc), if that particular
TSA is suitable for use.

I can anticipate an argument that the TDT can be requested by the client
just once, to check how good is the TSA's timing. But this does not
guarantee that the consequent TSTs will be issued using the same clock, or
using the same clock-to-NTA synchronisation. If this is guaranteed by the
TSA's policy, and we are going to trust to what the policy promises, then as
well we can trust the rest of it (i.e. when/if it states that the clock IS
synchronised with NTA).

Probably, there are business cases where having TDT in a time stamp would be
a nice feature. Looking forward to hear more.

Regards
MichaelZ
 

-----Original Message-----
From: Bill Lattin [mailto:[e-mail]]
Sent: Wednesday, June 30, 1999 5:21 AM
To: [e-mail]
Cc: Dave Robinson; Ron Holm; Mike Duren; Greg Dowd
Subject: Time Stamp: Usage of TDTs


All,

Over the last few weeks, there has been considerable discussion on the need
for TDAs and their corresponding TDTs.  Much of the debate has been on
whether or not TDAs really add anything essential.  The heart of the issue
is whether or not the TSA is producing suitably trusted and accurate time.
It has been argued that if the time is accurate and trusted, then TDAs are
redundant (de la Vega and Zolotarev) and therefore should be eliminated.

Rather than use TDAs to provide secondary non-time information to
substantiate a TST, an alternative use is for a TDT to convey traceable
trusted time certification from a National Timing Authority (NTA) (e.g.
NIST) to the TSAs.  Rather than conveying something indirect like stock
market closing data, this new type of TDT could be used to show, in a
non-repudiatable manner, that: (i) a TSA's clock is accurately synchronized
to the NTA's clock ; and/or (ii) the time of creation of a TST embedding
such a TDT is traceable to the NTA.

We are working with the S/Time group to create a protocol to reliably
distribute time from an NTA to allow lower clocks in a timing hierarchy to
be accurately and reliably synchronized to the NTA's clock.  The result of
this process is a digitally signed certification that a clock is properly
synchronized to the NTA.  This certification can be embedded in a TDT to
prove that the time in the TDT or TST comes from a clock which has been
synchronized to an NTA.

Use of a TDT in this manner accomplishes a number of things:

1.  It directly enhances the quality of the TST by providing both a link to
UTC and traceability to NIST (or appropriate NTA);
2.  It can be used to synchronize multiple TSA's to an NTA so that the TSAs
can produce timestamps per NIST UTC (for instance) rather than their local
clock.
3.  It will aid certain electronic commerce implementations since the TSA's
clock can be shown to be directly traceable to an NTA.

Thus, we urge the group not to abandon TDAs and TDTs, but to consider an
alternative use for them that would contribute additional, directly relevant
timing information to enhance the operation of the TSA and the quality of
its TSTs.

Regards,

Bill


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA02646; Tue, 29 Jun 1999 20:31:12 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 20:31:06 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA02623; Tue, 29 Jun 1999 20:31:05 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Tue, 29 Jun 1999 20:33:53 -0700
To: "Aram Perez" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 91d80fcf032ba33762bf41165b537642

At 07:21 PM 6/29/1999 -0700, Aram Perez wrote:
> > It has the public key of the server built-in without a cert. Remember, you
> > don't need certs for root keys.
>
>How do you plan to handle a comprised private key?

In the same method you got the bare key: out of band. If the client can't 
parse a cert, it probably can't parse a CRL.


--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA15723; Tue, 29 Jun 1999 19:18:27 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 19:18:19 -0700
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 TAA15681 for <[e-mail]>; Tue, 29 Jun 1999 19:18:19 -0700 (PDT)
Received: from mailgate1.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 TAA53308 for <[e-mail]>; Tue, 29 Jun 1999 19:21:54 -0700
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 29 Jun 1999 19:21:52 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id TAA15846 for <[e-mail]>; Tue, 29 Jun 1999 19:21:50 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 29 Jun 1999 19:21:51 -0700
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 4f066f2d5051a37dbbf1f0b81871b777

Hi Paul,

> At 06:24 PM 6/28/1999 -0700, Aram Perez wrote:
>>1) I like the idea of SCVP but if the SCVP response is signed, how does the
>>client verify the signature if it can't handle certs?
>
> It has the public key of the server built-in without a cert. Remember, you
> don't need certs for root keys.

How do you plan to handle a comprised private key?

Thanks,
Aram Perez


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA07470; Tue, 29 Jun 1999 16:03:34 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 16:03:30 -0700
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA07448 for <[e-mail]>; Tue, 29 Jun 1999 16:03:30 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id QAA16597 for <[e-mail]>; Tue, 29 Jun 1999 16:05:21 -0700 (PDT)
Received: from rhone (dhcp-3-128.engineering.valicert.com [192.168.3.128] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id QAA05423 for <[e-mail]>; Tue, 29 Jun 1999 16:06:35 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Tue, 29 Jun 1999 16:09:26 -0700
Message-ID: <003c01bec284$6f852160$[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]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 42885f449a308df8902983a037a34197

I had thought about using CMS for the ASN.1 encoding and the main
reason for avoiding that, was to allow both the tiny and the ASN.1
syntax to match each other closely.

Ambarish

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


> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: Monday, June 28, 1999 7:46 PM
> To: [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> At 12:27 PM 6/29/1999 +1000, [e-mail] wrote:
> >Hardcoded SHA-1:
> >Why not to use the X509 AlgorithmIdentifier?
> 
> Because there are two syntaxes, one of which is not ASN.1. If 
> folks see a 
> need for the additional complexity, we could put in a hash 
> identifier that 
> might look like that in the ASN.1 syntax.
> 
> But I still don't think it's all that necessary. Why make a 
> simple client 
> know two methods of hashing? Is there a real value to that? 
> If there are 
> multiple hash algorithms, clients will be expected to know 
> all of them (so 
> they can use an arbitrary server), which leads to code bloat. 
> Are we really 
> that nervous about SHA-1?
> 
> >Request/Response signatures:
> >Could the PKCS#7 encapsulation be used for the request and response?
> 
> For the ASN.1 syntax, yes; for the tiny syntax, absolutely 
> not. But CMS 
> doesn't really add much, and there's no reason to expect 
> clients to be 
> CMS-aware.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 
> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA04063; Tue, 29 Jun 1999 14:33:23 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 14:33:19 -0700
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA04017 for <[e-mail]>; Tue, 29 Jun 1999 14:33:18 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id RAA10015 for <[e-mail]>; Tue, 29 Jun 1999 17:35:52 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 29 Jun 1999 17:33:52 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.6 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: Processing of maximum in NameConstraints??
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: a8e77be188d9ae29ba50038f90ff4e0c

All,

I'm trying to figure out whether RFC 2459 compliant applications will
support processing maximum in NameConstraints.  The generation
requirements are very explicit (i.e., omit it), but I'm not sure if a
'compliant' application has to (i.e., MUST) support processing it.

Thoughts/Comments?

spt



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA00159; Tue, 29 Jun 1999 12:18:31 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 12:18:22 -0700
Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00130 for <[e-mail]>; Tue, 29 Jun 1999 12:18:22 -0700 (PDT)
Received: from lattin (1Cust108.tnt2.sfo3.da.uu.net [153.37.7.108]) by harrier.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id MAA19834; Tue, 29 Jun 1999 12:21:45 -0700 (PDT)
From: "Bill Lattin" <[e-mail]>
To: <[e-mail]>
Cc: "Dave Robinson" <[e-mail]>, "Ron Holm" <[e-mail]>, "Mike Duren" <[e-mail]>, "Greg Dowd" <[e-mail]>
Subject: Time Stamp:  Usage of TDTs
Date: Tue, 29 Jun 1999 12:21:10 -0700
Message-ID: <000b01bec264$8b7cc280$38072599@lattin>
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.2106.4
Importance: Normal
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 183bc272686085a695507c2db09664b3

All,

Over the last few weeks, there has been considerable discussion on the need
for TDAs and their corresponding TDTs.  Much of the debate has been on
whether or not TDAs really add anything essential.  The heart of the issue
is whether or not the TSA is producing suitably trusted and accurate time.
It has been argued that if the time is accurate and trusted, then TDAs are
redundant (de la Vega and Zolotarev) and therefore should be eliminated.

Rather than use TDAs to provide secondary non-time information to
substantiate a TST, an alternative use is for a TDT to convey traceable
trusted time certification from a National Timing Authority (NTA) (e.g.
NIST) to the TSAs.  Rather than conveying something indirect like stock
market closing data, this new type of TDT could be used to show, in a
non-repudiatable manner, that: (i) a TSA's clock is accurately synchronized
to the NTA's clock ; and/or (ii) the time of creation of a TST embedding
such a TDT is traceable to the NTA.

We are working with the S/Time group to create a protocol to reliably
distribute time from an NTA to allow lower clocks in a timing hierarchy to
be accurately and reliably synchronized to the NTA's clock.  The result of
this process is a digitally signed certification that a clock is properly
synchronized to the NTA.  This certification can be embedded in a TDT to
prove that the time in the TDT or TST comes from a clock which has been
synchronized to an NTA.

Use of a TDT in this manner accomplishes a number of things:

1.  It directly enhances the quality of the TST by providing both a link to
UTC and traceability to NIST (or appropriate NTA);
2.  It can be used to synchronize multiple TSA's to an NTA so that the TSAs
can produce timestamps per NIST UTC (for instance) rather than their local
clock.
3.  It will aid certain electronic commerce implementations since the TSA's
clock can be shown to be directly traceable to an NTA.

Thus, we urge the group not to abandon TDAs and TDTs, but to consider an
alternative use for them that would contribute additional, directly relevant
timing information to enhance the operation of the TSA and the quality of
its TSTs.

Regards,

Bill



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA27649; Tue, 29 Jun 1999 10:51:51 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 10:51:49 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA27625; Tue, 29 Jun 1999 10:51:29 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Tue, 29 Jun 1999 10:48:17 -0700
To: Carlisle Adams <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Cc: [e-mail]
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 10bed52d807af09e0cb6e37d55450648

At 10:25 AM 6/29/1999 -0400, Carlisle Adams wrote:
>Quite true, if you expect the key to live forever and to be unfettered with
>all those annoying policies, CPSs, key usages, key identifiers, and so on.

Not so. When the server's key is installed in the client, any of those 
could be hard-wired in, just as they are (or aren't) when you install root 
certificates. They just don't have to be wrapped in a formal certificate.

Which is not to say that they can't be. If the client understands certs, 
the interface for that client might only allow the installation of a root 
key which comes in a self-signed cert, and that installation might act on 
all the parameters. That's a perfectly reasonable way to get the server's 
public key. But it is not required for the very simple reason that many 
SCVP clients cannot even parse a cert, much less interpret it.

>If there is value in constraining the use and power of this key in any way
>whatsoever (and there typically is), the utility of a self-signed cert
>really becomes apparent.

You mean *that's* what we've been talking about on this mailing list?! :-)

If you want to exclude clients that can't interpret certs from SCVP, then 
there is little value to SCVP other than to aid some clients do 
chain-building. The purpose of SCVP, as stated in the intro, is to help 
clients that can use public keys, but not PKIX certs, to get value out of 
PKIX certs. Without SCVP, the makers of these clients might need to invent 
yet another cert format that is easier to parse and interpret; that would 
hurt the whole PKIX market.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA26327; Tue, 29 Jun 1999 09:52:39 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 09:52:27 -0700
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA26303 for <[e-mail]>; Tue, 29 Jun 1999 09:52:13 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA09927 for <[e-mail]>; Tue, 29 Jun 1999 12:55:33 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA09891 for <[e-mail]>; Tue, 29 Jun 1999 12:55:27 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id MAA03855 for <[e-mail]>; Tue, 29 Jun 1999 12:55:29 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id MAA00856 for <[e-mail]>; Tue, 29 Jun 1999 12:52:11 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 29 Jun 1999 12:52:11 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 73rYCcIKm5XGU/brUtglRQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 13aa2c5f67f23edaa68e1c04b5ff06dc
Status: O
X-Status:

> From: "Aram Perez" <[e-mail]>
>
> >>2) Section 3.20 states "The CertID item has an identifier for the type of
> >>certificate and the SHA-1 [SHA-1] hash of the octets of the certificate
> >>itself." While I agree with specifying SHA-1 to *identify the certs*, I
> >>recently got beat up on this mailing list because IETF is always supposed to
> >>allow algorithm independence ;-)
> >
> > Not always. There is a tradeoff of multiple algorithms for safety (in case
> > SHA-1 gets broken) versus complexity (having to include another identifier
> > and having clients understand it). What do others think here? I hard-coded
> > SHA-1 for simplicity.
> 
> Believe me, I agree with specifying just one algorithm for simplicity (and
> interoperability) sake. It's just that I wanted someone else to get beat up
> like I was ;-)

In this case I believe simplicity should win.  Algorithm agility is good
where there are actual or potential tradeoffs between algorithms.  But I don't
see any tradeoffs in this case.

Implementation complexity: at least one algorithm must be mandatory for
interoperability, so even if SHA-1 is "broken", support for it must be
continued.  If it were acceptable to break backwards compatibility to
designate a different mandatory algorithm, it would also be acceptable to
designate a different hard-coded algorithm.

Security: A hash used as a cert identifier should uniquely identify a
certificate.  Cryptographic advances may someday "break" SHA-1 by making
it computationally easier to find colliding inputs, but they will not change
the values of those inputs; two octet strings which have different SHA-1
hashes today will not suddenly have the same SHA-1 hash tomorrow.  I'll
start to worry when there are 2^80 meaningful certificates in the
universe.



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA26876; Tue, 29 Jun 1999 10:12:54 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 10:12:53 -0700
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 KAA26854 for <[e-mail]>; Tue, 29 Jun 1999 10:12:53 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA65754 for <[e-mail]>; Tue, 29 Jun 1999 10:16:26 -0700
Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (mailgate2.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 29 Jun 1999 10:16:17 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id KAA36564 for <[e-mail]>; Tue, 29 Jun 1999 10:16:16 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 29 Jun 1999 10:16:16 -0700
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: d3f8dcd6eb34338969d06568527d67f9
Status: O
X-Status:

Hi Dave,

> 
>> From: "Aram Perez" <[e-mail]>
>>
>> >>2) Section 3.20 states "The CertID item has an identifier for the type of
>> >>certificate and the SHA-1 [SHA-1] hash of the octets of the certificate
>> >>itself." While I agree with specifying SHA-1 to *identify the certs*, I
>> >>recently got beat up on this mailing list because IETF is always supposed
to
>> >>allow algorithm independence ;-)
>> >
>> > Not always. There is a tradeoff of multiple algorithms for safety (in case
>> > SHA-1 gets broken) versus complexity (having to include another identifier
>> > and having clients understand it). What do others think here? I hard-coded
>> > SHA-1 for simplicity.
>>
>> Believe me, I agree with specifying just one algorithm for simplicity (and
>> interoperability) sake. It's just that I wanted someone else to get beat up
>> like I was ;-)
>
> In this case I believe simplicity should win.  Algorithm agility is good
> where there are actual or potential tradeoffs between algorithms.  But I don't
> see any tradeoffs in this case.

This was precisely the point I was trying to make earlier. Where were you
when I was getting beat up ;-)

Regards,
Aram Perez


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA23374; Tue, 29 Jun 1999 07:23:27 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 07:23:16 -0700
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 HAA23340; Tue, 29 Jun 1999 07:23:15 -0700 (PDT)
Received: 	id KAA11070; Tue, 29 Jun 1999 10:23:22 -0400
Received: by gateway id <NP65DSYG>; Tue, 29 Jun 1999 10:25:49 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Tue, 29 Jun 1999 10:25:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 8bcf8fe3981a13a1b6ede1aa748a6bfe

Hi Paul,

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[e-mail]]
> Sent: 	Monday, June 28, 1999 9:49 PM
> To: 	[e-mail]
> Subject: 	Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> At 06:24 PM 6/28/1999 -0700, Aram Perez wrote:
> >1) I like the idea of SCVP but if the SCVP response is signed, how does
> the
> >client verify the signature if it can't handle certs?
> 
> It has the public key of the server built-in without a cert. Remember, you
> 
> don't need certs for root keys.
 
Quite true, if you expect the key to live forever and to be unfettered with
all those annoying policies, CPSs, key usages, key identifiers, and so on.

If there is value in constraining the use and power of this key in any way
whatsoever (and there typically is), the utility of a self-signed cert
really becomes apparent.

Just a thought...

Carlisle.



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA18720; Tue, 29 Jun 1999 04:04:18 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 04:02:47 -0700
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA18670 for <[e-mail]>; Tue, 29 Jun 1999 04:02:46 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA04575 for <[e-mail]>; Tue, 29 Jun 1999 13:06:16 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 29 Jun 1999 13:06:15 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA22198 for <[e-mail]>; Tue, 29 Jun 1999 13:06:14 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA07510 for [e-mail]; Tue, 29 Jun 1999 13:06:14 +0200 (MET DST)
Date: Tue, 29 Jun 1999 13:06:14 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: draft-ietf-pkix-dcs-01.txt
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 04d632d690b672d0401a144a60b2f562

Hello,

A new version of dcs draft is available under

  ftp://ftp.edelweb.fr/pub/dcs/draft-ietf-pkix-dcs-01.txt

This draft had been created by me in agreement with 
Robert Zuccerato, the author of the 00 version.

Comments are welcome as usual.

Peter Sylvester


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA20229; Tue, 29 Jun 1999 05:11:16 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 05:11:03 -0700
Received: from mystic.trustcenter.de (mystic.trustcenter.de [194.64.226.89]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20193 for <[e-mail]>; Tue, 29 Jun 1999 05:11:02 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 29 Jun 1999 14:12:55 +0200
To: [e-mail]
From: Juergen Brauckmann <[e-mail]>
Subject: AuthorityKeyIdentifier in RFC2459
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 1d937acb551c19bffe18d1459ea2dd6e

Hi.

The Authority Key Identifier section in RFC2459 is:

4.2.1.1  Authority Key Identifier

   The authority key identifier extension provides a means of
   identifying the public key corresponding to the private key used to
   sign a certificate. This extension is used where an issuer has
   multiple signing keys (either due to multiple concurrent key pairs or
   due to changeover).  The identification may be based on either the
   key identifier (the subject key identifier in the issuer's
   certificate) or on the issuer name and serial number.

I feel that the last sentence is confusing, since it sounds as if you may
include the issuer name of the certificate containing the AKI (=the subject
DN of the issuer certificate) together with the issuers serial number.
According to X.509 from 1997 you have to include the issuer name of the
issuer certificate of the certificate including the AKI:
"The key may be identified..., by identification of a certificate for the
key (giving certificate issuer ... and certificate serial number...) ...."

I know at least one profile profiling the pkix profile that gets it wrong;
perhaps it's worth the effort to change it in the next version of RFC2459? 

Regards,
   Juergen
-- 
Juergen Brauckmann             Tel.:  040 / 766 29 2708
TC Trust Center for Security   Fax.:  040 / 766 29 577
in Data Networks GmbH 	    mailto:[e-mail]
Am Werder 1    		    http://www.trustcenter.de	
21073 Hamburg


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA21726; Tue, 29 Jun 1999 06:14:46 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 29 Jun 1999 06:12:34 -0700
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21654 for <[e-mail]>; Tue, 29 Jun 1999 06:12:34 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA07440 for <[e-mail]>; Tue, 29 Jun 1999 15:16:04 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 29 Jun 1999 15:16:02 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA24216 for <[e-mail]>; Tue, 29 Jun 1999 15:16:01 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA07589 for [e-mail]; Tue, 29 Jun 1999 15:16:01 +0200 (MET DST)
Date: Tue, 29 Jun 1999 15:16:01 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: draft-ietf-pkix-dcs-01.txt (cont)
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b924c7dffe3f7f2bdbca3e29822a57cc

I apologize for having missed the deadline for
the next meeting. Thus, the announced draft will
will not appear before July 12 in the ietf draft
directory. 

No permanent harm will occur to you if you ignore
the document during the next two weeks. 

Peter Sylvester


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA18542; Mon, 28 Jun 1999 20:18:25 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Jun 1999 20:18:24 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA18520 for <[e-mail]>; Mon, 28 Jun 1999 20:18:23 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Mon, 28 Jun 1999 20:16:57 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b3bea11a81e3bdbc248ef69ce02f9fb5

At 08:07 PM 6/28/1999 -0700, Aram Perez wrote:
> > It has the public key of the server built-in without a cert. Remember, you
> > don't need certs for root keys.
>
>This is fine but implies a limited number of SCVP servers.

A limited number that the client trusts. Absolutely. You aren't going to 
trust just anyone. Our expectation is that a typical client might trust one 
or two servers at a time. Of course, there's nothing in the protocol that 
limits the client to this.

>Believe me, I agree with specifying just one algorithm for simplicity (and
>interoperability) sake. It's just that I wanted someone else to get beat up
>like I was ;-)

We're open to such beating, and changing if necessary.

> >>4) Section 3.19 RequestSignature, 2nd paragraph. I would suggest rewording
> >>it as "Requests MUST include a RequestSignature item unless the request is
> >>done over an authenticated channel, such as..."
> >
> > That wording is equivalent to what we have, I think. I prefer SHOULD to
> > "MUST with exceptions" as a stylistic choice.
>
>I don't think that it is equivalent. With the original wording I can send an
>unsigned request over an unauthenticated channel and be compliant but with
>my wording I can't be compliant.

If you want to be insecure, you can. Again, our expectation is that 
companies relying on SCVP will have their own SCVP servers. They might want 
to risk running the requests and responses over their corporate networks. 
Dumb, yes (given the small overhead of signing), but it should be 
acceptable if they really want to do it even after the warnings.

> > We very explicitly did the opposite. *All* of the semantics are in sections
> > 2, 3, and 4; *only* the syntax is in sections 5 and 6. The reason for this
> > is to reduce confusion between the two syntaxes.
>
>In my cursory reading I missed this point. I would recommend you highlight
>this point to make it very clear and make sure all understand it.

Will do.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA13946; Mon, 28 Jun 1999 19:46:58 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Jun 1999 19:46:56 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA13896 for <[e-mail]>; Mon, 28 Jun 1999 19:46:55 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Mon, 28 Jun 1999 19:39:52 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
In-Reply-To: <[e-mail] o.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: c029b5a0bbba42146491d169709d437e

At 11:46 AM 6/29/1999 +1000, [e-mail] wrote:
>The first glance impression.
>
>The purpose of the verification, as I understood it, is to attain to the
>validity of the certificate.
>I guess it will provide more value if the result (phrasing it out freely)
>was " a certificate was valid (or otherwise) at a particular moment of
>time".
>I can imagine that it is of a big importance for the clients to know if a
>certificate WAS valid at some moment in the past (when it was actually used
>for signing etc). So should the request contain an extra [optional]
>timeOfInterest field?
>
>1. Note, it is not the same as the ProducedAt field you have proposed.
>
>2. Hmm, sounds very much like a digital Notary to me :)

Yes, it sure does. If we overload the protocol, the "S" becomes a "C". I'd 
rather leave this in the notary work.



--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA13941; Mon, 28 Jun 1999 19:46:58 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Jun 1999 19:46:57 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA13904 for <[e-mail]>; Mon, 28 Jun 1999 19:46:56 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Mon, 28 Jun 1999 19:45:37 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
In-Reply-To: <[e-mail] o.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 7fd79a2263f30cd8074e49bfa779e913

At 12:27 PM 6/29/1999 +1000, [e-mail] wrote:
>Hardcoded SHA-1:
>Why not to use the X509 AlgorithmIdentifier?

Because there are two syntaxes, one of which is not ASN.1. If folks see a 
need for the additional complexity, we could put in a hash identifier that 
might look like that in the ASN.1 syntax.

But I still don't think it's all that necessary. Why make a simple client 
know two methods of hashing? Is there a real value to that? If there are 
multiple hash algorithms, clients will be expected to know all of them (so 
they can use an arbitrary server), which leads to code bloat. Are we really 
that nervous about SHA-1?

>Request/Response signatures:
>Could the PKCS#7 encapsulation be used for the request and response?

For the ASN.1 syntax, yes; for the tiny syntax, absolutely not. But CMS 
doesn't really add much, and there's no reason to expect clients to be 
CMS-aware.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA16803; Mon, 28 Jun 1999 20:04:21 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Jun 1999 20:04:20 -0700
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 UAA16776 for <[e-mail]>; Mon, 28 Jun 1999 20:04:19 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id UAA32320 for <[e-mail]>; Mon, 28 Jun 1999 20:07:50 -0700
Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (mailgate2.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 28 Jun 1999 20:07:39 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id UAA56554 for <[e-mail]>; Mon, 28 Jun 1999 20:07:38 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 28 Jun 1999 20:07:37 -0700
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: bf58d985cc18c9519ad64c1fc6bfff50

Hi Paul,

Thanks for your response. Below are my comments.

> At 06:24 PM 6/28/1999 -0700, Aram Perez wrote:
>>1) I like the idea of SCVP but if the SCVP response is signed, how does the
>>client verify the signature if it can't handle certs?
>
> It has the public key of the server built-in without a cert. Remember, you
> don't need certs for root keys.

This is fine but implies a limited number of SCVP servers.

>>2) Section 3.20 states "The CertID item has an identifier for the type of
>>certificate and the SHA-1 [SHA-1] hash of the octets of the certificate
>>itself." While I agree with specifying SHA-1 to *identify the certs*, I
>>recently got beat up on this mailing list because IETF is always supposed to
>>allow algorithm independence ;-)
>
> Not always. There is a tradeoff of multiple algorithms for safety (in case
> SHA-1 gets broken) versus complexity (having to include another identifier
> and having clients understand it). What do others think here? I hard-coded
> SHA-1 for simplicity.

Believe me, I agree with specifying just one algorithm for simplicity (and
interoperability) sake. It's just that I wanted someone else to get beat up
like I was ;-)

>>3) Section 3.17 RequestNonce. Why is this field optional if requiring it
>>would prevent a well known attack? Ditto for changing the nonce with every
>>request.
>
> It didn't seem completely necessary, just Very Good, thus SHOULD instead of
> MUST. We're open to either.

I vote for SHOULD.

>>4) Section 3.19 RequestSignature, 2nd paragraph. I would suggest rewording
>>it as "Requests MUST include a RequestSignature item unless the request is
>>done over an authenticated channel, such as..."
>
> That wording is equivalent to what we have, I think. I prefer SHOULD to
> "MUST with exceptions" as a stylistic choice.

I don't think that it is equivalent. With the original wording I can send an
unsigned request over an unauthenticated channel and be compliant but with
my wording I can't be compliant.

[snip]
>>7) Section 5 Tiny Syntax. More definition is needed specially for items that
>>are octets. For example, Version. Does 0x00 correspond to version 1 or
>>should the octet be 0x01?
>
> The latter. In the semantics section, we gave the decimal values for the
> items. Version has a decimal value of 1, so the hex value would be x01.
>
>>  Another example, ExtensionCritical. Are only 0x00
>>and 0x01 allowed?
>
> Correct. See the list of values in the semantics section for the legal
> values, then apply that to the appropriate syntax section.
>
>>  Or does 0x00 mean FALSE and non-zero mean TRUE? Ditto for
>>TypesOfCheck and WantBack.
>>
>>8) I think it would be helpful to add ASN.1 comments (Phil Griffin help).
>>For examples:
>>     FullRequest ::= SEQUENCE {
>>       version             Version,
>>         .
>>         .
>>       requestSignature    [3] Signature OPTIONAL
>>                                    -- Required on unauthenticated channels
>>     }
>>
>>     CertID ::= CHOICE {
>>       pkixCert    [0] OCTET STRING, -- SHA-1 of X.509 certificate
>>       pgpCert     [1] OCTET STRING  -- SHA-1 of PGP certificate
>>     }
>
> We very explicitly did the opposite. *All* of the semantics are in sections
> 2, 3, and 4; *only* the syntax is in sections 5 and 6. The reason for this
> is to reduce confusion between the two syntaxes.

In my cursory reading I missed this point. I would recommend you highlight
this point to make it very clear and make sure all understand it.

Regards,
Aram Perez


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA10749; Mon, 28 Jun 1999 19:24:59 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Jun 1999 19:24:56 -0700
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA10712; Mon, 28 Jun 1999 19:24:54 -0700 (PDT)
From: [e-mail]
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id MAA04486; Tue, 29 Jun 1999 12:30:15 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <N40L258S>; Tue, 29 Jun 1999 12:27:12 +1000
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Tue, 29 Jun 1999 12:27:04 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: e4c3b2ac87a4067bee0b3709bdc0fcc1

Hardcoded SHA-1:
Why not to use the X509 AlgorithmIdentifier? It gives you a flexibility to
use any (but just one) hash algorithm.
AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }


Request/Response signatures:
Could the PKCS#7 encapsulation be used for the request and response?
signedContent for normal comms, and dataContent for secure/authenticated
wire?


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA05600; Mon, 28 Jun 1999 18:44:18 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Jun 1999 18:44:17 -0700
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05577 for <[e-mail]>; Mon, 28 Jun 1999 18:44:14 -0700 (PDT)
From: [e-mail]
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id LAA03918; Tue, 29 Jun 1999 11:49:23 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <N40L257Q>; Tue, 29 Jun 1999 11:46:21 +1000
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
Date: Tue, 29 Jun 1999 11:46:19 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: c11ae585710ff675d4b497bf96ca848a

The first glance impression. 

The purpose of the verification, as I understood it, is to attain to the
validity of the certificate.
I guess it will provide more value if the result (phrasing it out freely)
was " a certificate was valid (or otherwise) at a particular moment of
time". 
I can imagine that it is of a big importance for the clients to know if a
certificate WAS valid at some moment in the past (when it was actually used
for signing etc). So should the request contain an extra [optional]
timeOfInterest field?

1. Note, it is not the same as the ProducedAt field you have proposed.

2. Hmm, sounds very much like a digital Notary to me :)

Michael Zolotarev
Technical Architect, Baltimore Technologies Pty Ltd (Australia)


> 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  : Simple Certificate Validation Protocol (SCVP)
>  Author(s) :  A. Malpani, P. Hoffman
>  Filename : draft-ietf-pkix-scvp-00.txt
>  Pages  :
>  Date  : 25-Jun-99
>  
> The SCVP protocol allows a client to offload certificate handling to a
> server. The server can give a variety of valuable information about the
> certificate, such as whether or not it is valid, what the public key
> and subject of the certificate is, and so on.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-00.txt
[snip]


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA05807; Mon, 28 Jun 1999 18:50:35 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Jun 1999 18:50:34 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05785 for <[e-mail]>; Mon, 28 Jun 1999 18:50:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Mon, 28 Jun 1999 18:49:23 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 3138b3305d4f59962090d645f6ce5501

At 06:24 PM 6/28/1999 -0700, Aram Perez wrote:
>1) I like the idea of SCVP but if the SCVP response is signed, how does the
>client verify the signature if it can't handle certs?

It has the public key of the server built-in without a cert. Remember, you 
don't need certs for root keys.

>2) Section 3.20 states "The CertID item has an identifier for the type of
>certificate and the SHA-1 [SHA-1] hash of the octets of the certificate
>itself." While I agree with specifying SHA-1 to *identify the certs*, I
>recently got beat up on this mailing list because IETF is always supposed to
>allow algorithm independence ;-)

Not always. There is a tradeoff of multiple algorithms for safety (in case 
SHA-1 gets broken) versus complexity (having to include another identifier 
and having clients understand it). What do others think here? I hard-coded 
SHA-1 for simplicity.

>3) Section 3.17 RequestNonce. Why is this field optional if requiring it
>would prevent a well known attack? Ditto for changing the nonce with every
>request.

It didn't seem completely necessary, just Very Good, thus SHOULD instead of 
MUST. We're open to either.

>4) Section 3.19 RequestSignature, 2nd paragraph. I would suggest rewording
>it as "Requests MUST include a RequestSignature item unless the request is
>done over an authenticated channel, such as..."

That wording is equivalent to what we have, I think. I prefer SHOULD to 
"MUST with exceptions" as a stylistic choice.

>5) Section 3.23 KeyId. See comment 2.

Ditto.

>6) Section 4.13 ResponseSignature. See comment 4.

Ditto.

>7) Section 5 Tiny Syntax. More definition is needed specially for items that
>are octets. For example, Version. Does 0x00 correspond to version 1 or
>should the octet be 0x01?

The latter. In the semantics section, we gave the decimal values for the 
items. Version has a decimal value of 1, so the hex value would be x01.

>  Another example, ExtensionCritical. Are only 0x00
>and 0x01 allowed?

Correct. See the list of values in the semantics section for the legal 
values, then apply that to the appropriate syntax section.

>  Or does 0x00 mean FALSE and non-zero mean TRUE? Ditto for
>TypesOfCheck and WantBack.
>
>8) I think it would be helpful to add ASN.1 comments (Phil Griffin help).
>For examples:
>     FullRequest ::= SEQUENCE {
>       version             Version,
>         .
>         .
>       requestSignature    [3] Signature OPTIONAL
>                                    -- Required on unauthenticated channels
>     }
>
>     CertID ::= CHOICE {
>       pkixCert    [0] OCTET STRING, -- SHA-1 of X.509 certificate
>       pgpCert     [1] OCTET STRING  -- SHA-1 of PGP certificate
>     }

We very explicitly did the opposite. *All* of the semantics are in sections 
2, 3, and 4; *only* the syntax is in sections 5 and 6. The reason for this 
is to reduce confusion between the two syntaxes.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA05207; Mon, 28 Jun 1999 18:21:19 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Jun 1999 18:21:05 -0700
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 SAA05179 for <[e-mail]>; Mon, 28 Jun 1999 18:21:05 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id SAA16504 for <[e-mail]>; Mon, 28 Jun 1999 18:24:30 -0700
Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (mailgate2.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 28 Jun 1999 18:24:26 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id SAA31908 for <[e-mail]>; Mon, 28 Jun 1999 18:24:25 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 28 Jun 1999 18:24:24 -0700
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b9f698b7b85c33a5fea5ab6ca6876fcf

A few minor comments after a very cursory read:

1) I like the idea of SCVP but if the SCVP response is signed, how does the
client verify the signature if it can't handle certs?

2) Section 3.20 states "The CertID item has an identifier for the type of
certificate and the SHA-1 [SHA-1] hash of the octets of the certificate
itself." While I agree with specifying SHA-1 to *identify the certs*, I
recently got beat up on this mailing list because IETF is always supposed to
allow algorithm independence ;-)

3) Section 3.17 RequestNonce. Why is this field optional if requiring it
would prevent a well known attack? Ditto for changing the nonce with every
request.

4) Section 3.19 RequestSignature, 2nd paragraph. I would suggest rewording
it as "Requests MUST include a RequestSignature item unless the request is
done over an authenticated channel, such as..."

5) Section 3.23 KeyId. See comment 2.

6) Section 4.13 ResponseSignature. See comment 4.

7) Section 5 Tiny Syntax. More definition is needed specially for items that
are octets. For example, Version. Does 0x00 correspond to version 1 or
should the octet be 0x01? Another example, ExtensionCritical. Are only 0x00
and 0x01 allowed? Or does 0x00 mean FALSE and non-zero mean TRUE? Ditto for
TypesOfCheck and WantBack.

8) I think it would be helpful to add ASN.1 comments (Phil Griffin help).
For examples:
    FullRequest ::= SEQUENCE {
      version             Version,
        .
        .
      requestSignature    [3] Signature OPTIONAL
                                   -- Required on unauthenticated channels
    }

    CertID ::= CHOICE {
      pkixCert    [0] OCTET STRING, -- SHA-1 of X.509 certificate
      pgpCert     [1] OCTET STRING  -- SHA-1 of PGP certificate
    }

That's it for now,
Aram Perez


> 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  : Simple Certificate Validation Protocol (SCVP)
>  Author(s) :  A. Malpani, P. Hoffman
>  Filename : draft-ietf-pkix-scvp-00.txt
>  Pages  :
>  Date  : 25-Jun-99
>  
> The SCVP protocol allows a client to offload certificate handling to a
> server. The server can give a variety of valuable information about the
> certificate, such as whether or not it is valid, what the public key
> and subject of the certificate is, and so on.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-00.txt
[snip]


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA25212; Mon, 28 Jun 1999 05:50:02 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Jun 1999 05:48:45 -0700
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA25182 for <[e-mail]>; Mon, 28 Jun 1999 05:48:44 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27924; Mon, 28 Jun 1999 08:51:37 -0400 (EDT)
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-scvp-00.txt
Date: Mon, 28 Jun 1999 08:51:36 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0a343201f05c1fa1d687b5d25b2ed152

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		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	:  A. Malpani, P. Hoffman
	Filename	: draft-ietf-pkix-scvp-00.txt
	Pages		: 
	Date		: 25-Jun-99
	
The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about the
certificate, such as whether or not it is valid, what the public key
and subject of the certificate is, and so on.

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

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

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


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

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

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-scvp-00.txt>
>From ???@??? Mon Jun 28 16:39:22 1999
Received: from localhost (daemon@localhost)
	by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA02912;
	Mon, 28 Jun 1999 15:20:50 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 28 Jun 1999 15:20:40 -0700
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02889
	for <[e-mail]>; Mon, 28 Jun 1999 15:20:39 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24])
	by popmail.inbox.se (8.9.3/8.9.3) with SMTP id AAA00514;
	Tue, 29 Jun 1999 00:24:06 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 29 Jun 1999 00:24:17 +0200
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: PolicyStatements ewxtension in Qualified Certificates
Cc: Stephen Kent <[e-mail]>
In-Reply-To: <v04020a09b39070b60562@[128.89.0.110]>
References: <[e-mail]>
 <v04020a11b38f168558d5@[128.33.238.33]>
 <[e-mail]>
 <v04020a10b38b45a34213@[128.33.238.203]>
 <[e-mail]>
 <v04020a0fb383271ddc78@[128.89.0.110]>
 <[e-mail]>
 <41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15>
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 PAA02890
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 80e7692cb2ea8cf7f56c78bc06e444ab

All,

I conclude from various on-list and off-list discussions that the best way
to solve inclusion of statements related to legal frameworks in a Qualified
Certificate, is to provide this functionality in a private extension.

Three statements has been discussed related to the EU-directive:

1) Inclusion of a reliance limit (how much you should rely on the
certificate. Note that this has NOTHING to do with how much you should rely
on the certified subject).
2) Inclusion of a statement declaring that the certificate is a Qualified
Certificate according to a legal framework (In case of the EU-directive,
that the certificate meets Annex I and are issued according to Annex II)
2) Inclusion of a statement, limiting the area of use of the certificate.

I have earlier posted a proposal for such an extension. The current
proposal is:

    PolicyStatement  EXTENSION ::= {
      SYNTAX             PolicyStatementSyntax
      IDENTIFIED BY      id-pe-PolicyStatement }

    id-pe-policyStatement          OBJECT IDENTIFIER ::= { id-pe 3 }
    -- This is  only a proposed OID. It is not assigned yet.

    PolicyStatementSyntax ::= SEQUENCE OF Statement
   
    Statement ::= SEQUENCE {
        StatementId        OBJECTIDENTIFIER
        StatementInfo      ANY DEFINED BY StatementId OPTIONAL}

As these types of statements are policy statements, the QC standard SHALL
require that included statements are not in conflict with any policy
identified in the policy extension.

Stephen Kent replied to the last proposal with:

At 05:58 PM 6/18/99 -0400, Stephen Kent wrote:
>Stefan,
>
>This would make folks happy who hated the use of policy qualifiers for
>this, and address the incorporation by reference concerns too. One
>question: why do we need the "Any Defined by: here?  I'd rather not leave
>the hole for folks to incorporate text directly, instead of by pointer and
>hash.  why not replace the statement by those two data items?
>
>Please bring it to the list.
>
>Steve

The answer to this is that the StatmentInfo may be required in order to
make a good structure for several statements. I.e. one OID may define that
StatementInfo contains a reliance limit specified using the ISO structure
for monetary value  (expressed before), and another OID may define that the
StatementInfo contains information regarding restrictions of usage (e.g.
only for banking applications).

So this is a 2 step approach, but can also be used as an 1 step approach in
cases where an exact statement can be identified by a single OID. In the
latter case the StatementInfo is omitted.

Before I put this in the specification I would like some final reactions on
this.

/Stefan 







-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA04814; Sat, 26 Jun 1999 20:42:45 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Sat, 26 Jun 1999 20:42:14 -0700
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 UAA04719; Sat, 26 Jun 1999 20:42:12 -0700 (PDT)
Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id XAA28320; Sat, 26 Jun 1999 23:45:22 -0400 (EDT)
Received: by world.std.com (TheWorld/Spike-2.0) id AA05946; Sat, 26 Jun 1999 23:45:22 -0400
Message-Id: <[e-mail]>
To: Graham Klyne <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Certificate requests for encryption keys 
In-Reply-To: Your message of "Mon, 14 Jun 1999 11:35:17 EDT." <[e-mail]> 
Date: Sat, 26 Jun 1999 23:45:18 -0400
From: Dan Geer <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: f2cb0f060c3b9aac4dffbe986cf7e4bf

    >[...]   and since I'm pretty picky about 
    >doing things the way PKIX requires the only way they could get
    >self-issued certs to work is to make everyone a CA.
    
    Time for a dumb question, if I may.
    
    What is the problem with this?

My colleague Don Davis & I have discussed this as early as
1996, see http://world.std.com/~dtd/scca/smartcard_ca.ps

In my view, there is nothing wrong and much right...

--dan



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA00989; Fri, 25 Jun 1999 09:22:12 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 25 Jun 1999 09:22:07 -0700
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 JAA00967 for <[e-mail]>; Fri, 25 Jun 1999 09:22:06 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id SAA13298; Fri, 25 Jun 1999 18:24:00 +0200
Message-ID: <[e-mail]>
Date: Fri, 25 Jun 1999 18:23:47 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
CC: "'IETF-PXIX'" <[e-mail]>
Subject: Re: New TSP draft
References: <000001bebe30$02575ca0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 5c0cdb5a01361db144b845ca258d2628

Michael,

You were really in the "starting blocks", even not waiting until the new draft
was made available. :-)

> Good luck, Denis. Looking forward to see the new draft. Though would be
> nicer not to have any patents in there at all :)
>
> What about the [boring issue of] messageTag?

As you said "boring". It is currently left out because, in this way, the TSA
*may not be* in a position to learn anything about the context of use. This is
motivated from a legal point of view.

> Also, recently there was a good 'pick' by James Manger about GeneralizedTime
> syntax, which itself allows defining time value down to fractions of second.

There are various ways to address the problem. GeneralizedTime using a precision
below the second is certainly one. The one currently in the document has been
imported directly from the NTP document. NTP is using 32 bits words and
basically that format has been translated into ASN1.

In particular the precisionFactor which tells the precision of the clock. This
also gives the format of fractionOfSecond.

Using Generalized time up to the second only makes it consistant with the format
used in certificates and CRLs. This was the major motivation for choosing it.
There are however two additional needs solved by a single structure :
fractionOfSecond.

a) the need to make the difference between two time stamps within the same
second.
b) the need to give a precision below the second.

Basically the left bits of fractionOfSecond are meaningful as far as the
precision is concerned when the precisionFactor is negative, while the right
bits will certainly not be.

If the precisionFactor is nul or positive, none of these bits carry a time
information and in that case the field is only used to make the difference
between two time stamps within the same second.

These are basically the explanations that motivated this structure. There are
surely alternatives to the problem, we picked one based on the above
motivations.

Regards,

Denis

>
> Regards
> MichaelZ



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA29437; Fri, 25 Jun 1999 07:17:19 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 25 Jun 1999 07:16:50 -0700
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA29411 for <[e-mail]>; Fri, 25 Jun 1999 07:16:48 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA09129; Fri, 25 Jun 1999 16:19:58 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 25 Jun 1999 16:19:58 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id QAA25067; Fri, 25 Jun 1999 16:19:57 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id QAA05895; Fri, 25 Jun 1999 16:19:56 +0200
Date: Fri, 25 Jun 1999 16:19:56 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: New TSP draft
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0184a106c091c20239ba149f97c154f7

Here some comments:

> 
> 1) The introduction has been re-written.
> 
> 2) The status has now be placed outside the Time Stamping Token
> (TST).

You have no longer any means to create a signed response from
the TSA indicating that you cannot create a time stamp. 

I try to resume the discussions: 

- There were requests to create an unsigned error message; 
  That's what you have created (although I don't understand
  why you have a SEQUENCE and not a CHOICE, since success
  is the only case where you can have a token, thus the value
  of success itself is redundant. 
  
- The same argument apply for a signed error message, thus the
  TSTinfo could be a 

  TSTInfoOrError = 
     CHOICE {   pkistatus [0] PKIStatusinfo ,
                              tstinfo   [1] TSTInfo 
            }

  which in fact is equivalent with the syntax of the previous draft
  but somewhat nicer. 

Of course, if the lower layer protocol is hhtp over SSL,
or direct socket over ssl, then a signed error is not necessary. 
  
> 
> 3) The items 5 and 6 under the "Security Considerations" chapter
> which is chapter 6 have been deleted.
> 
> 4) The precisionFactor has been changed from INTEGER to BIT
> STRING (but not to REAL) and the explanations are, I hope,
> better.

Why that: It is an unsigned integer, so why an encoding
as a bit string. 

In fact, why is this an integer at all. 

The fraction of a second could be encoded with a generalizedtime.
Why not making it optional?

I think that the precision should be an optional element,
a TSA may be not be able or willing to give such a detail, or
specify it in a policy. 

The whole TSTTime may be optional then, and the signingtime
attribute MAY be used instead??
  
> 
> 12) HTTP errors.  Peter Sylvester has been complaining that we
> don't specify what to do in the HTTP protocol when errors occur.
> The following sentence has been added "Upon receiving a valid
> request, the server MUST respond with either a valid
> response with content type application/timestamp or with an HTTP
> error."
This sentence seems useless, since it is redundant. The
question is not that you create an error message, any http server
does that from time to time, BUT rather how a client should
interprete it. 

"It is up to the client to decide how to react on an http
 error message."

"Unless when the http layer is encapsulated inside an ssl layer, 
 an http error message or un unsigned error message cannot be
 trusted as a definitive indication of the servers status."


There are a few spelling errors in the text:

     1. to provide a trustworty source of time.
                     trustworthy

    3. to include a monotonically incrementing value of the time of day 
                                  increasing
        for each newly generated time stamp token.


> The time stamp token MUST NOT contain any signatures other than the 
> signature of the TSA. The certificate identifier of the TSA 
> certificate shall be included as a signed attribute.
              ?????

And why that phrase, why couldn't you have more than one entity
sign the time stamp? 


Remove the Content-Transfer-Encoding: in 3.3:

A simple MIME object is specified as follows:

The Content-Type is application/timestamp, and the content is a
DER encoded time stamp message, encapsulated with an appropropriate
content-transfer encoding.


The comment about identification of the requestor at the beginning
of page 5 should probably be included in 3.3 and 3.4, and it
should not only mention authentication, but also confidentiality.








Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA06335; Thu, 24 Jun 1999 12:30:24 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 24 Jun 1999 12:29:42 -0700
Received: from intotoinc.com ([206.40.37.62]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06305 for <[e-mail]>; Thu, 24 Jun 1999 12:29:41 -0700 (PDT)
Received: from shasta ([206.40.37.46]) by intotoinc.com (8.9.1/8.9.1) with SMTP id MAA29765 for <[e-mail]>; Thu, 24 Jun 1999 12:27:03 -0700 (PDT)
Message-ID: <026701bebe79$0d03b6a0$2e05010a@HEG>
From: "Kalyan Chakravarthy Bade" <[e-mail]>
To: <[e-mail]>
Date: Thu, 24 Jun 1999 12:37:52 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0264_01BEBE3E.603B6E70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0fe6b6ba6ca2b75c3bcfa8db0720ebba

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2014.210" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Verdana size=2>subscribe</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA29944; Thu, 24 Jun 1999 03:29:22 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 24 Jun 1999 03:24:55 -0700
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 DAA29891 for <[e-mail]>; Thu, 24 Jun 1999 03:24:52 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id MAA17574 for <[e-mail]>; Thu, 24 Jun 1999 12:09:08 +0200
Message-ID: <[e-mail]>
Date: Thu, 24 Jun 1999 12:10:44 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: New TSP draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 4cc4c2e6bc6b08d36ef340e67fe1871a
Status: U

Dear PKIX group members,

Robert Zuccherato who was the lead editor of the Time Stamp
Protocol, asked me take the position of lead editor for that
draft. I have accepted despite my current workload.

I have just posted to the draft editor the new version, i.e.
<draft-ietf-pkix-time-stamp-02.txt> and I hope it will be made
available shortly.

First of all, I would like to thank Robert for its effort (this
work has been started at the Memphis meeting) and I do hope that
he made most of the (unpaved) way for going to a WG last call.
Robert will not be present at the Oslo meeting, but I will and
thus I will present the document.

Hereafter is a summary of the main changes that have been
performed after observing some heavy traffic on the mailing list.

1) The introduction has been re-written.

2) The status has now be placed outside the Time Stamping Token
(TST).

3) The items 5 and 6 under the "Security Considerations" chapter
which is chapter 6 have been deleted.

4) The precisionFactor has been changed from INTEGER to BIT
STRING (but not to REAL) and the explanations are, I hope,
better.

4) I considered the comments/complaints on the mailing list about
the TDA and so I prepared the document for an easy deletion of
that part, should it be the case. This issue will be discussed at
the Oslo meeting. To this respect, I have clarified the role of
the TDA and changed the ASN1 syntax to place any OPTIONAL
elements needed for the support of the TDA at the very end of the
ASN1 structures. I also moved the explanatory texts accordingly.

5) I believe that the "waiting" status is not/no more needed (I
saw no reason in the text for having it) and thus I have
suppressed it for the sake of simplicity.

6) The Annex B has been changed and aligned it with the white
paper I co-produced with Hans Nilsson on the Validation of
Digital signature.

7) Serial Number.  It was suggested on the list that this should
be made mandatory and not optional, in order to help solve the
"who was first" argument when two timestamps contain the same
time.  The serial number should be used just for token
identification and that solving the "who was first" argument
belongs in the tstTime field. Therefore, it doesn't need to be
mandatory, OPTIONAL is fine for applications that require it.

8) CMP Encapsulation.  It was also suggested that we use CMP
encapsulation instead of CMS.  It is just another way of doing
things.  We have decided to use CMS encapsulation.  Unless there
is a clear reason to use CMP, we should just leave it as it is.
There were a lot of choices we could have made, we chose this,
let's live with it.

9) SEQUENCE OF MessageImprint.  There was quite a discussion
about whether or not we should allow a SEQUENCE of
MessageImprint's (i.e. allow multiple hashes of a document in a
single token).  I really don't see the point of this.  If someone
breaks SHA-1, the entire PKI crumbles.

10) Criticality of extended key usage.  Complaints have been sent
to the list about the extended key usage extension indicating
time stamping to be critical.  A key certified for use in
timestamping should not also be used for establishing an SSL
connection, for example. I have left the document as it were, for
the moment.

11) TSA name in token.  Some people don't want the TSA's name
included within the token.  Since it was originally there, I kept
it, but it is only a hint about the identity of the TSA. If you
get a name different from the one expected, there is indeed an
error. If you get the right name, additional checking is
necessary. This means that the field is optional and that the
certificate identifier used for signing the token is now part of
a signed attribute

12) HTTP errors.  Peter Sylvester has been complaining that we
don't specify what to do in the HTTP protocol when errors occur.
The following sentence has been added "Upon receiving a valid
request, the server MUST respond with either a valid
response with content type application/timestamp or with an HTTP
error."

13) AIA OID. OID's for the Authority Information Access extension
are neeed for both the TSA and TDA. They should be called
id-ad-timestamping and id-ad-temporaldata.

I hope that's most of it, as far as the technical aspects are
concerned.

14) From another aspect, a new patent has been added to the
(long) list.

Now, wait for the new draft. :-)

Denis










Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA01146; Thu, 24 Jun 1999 03:55:10 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 24 Jun 1999 03:55:08 -0700
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA01124 for <[e-mail]>; Thu, 24 Jun 1999 03:55:06 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id UAA00195; Thu, 24 Jun 1999 20:59:50 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'IETF-PXIX'" <[e-mail]>
Subject: RE: New TSP draft
Date: Thu, 24 Jun 1999 20:54:41 +1000
Message-ID: <000001bebe30$02575ca0$[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 V5.00.2314.1300
Importance: Normal
In-Reply-To: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: a15afad6d5b86db87f357b637e62f9ac
Status: U

Good luck, Denis. Looking forward to see the new draft. Though would be
nicer not to have any patents in there at all :)

What about the [boring issue of] messageTag?
Also, recently there was a good 'pick' by James Manger about GeneralizedTime
syntax, which itself allows defining time value down to fractions of second.


Regards
MichaelZ









Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA18840; Wed, 23 Jun 1999 11:47:34 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Jun 1999 11:47:31 -0700
Received: from web601.yahoomail.com (web1101.mail.yahoo.com [128.11.23.121]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA18817 for <[e-mail]>; Wed, 23 Jun 1999 11:47:31 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [157.22.240.51] by web1101.mail.yahoo.com; Wed, 23 Jun 1999 11:50:11 PDT
Date: Wed, 23 Jun 1999 11:50:11 -0700 (PDT)
From: Hasa Klue <[e-mail]>
Subject: Attrribute Certificate Patents
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 68cafbf54b9a16afe1ff02c6ca15270a
Status: U

What is the patent status of attribute/authorization certificates?  Do
the patents of Fisher, Matyas or Sudia cover the current efforts for
attribute certificates?

I've found: 
US5659616 Sudia
several   Matyas
US5412717 Fisher

Are there others to consider?

Thanks,

Hasa


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA18461; Wed, 23 Jun 1999 11:20:00 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 23 Jun 1999 11:19:31 -0700
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18434 for <[e-mail]>; Wed, 23 Jun 1999 11:19:31 -0700 (PDT)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00056 for <[e-mail]>; Wed, 23 Jun 1999 11:22:32 -0700 (PDT)
Received: from saguaro.East.Sun.COM (saguaro.East.Sun.COM [129.148.75.130]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA25098 for <[e-mail]>; Wed, 23 Jun 1999 14:22:30 -0400 (EDT)
Received: (from aha@localhost) by saguaro.East.Sun.COM (8.9.1b+Sun/8.9.1) id OAA04798; Wed, 23 Jun 1999 14:22:30 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 23 Jun 1999 14:22:30 -0400 (EDT)
To: [e-mail]
Subject: bounding NameConstraints
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14193.5099.649384.501334@saguaro>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 7c11ed7f8bb811275a6a7c16beaea671
Status: U

I would like to be able to set NameConstraints such that ONLY
specified name types are accepted for subsequent end-entity
certificates. I can do this by creating a
NameConstraints:permitted:<type>:null entry for all those types I do
not wish to allow.

The problem is that I would also like to prohibit all certification
paths that use any OtherName types as well.  Otherwise, one of the
CA's may start issuing certificates for identities I don't want to
accept using a newly defined OtherName type.

Is there any way to specify "permitted:none" for ALL OtherName
types?

Anne Anderson
-- 
Anne H. Anderson  ECI#712-KC Email: [e-mail]
Sun Microsystems Laboratories   or: [e-mail]
1 Network Drive,UBUR02-311     Tel: [phone]
Burlington, MA 01803-0902 USA  Fax: [phone]


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA28469; Tue, 22 Jun 1999 19:10:04 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 22 Jun 1999 19:09:40 -0700
Received: from oak.us.pw.com (pw22.pw9.com [208.141.52.245]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA28314; Tue, 22 Jun 1999 19:09:37 -0700 (PDT)
From: [e-mail]
Received: by oak.us.pw.com; id WAA10840; Tue, 22 Jun 1999 22:13:19 -0400
Received: from moss.us.pw.com(10.9.16.183) by oak.us.pw.com via smap (4.1) id xma010322; Tue, 22 Jun 99 22:12:48 -0400
Received: from intlnamsmtp20.us.pw.com by moss.us.pw.com (PMDF V5.1-12 #U3018) with SMTP id <[e-mail]>; Tue, 22 Jun 1999 22:14:51 -0400 (EDT)
Received: by intlnamsmtp20.us.pw.com(Lotus SMTP MTA v1.2 hotfix6  (702.3 8-27-1998)) id 85256799.000BFB58 ; Tue, 22 Jun 1999 22:10:52 -0400
Date: Tue, 22 Jun 1999 22:10:48 -0400
Subject: subscribe
To: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
X-Lotus-FromDomain: C&L US@INTL
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: a0eee14fc8388d16273c4f4fbd84e7b3

subscribe
----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA24263; Mon, 21 Jun 1999 08:01:45 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Jun 1999 08:01:44 -0700
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24241 for <[e-mail]>; Mon, 21 Jun 1999 08:01:44 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with SMTP id HAA00675; Mon, 21 Jun 1999 07:56:43 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 21 Jun 1999 10:37:31 -0400
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: Stephen Kent <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <v04020a0ab38ee48b48a9@[128.33.238.16]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: c1b70000ca4d055a914b1221b24cc7bf

Denis:

>> Some people see a need for posting encrypted information in a Directory.
>> As long as it is not a mandatory requirement, but an option, what is the
>> problem.
>
>So let us *not* include it in the base document.

No.  That is exactly the point.  We want it in the base document as an
option.  This way, if an encrypted attribute is needed, everyone will know
how to do one.

>> I want all of the folks that post encrypted information to the Directory to
>> do so in the same manner.  This way, the ability to decrypt fall to the
>> ablity to obtain the correct key, not the ability to understand a
>> particular syntax.
>
>The requirement you describe can be met using a global encryption of the
>information placed in the Directory, not a selective field encryption of some
>signed attributes. This topic is thus more relevant to the WG taking care of 
>LDAP rather than ours.

I thought we were discussig how to encrypt some or all of the attributes
placed in an attribute certificate.  What does this have to do with LDAP?

Russ



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA23720; Mon, 21 Jun 1999 07:38:12 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Jun 1999 07:38:11 -0700
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA23695 for <[e-mail]>; Mon, 21 Jun 1999 07:38:09 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Mon, 21 Jun 1999 15:39:50 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id PAA13078; Mon, 21 Jun 1999 15:39:47 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id PAA22858; Mon, 21 Jun 1999 15:39:46 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: Carlisle Adams <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: use of objectDigestInfo 
In-reply-to: Your message of "Mon, 21 Jun 1999 09:49:17 EDT." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 21 Jun 1999 15:39:46 +0100
From: Stephen Farrell <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 8c2b926b020ced1384b6f2cfddf5fbf3

Carlisle,

> What I would suggest instead (and perhaps this is what you intended in the
> first place) is not that "a DigestedObjectInfo extension must be present
> which must use the wellKnownObject choice", but rather that PKIX-compliant
> implementations MUST "support (i.e., understand and be able to process) a
> DigestedObjectInfo extension that uses the wellKnownObject choice".  In
> other words, the wellKnownObject choice will be guaranteed to be understood
> by PKIX-compliant implementations, not that this is the only choice they're
> allowed to use.

Couldn't this mess up interop somewhat? It would mean that a
compliant implementation may not be able to verify a compliant
AC, due to the fact that the implementation doesn't know what 
thing should be digested. Maybe this needs some more thought?
(I guess I'm not sure what the security and implementation
implications are if the AC validation module doesn't know
what the owner field represents.)

If it solved the problem, I'd be quite open to adding more 
wellKnownObject's.

> Only to note that this whole proposal applies to the issuer field as well
> (it has already been agreed that the issuer choice in X.509 will be extended
> to include objectDigestInfo).

Speaking of which, if the FPDAM is to change this way, and since
use of the objectDigestInfo requires a v2 AC, would it be possible
to add the extra field unto the ObjectDigestInfo structure? 

E.g. if ObjectDigestInfo was defined as something like ...

        ObjectDigestInfo ::= SEQUENCE {
              digestAlgorithm     AlgorithmIdentifier,
              objectDigest        OCTET STRING,
              digestedObjectType  CHOICE {
                       wellKnownObject      INTEGER {
                                -- ...values
                       },
                       otherObject          OBJECT IDENTIFIER
              } OPTIONAL
        }

...then there'd be no need for a new extension (*much* nicer).

BTW: The draft currently mandates the the issuer MUST use a DN
(section 4.3.3). One consequence will be that use of objectDigestInfo 
for the issuer is non-compliant. I'd recommend sticking with this, 
(since it parallels 2459), but would be interested to see if anyone 
has a problem with this - if so, send a digest of your objection:-)

Regards,
Stephen.




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA24082; Mon, 21 Jun 1999 07:58:52 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Jun 1999 07:58:13 -0700
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24060 for <[e-mail]>; Mon, 21 Jun 1999 07:58:13 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with SMTP id HAA00679; Mon, 21 Jun 1999 07:56:44 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 21 Jun 1999 10:46:50 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: use of objectDigestInfo
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 954c827e1b20e0fc9e2dfe0c1fdca32f

Stephen:

I would think that the have of a public key would be the hash of the
subject publick key info field in the public key certificate (PKC).

I think that we should include an algorithm identifier for the hash
algorithm used.  And, the mandatory to implement hash algorithm must be SHA-1.

Russ

At 10:44 AM 6/21/99 +0100, Stephen Farrell wrote:
>
>A while back there was some discussion of SPKI and X.509 ACs
>(before that thread got taken over by encrypted attributes).
>
>There was some support for having a hashed public key (or
>hashed public key certificate) in the owner.objectDigestInfo
>field of an AC.
>
>As far as I know (and this may be completely wrong) this wasn't
>the original (X.509) idea for the objectDigestInfo field - the idea
>was that this field could contain a hash over e.g. some
>java bytecode, and whenever you download the bytecode, you also
>get the AC and could decide what you'll let the downloaded
>classes do. (Doesn't really matter, point is, it wasn't
>only intended for a hashed key/cert.)
>
>So, we have at least three possible things that could be 
>hashed, two of which are clearly within scope of a PKIX
>profile.
>
>One other factor is the definintion of ObjectDigestInfo - 
>it tells you how something was hashed, but not what thing
>was, that was hashed. So if we allow more than one thing-to-be-hashed
>we probably need to provide a hint about the thing in a 
>new extension.
>
>If we want to include this support then we could add something 
>like the following to the next version of the I-D:
>
>- define a DigestedObjectInfo extension (never critical) with
>a syntax like:
>
>	DigestedObjectInfoSyntax ::= CHOICE {
>		wellKnownObject	INTEGER {
>			publicKey	(0),
>			publicKeyCert	(1)
>		},
>		otherObject	OBJECT IDENTIFIER
>			-- if ever a field should use an oid, 
>			-- this one should:-)
>	}
>
>- owner.objectDigestInfo can be used, if so, mandatory to support
>  alg. is SHA-1, (MD5 allowed ?)
>
>- if owner.objectDigestInfo is used then a DigestedObjectInfo 
>  extension must be present which must use the wellKnownObject
>  choice
>
>- we specify what bits are input to the hashing for the two
>  well known objects. For the cert its the DER encoding of the 
>  full cert. For the key, its the DER encoding of a 
>  SubjectPublicKeyInfo, i.e. the BIT STRING for the key and the 
>  algo OID and the parameters)
>
>- we add the relevant additional checks to the AC validation
>  text
>
>Reactions?
>
>Regards,
>Stephen.
>
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA24431; Mon, 21 Jun 1999 08:05:37 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Jun 1999 08:05:36 -0700
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 IAA24409 for <[e-mail]>; Mon, 21 Jun 1999 08:05:34 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id RAA14452; Mon, 21 Jun 1999 17:06:35 +0200
Message-ID: <[e-mail]>
Date: Mon, 21 Jun 1999 17:08:12 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <[e-mail]> <v04020a0ab38ee48b48a9@[128.33.238.16]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: d5d78ccf479228b8db62594078f342a6

Russ,

As I originally proposed, I suggest that we stop discussing this topic on the
mailing list for the time being and continue with corridor discussions at the Oslo
meeting.

To put in practice this proposal immediatly, I will not argue anymore on this
topic on the list before the Oslo meeting.

Denis


> Denis:
>
> >> Some people see a need for posting encrypted information in a Directory.
> >> As long as it is not a mandatory requirement, but an option, what is the
> >> problem.
> >
> >So let us *not* include it in the base document.
>
> No.  That is exactly the point.  We want it in the base document as an
> option.  This way, if an encrypted attribute is needed, everyone will know
> how to do one.
>
> >> I want all of the folks that post encrypted information to the Directory to
> >> do so in the same manner.  This way, the ability to decrypt fall to the
> >> ablity to obtain the correct key, not the ability to understand a
> >> particular syntax.
> >
> >The requirement you describe can be met using a global encryption of the
> >information placed in the Directory, not a selective field encryption of some
> >signed attributes. This topic is thus more relevant to the WG taking care of
> >LDAP rather than ours.
>
> I thought we were discussig how to encrypt some or all of the attributes
> placed in an attribute certificate.  What does this have to do with LDAP?
>
> Russ



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA23254; Mon, 21 Jun 1999 06:50:58 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Jun 1999 06:50:41 -0700
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 GAA23230 for <[e-mail]>; Mon, 21 Jun 1999 06:50:39 -0700 (PDT)
Received: 	id JAA17520; Mon, 21 Jun 1999 09:46:52 -0400
Received: by gateway id <NAS8J87B>; Mon, 21 Jun 1999 09:49:19 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: use of objectDigestInfo
Date: Mon, 21 Jun 1999 09:49:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 7219607ab24dd1a4498fbdd1c59917d4

Hi Stephen,

> ----------
> From: 	Stephen Farrell[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Monday, June 21, 1999 5:44 AM
> To: 	[e-mail]
> Cc: 	[e-mail]
> Subject: 	use of objectDigestInfo
> 
> 
> A while back there was some discussion of SPKI and X.509 ACs
> (before that thread got taken over by encrypted attributes).
 
Yes, please let us move on from the encrypted attribute discussion.  Some
people see a need for them; others don't.  The normal standards way to solve
this dilemma is to make them OPTIONAL.  Guess what?  The draft already does
this -- problem solved!

Denis is perfectly free to write a profile for his environment that says
"never use this" and others are free to write a profile for their
environment that says "use this if needed".  I see no reason whatsoever to
remove this from the current draft.  Let's save our energy for arguing over
mandatory things, incorrect things, insecure things, or missing
functionality (if any of these situations arise)...

> As far as I know (and this may be completely wrong) this wasn't
> the original (X.509) idea for the objectDigestInfo field - the idea
> was that this field could contain a hash over e.g. some
> java bytecode, and whenever you download the bytecode, you also
> get the AC and could decide what you'll let the downloaded
> classes do. (Doesn't really matter, point is, it wasn't
> only intended for a hashed key/cert.)
 
(...some text deleted...)

> - if owner.objectDigestInfo is used then a DigestedObjectInfo 
>   extension must be present which must use the wellKnownObject
>   choice
 
Comparing this paragraph with the one just above it, it seems to me that
this may create an artificial and unnecessary dichotomy between
X.509-compliant implementations and PKIX-compliant implementations.

What I would suggest instead (and perhaps this is what you intended in the
first place) is not that "a DigestedObjectInfo extension must be present
which must use the wellKnownObject choice", but rather that PKIX-compliant
implementations MUST "support (i.e., understand and be able to process) a
DigestedObjectInfo extension that uses the wellKnownObject choice".  In
other words, the wellKnownObject choice will be guaranteed to be understood
by PKIX-compliant implementations, not that this is the only choice they're
allowed to use.

> Reactions?
 
Only to note that this whole proposal applies to the issuer field as well
(it has already been agreed that the issuer choice in X.509 will be extended
to include objectDigestInfo).

Carlisle.



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA17299; Mon, 21 Jun 1999 00:10:16 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Jun 1999 00:09:32 -0700
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 AAA17276 for <[e-mail]>; Mon, 21 Jun 1999 00:09:29 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id JAA10810; Mon, 21 Jun 1999 09:08:55 +0200
Message-ID: <[e-mail]>
Date: Mon, 21 Jun 1999 09:10:32 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <[e-mail]> <v04020a0ab38ee48b48a9@[128.33.238.16]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0b8a2b25e7db758aa3891f7d70af78e1

Russ,

> Denis:
>
> Some people see a need for posting encrypted information in a Directory.
> As long as it is not a mandatory requirement, but an option, what is the
> problem.

So let us *not* include it in the base document.

> I want all of the folks that post encrypted information to the Directory to
> do so in the same manner.  This way, the ability to decrypt fall to the
> ablity to obtain the correct key, not the ability to understand a
> particular syntax.

The requirement you describe can be met using a global encryption of the
information placed in the Directory, not a selective field encryption of some
signed attributes. This topic is thus more relevant to the WG taking care of LDAP
rather than ours.

Regards,

Denis


>
> Russ
>
> At 02:37 PM 6/18/99 +0200, Denis Pinkas wrote:
> >Steve,
> >
> >> Denis,
> >>
> >> I tend to agree with Russ and Stephen on this one.  It seems reasonable to
> >> be able to encrypt some parameters in an AC, for any of the application
> >> examples cited.
> >
> >I have not seen a good argumentation for them, up to now. But the problem is
> >much deeper, as indicated after.
> >
> >> If we want to be able to store ACs in directories without
> >> having to rely exclusively on directory access controls for
> >> confidentiality, then encryption of the attributes seems like a good
> >> mechanism.
> >
> >Hum ! You are implictly supporting there a push model whereas I am a
> supportive
> >of a pull model where that functionality is not needed. With a push model you
> >not have have these kind of problems: no encryption and no access control. :-)
> >
> >
> >> Yes, this may mean that the encrypted fields in the AC will be
> >> accessable by a limited set of entities, who may often be known at the time
> >> of AC creation. (Thye don't have to be know at this time, since it may be
> >> feasible to dynamically distributed the necessary decryption material
> >> later, e.g., incrementally.) I don't see this as a problem; often an AC may
> >> be quite constrained in the set of entities that will accept it anyway, if
> >> one views ACs as capabilities.
> >
> >Once again a push model is much simpler ! I do know that anyway some people
> >will go or have to go for a pull model, ... at their own risk. For the sake of
> >simplicity, I am advocating a basic document covering the basic needs of a
> push
> >model, which does not need the support of encrypted attributes. If some other
> >people want to go further, then I would have no problem to let them draft
> >another document. But this is a problem to be discussed both in the corridors
> >and the next PKIX meeting  at Oslo.   :-)
> >
> >Denis
> >
> >>
> >> Steve



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA18542; Mon, 21 Jun 1999 02:16:20 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Jun 1999 02:16:12 -0700
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA18520 for <[e-mail]>; Mon, 21 Jun 1999 02:16:11 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Mon, 21 Jun 1999 10:16:11 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id KAA28019; Mon, 21 Jun 1999 10:16:09 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id KAA21745; Mon, 21 Jun 1999 10:16:08 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: Denis Pinkas <[e-mail]>
cc: Russ Housley <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI? 
In-reply-to: Your message of "Mon, 21 Jun 1999 09:10:32 +0200." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 21 Jun 1999 10:16:08 +0100
From: Stephen Farrell <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: e7a4f26ad61fb246722d6a9051ed52e2

Denis,

> > As long as it is not a mandatory requirement, but an option, what is the
> > problem.
> 
> So let us *not* include it in the base document.

Seems like this is what it boils down to. You don't mind that the
mechanism is defined by the WG, but do object to its being a 
non-mandatory part of the base document. I don't understand this. 

Can you say why?

(BTW: Since you don't mind the mechanism being specified, then I
guess your answer can't be based on technical reasons. Of course,
maybe you see a technical difference between "attribute encryptrion
as an option in rfcNNN" and "rfcMMM, an attribute encryption
extension to rfcNNN"? I don't.)

Regards,
Stephen.




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA18896; Mon, 21 Jun 1999 02:42:10 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 21 Jun 1999 02:42:09 -0700
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA18874 for <[e-mail]>; Mon, 21 Jun 1999 02:42:08 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Mon, 21 Jun 1999 10:44:27 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id KAA29380; Mon, 21 Jun 1999 10:44:23 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id KAA21913; Mon, 21 Jun 1999 10:44:22 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
Reply-To: [e-mail]
To: [e-mail]
cc: [e-mail]
Subject: use of objectDigestInfo
From: Stephen Farrell <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 21 Jun 1999 10:44:22 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 6d3ffc313049cf39e6c15025f179f221

A while back there was some discussion of SPKI and X.509 ACs
(before that thread got taken over by encrypted attributes).

There was some support for having a hashed public key (or
hashed public key certificate) in the owner.objectDigestInfo
field of an AC.

As far as I know (and this may be completely wrong) this wasn't
the original (X.509) idea for the objectDigestInfo field - the idea
was that this field could contain a hash over e.g. some
java bytecode, and whenever you download the bytecode, you also
get the AC and could decide what you'll let the downloaded
classes do. (Doesn't really matter, point is, it wasn't
only intended for a hashed key/cert.)

So, we have at least three possible things that could be 
hashed, two of which are clearly within scope of a PKIX
profile.

One other factor is the definintion of ObjectDigestInfo - 
it tells you how something was hashed, but not what thing
was, that was hashed. So if we allow more than one thing-to-be-hashed
we probably need to provide a hint about the thing in a 
new extension.

If we want to include this support then we could add something 
like the following to the next version of the I-D:

- define a DigestedObjectInfo extension (never critical) with
a syntax like:

	DigestedObjectInfoSyntax ::= CHOICE {
		wellKnownObject	INTEGER {
			publicKey	(0),
			publicKeyCert	(1)
		},
		otherObject	OBJECT IDENTIFIER
			-- if ever a field should use an oid, 
			-- this one should:-)
	}

- owner.objectDigestInfo can be used, if so, mandatory to support
  alg. is SHA-1, (MD5 allowed ?)

- if owner.objectDigestInfo is used then a DigestedObjectInfo 
  extension must be present which must use the wellKnownObject
  choice

- we specify what bits are input to the hashing for the two
  well known objects. For the cert its the DER encoding of the 
  full cert. For the key, its the DER encoding of a 
  SubjectPublicKeyInfo, i.e. the BIT STRING for the key and the 
  algo OID and the parameters)

- we add the relevant additional checks to the AC validation
  text

Reactions?

Regards,
Stephen.





Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA11081; Fri, 18 Jun 1999 18:28:31 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 18:28:26 -0700
Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA11058 for <[e-mail]>; Fri, 18 Jun 1999 18:28:26 -0700 (PDT)
Received: from brick (sdn-ar-004casfraP109.dialsprint.net [158.252.211.111]) by snipe.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id SAA03201; Fri, 18 Jun 1999 18:30:51 -0700 (PDT)
Message-ID: <014701beb9f3$2b5784e0$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>, <[e-mail]>
References: <[e-mail]><[e-mail]><v04020a0fb383271ddc78@[128.89.0.110]><[e-mail]><41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15><[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: Combination of policy OID:s
Date: Fri, 18 Jun 1999 18:29:21 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 9bada37832f7e19ec3eee453cc18b550

Russ, I agree with you.
It does violate the 2459 rule model, but I also think it is a valid use
model and we should indeed issue the new policy OID.

Todd

----- Original Message -----
From: Russ Housley <[e-mail]>
To: Todd S. Glassey - ELN <[e-mail]>
Cc: Denis Pinkas <[e-mail]>; Stefan Santesson
<[e-mail]>; <[e-mail]>
Sent: Friday, June 18, 1999 7:57 AM
Subject: Re: Combination of policy OID:s


> Todd:
>
> I believe that your proposal is in conflict with RFC 2459.  It says:
>
>    4.2.1.5  Certificate Policies
>
>       The certificate policies extension contains a sequence of one or
more
>       policy information terms, each of which consists of an object
>       identifier (OID) and optional qualifiers.  These policy information
>       terms indicate the policy under which the certificate has been
issued
>       and the purposes for which the certificate may be used.  Optional
>       qualifiers, which may be present, are not expected to change the
>       definition of the policy.
>
> I think that the use of certificate policy qualifier you are proposing
does
> change the definition of the policy.  In my view, that means that a new
> certificate policy OID should me assigned.
>
> Russ
>
>
> At 06:42 AM 6/18/99 -0700, Todd S. Glassey - ELN wrote:
> >
> >----- Original Message -----
> >From: Russ Housley <[e-mail]>
> >To: Denis Pinkas <[e-mail]>; Stefan Santesson
> ><[e-mail]>
> >Cc: <[e-mail]>
> >Sent: Thursday, June 17, 1999 9:29 AM
> >Subject: Re: Combination of policy OID:s
> >
> >
> >> Stefan & Denis:
> >>
> >> Persoanally, I really dislike policy qualifiers.  They have a negative
> >> imapct on interoperability.  If a policy is specified by an OID, then
the
> >> cert path validation does not need to know any details of that policy.
On
> >> the other hand, when qualifiers are used, cert path validation must
> >> understand the syntax and possibly the semantics of the qualifier.
> >>
> >> How does one get every implementation, especially mass market software
> >> implementations, to support a particular policy qualifier?  Beats me.
> >That
> >> is why they cause interoperability problems.
> >
> >Seems to me that there are many parts of the process that are application
> >depedent Russ - leave it up to the apps that use the data fioelds
> >
> >>
> >> In drafting RFC 2459, I suggested that policy qualifiers be forbidden.
> >> Others disagreed, so we have a compromise position documented in RFC
2459.
> >> It says:
> >>
> >>    To promote interoperability, this profile RECOMMENDS that policy
> >>    information terms consist of only an OID.  Where an OID alone is
> >>    insufficient, this profile strongly recommends that use of
qualifiers
> >>    be limited to those identified in this section.
> >>
> >> A small set of policy qualifiers was included with the hope that all
> >> implementations would include support for them.
> >>
> >> So, my advice is to avoid policy qualifiers.
> >>
> >> Russ
> >>
> >
> >>From the purist's point I agree with you, but there is also the issue of
> >creating functional services that address commercial requirements, and
> >becuase that is what pays the bills I suggest that perhaps there is a
class
> >of OIDs that can support Policy.
> >
> >One of the policy control OID Structures I would like to see is a
mechanism
> >to indicate a legal hierarchy. That is to say a representation of
mechanism
> >for legal jusridictions.
> >
> >This may be a subset of the policy OID concept but would be of tremendous
> >value in the world of Online EC enabled business, and while it is
strictly a
> >"non challenging" technical aspect of EC it is a requirement none the
less.
> >
> >Todd
> >
>
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA05807; Fri, 18 Jun 1999 12:52:30 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 12:52:20 -0700
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA05784 for <[e-mail]>; Fri, 18 Jun 1999 12:52:20 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with SMTP id MAA10203; Fri, 18 Jun 1999 12:47:13 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 18 Jun 1999 15:17:53 -0400
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: Stephen Kent <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <v04020a0ab38ee48b48a9@[128.33.238.16]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 659b3723cd7aa402ed63bb5048b2cb7e

Denis:

Some people see a need for posting encrypted information in a Directory.
As long as it is not a mandatory requirement, but an option, what is the
problem.

I want all of the folks that post encrypted information to the Directory to
do so in the same manner.  This way, the ability to decrypt fall to the
ablity to obtain the correct key, not the ability to understand a
particular syntax.

Russ

At 02:37 PM 6/18/99 +0200, Denis Pinkas wrote:
>Steve,
>
>> Denis,
>>
>> I tend to agree with Russ and Stephen on this one.  It seems reasonable to
>> be able to encrypt some parameters in an AC, for any of the application
>> examples cited.
>
>I have not seen a good argumentation for them, up to now. But the problem is
>much deeper, as indicated after.
>
>> If we want to be able to store ACs in directories without
>> having to rely exclusively on directory access controls for
>> confidentiality, then encryption of the attributes seems like a good
>> mechanism.
>
>Hum ! You are implictly supporting there a push model whereas I am a
supportive
>of a pull model where that functionality is not needed. With a push model you
>not have have these kind of problems: no encryption and no access control. :-)
>
>
>> Yes, this may mean that the encrypted fields in the AC will be
>> accessable by a limited set of entities, who may often be known at the time
>> of AC creation. (Thye don't have to be know at this time, since it may be
>> feasible to dynamically distributed the necessary decryption material
>> later, e.g., incrementally.) I don't see this as a problem; often an AC may
>> be quite constrained in the set of entities that will accept it anyway, if
>> one views ACs as capabilities.
>
>Once again a push model is much simpler ! I do know that anyway some people
>will go or have to go for a pull model, ... at their own risk. For the sake of
>simplicity, I am advocating a basic document covering the basic needs of a
push
>model, which does not need the support of encrypted attributes. If some other
>people want to go further, then I would have no problem to let them draft
>another document. But this is a problem to be discussed both in the corridors
>and the next PKIX meeting  at Oslo.   :-)
>
>Denis
>
>>
>> Steve



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA06335; Fri, 18 Jun 1999 13:24:50 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 13:23:58 -0700
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA06299 for <[e-mail]>; Fri, 18 Jun 1999 13:23:57 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with SMTP id NAA10780; Fri, 18 Jun 1999 13:18:51 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 18 Jun 1999 15:59:13 -0400
To: Stefan Santesson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Combination of policy OID:s
Cc: "Todd S. Glassey - ELN" <[e-mail]>, Stephen Kent <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
References: <002c01beb990$6682a620$930aff0c@brick> <[e-mail]> <[e-mail]> <v04020a0fb383271ddc78@[128.89.0.110]> <[e-mail]> <41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 6ac31ac52123f15a741d8e4c69a7d109

Stefan:

First, I want to understand a bit more about your assumptions.  In
particular, you said:
>We can conclude that there are several clear requirements statetd from the
>"non-technical" society (mostly related to Qualified Certificates), which
>demands inclusion of small explicit policy-related statements. The most
>important one is "This is a Qualified Certificate according to EU-directive
>Annex I and II"
>
>They will just not go for the current policy oriented solution where
everything
>is said in just one OID, specific to the CA.

Why do you say that the certificate policy (CP) OID is specific to a CA?  I
see several large communities defining a CP that will be used by many
different CAs.  The Certification Practice Statement (CPS) will be specific
to the CA; it documents how the CA practices meet the requirements in the
community-wide CP.

Russ


Received: from localhost (daemon@localhost)  by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA03689;  Fri, 18 Jun 1999 10:05:26 -0700 (PDT) 
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 10:05:24 -0700 
Received: from mail.iol.ie (mail2.mail.iol.ie [194.125.2.193])  by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03667  for <[e-mail]>; Fri, 18 Jun 1999 10:05:22 -0700 (PDT) 
Received: from fw1.inflo.ie (fw1.inflo.ie [194.125.13.18]) by mail.iol.ie  Sendmail (v8.9.3) with SMTP id SAA25763 for <[e-mail]>;  Fri, 18 Jun 1999 18:07:27 +0100 (IST) 
Received: from consus.inflo.com by fw1.inflo.ie  via smtpd (for mail2.mail.iol.ie [194.125.2.193]) with SMTP; 18 Jun 1996 17:09:00 UT 
Received: by ntserver.inflo.ie with Internet Mail Service (5.5.1960.3)  id <MXJR55BP>; Fri, 18 Jun 1999 18:11:50 +0100 
Message-ID: <[e-mail]> 
From: Kevin McGonagle <[e-mail]> 
To: "'[e-mail]'" <[e-mail]> 
Subject: X.509 certs 
Date: Fri, 18 Jun 1999 18:11:43 +0100 
MIME-Version: 1.0 
X-Mailer: Internet Mail Service (5.5.1960.3) 
MIME-Version: 1.0 
Content-Type: Multipart/signed;  protocol="application/x-pkcs7-signature";  micalg="sha-1";  boundary="Boundary-2=_ATtalnfbqZRONMFDWGPBEpeuhGB" 
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 
Content-Transfer-Encoding: 7bit 
X-Consus-Received: The message is clear-signed. Algorithms: Encryption="des3-cbc". Digest="sha-1". no crypto library exception. (18:07:06 Saturday 18 Jun 1999) 
Precedence: bulk 
List-Archive:

The following are the message properties:


   Encrypted: No
   Signed: Yes
   Contents Altered after signing: No
   Signature Algorithm: SHA1


The following are the message properties:


   Encrypted: No
   Signed: Yes
   Contents Altered after signing: Unknown
   Signature Algorithm: Unknown


If I have an X.509 user certificate signed by a CA, is there any way in which I can get the CA's public key from that cert?
 
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe 
X-UIDL: 0c316d50b44ae32ed895ffc775c22db5 

<html><DIV><A href="file://C:\Temp\X.509 certs.ems <0265.0002>" EUDORA="PLUGIN"><IMG 
alt="C:\Temp\X.509 certs.ems" src="file://d:\mail\combined\icons\b21c110.jpg"> 
X.509 certs.ems </A></DIV></html>
>From ???@??? Fri Jun 18 10:28:14 1999
Received: from localhost (daemon@localhost)
	by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA04063;
	Fri, 18 Jun 1999 10:25:17 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 10:25:14 -0700
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA04040
	for <[e-mail]>; Fri, 18 Jun 1999 10:25:14 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost)
	by stingray.missi.ncsc.mil with ESMTP id NAA02945
	for <[e-mail]>; Fri, 18 Jun 1999 13:27:51 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1])
	by stingray.missi.ncsc.mil with ESMTP id NAA02927
	for <[e-mail]>; Fri, 18 Jun 1999 13:27:50 -0400 (EDT)
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 NAA02285 for <[e-mail]>; Fri, 18 Jun 1999 13:27:52 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (avenger53.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>;
 Fri, 18 Jun 1999 13:25:39 -0400
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9)
	id <LX8NTYAP>; Fri, 18 Jun 1999 13:27:36 -0400
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Stephen Farrell'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: X.509 ACs vs. SPKI? 
Date: Fri, 18 Jun 1999 13:27:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BEB9AF.DAC72654"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 3e8c814d378f4c09ad897a355909e6fe


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0">
<TITLE>RE: X.509 ACs vs. SPKI? </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Stephen, I see your point!&nbsp; thanks for the feedback.</FONT>
</P>

<P><FONT SIZE=2>Sandi Miklos</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Stephen Farrell [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Friday, June 18, 1999 10:00 AM</FONT>
<BR><FONT SIZE=2>To: Miklos, Sue A.</FONT>
<BR><FONT SIZE=2>Cc: '[e-mail]'; [e-mail]; [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: Re: X.509 ACs vs. SPKI? </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>Sandi,</FONT>
</P>

<P><FONT SIZE=2>I did look at EncryptedAttributeSyntax when I was writing up the</FONT>
<BR><FONT SIZE=2>draft but chose to go with CMS EnvelopedData for a few reasons:-</FONT>
</P>

<P><FONT SIZE=2>- CMS (or at least pkcs#7) is much more widely implemented today</FONT>
<BR><FONT SIZE=2>- referencing CMS requires much less work for the group than</FONT>
<BR><FONT SIZE=2>&nbsp; profiling EncryptedAttributeSyntax from scratch</FONT>
<BR><FONT SIZE=2>- I find it handy to use EnvelopedData, since I can check</FONT>
<BR><FONT SIZE=2>&nbsp; interop easily (I extract the ciphertext attribute value,</FONT>
<BR><FONT SIZE=2>&nbsp; put on some MIME headers and feed it to our S/MIME </FONT>
<BR><FONT SIZE=2>&nbsp; product)</FONT>
<BR><FONT SIZE=2>- ignorance:-) Personally, I just don't understand what bytes</FONT>
<BR><FONT SIZE=2>&nbsp; to generate for things like:</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT SIZE=2> keyProtection PROTECTION-MAPPING ::= </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <FONT SIZE=2>SECURITY-TRANSFORMATION {genEncryption}</FONT></P>

<P><FONT SIZE=2>However, if there were significant advantages from, or lots of</FONT>
<BR><FONT SIZE=2>support for, moving to the X.501 syntax then I guess we should</FONT>
<BR><FONT SIZE=2>consider it.</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
<BR><FONT SIZE=2>Stephen.</FONT>
</P>

</BODY>
</HTML>
>From ???@??? Fri Jun 18 11:12:30 1999
Received: from localhost (daemon@localhost)
	by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA04425;
	Fri, 18 Jun 1999 10:42:26 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 10:42:25 -0700
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.30])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA04403
	for <[e-mail]>; Fri, 18 Jun 1999 10:42:24 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101])
	by mail.spyrus.com (8.9.3/8.9.3) with SMTP id KAA07207;
	Fri, 18 Jun 1999 10:40:52 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 18 Jun 1999 13:42:39 -0400
To: Stefan Santesson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Policy Qualifierts     Was: Re: Combination of policy OID:s
Cc: Stephen Kent <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
 <[e-mail]>
 <[e-mail]>
 <[e-mail]>
 <v04020a0fb383271ddc78@[128.89.0.110]>
 <[e-mail]>
 <41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15>
 <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 3a46e1f65b22c17747e92fc6e68e7661

Stefan:

If you have already determined that a separate extension is not a viable
alternative, then I suggest that you do nothing.  I do not think that you
can be sure that the certificate policies extension will always be
non-critical.

Russ


At 10:01 PM 6/17/99 +0200, Stefan Santesson wrote:
>Russ,
>
>I agree in principle, but maybe not totally.
>
>Unless the policy extension is critical, it is perfectly OK for a client to
>ignore any qualifier. And qualifiers may have some advantages if used
>properly. They will however most certainly only make sense to those
>applications who are specifically trained for them.
>
>In Qualified Certificates we have discussed inclusion of a monetary value
>(to be used to specify a max reliance limit). It is proposed that this MAY
>be specified by a qualifier , defined by a ISO defined ASN.1 field.
>
>In this case the qualifier may make sense. It will only have to be
>understood by those application who have been trained to react upon this
>information. Further, the CA can see through that only specifically trained
>clients will accept the certificates by setting this extension to critical.
>
>Stephen Kent has expressed his preliminary support for this solution. At
>least our conclusion has been that qualifier is the only possible way if we
>should do anything at all. An extension can't be defined since it would be
>to complex to define the semantics of such extension anyway, plus the fact
>that policy information in additional extensions is generally deprecated.
>So a qualifier is the only possible solution, if defined by PKIX, since the
>semantics then is defined by the associated policy and not by the
>specification.
>
>
>But, what you say also makes sense and maybe we should not do anything at all.
>
>At least... for the purpose of combining policy OID:s, I agree that using
>policy qualifiers is NOT a good idea. I never really liked it but I wanted
>comments on this in order to see it straight. 
>
>Steve, do you have any comment on this as well?
>
>/Stefan
>
>
>
>At 12:29 1999-06-17 -0400, Russ Housley wrote:
>>Stefan & Denis:
>>
>>Persoanally, I really dislike policy qualifiers.  They have a negative
>>imapct on interoperability.  If a policy is specified by an OID, then the
>>cert path validation does not need to know any details of that policy.  On
>>the other hand, when qualifiers are used, cert path validation must
>>understand the syntax and possibly the semantics of the qualifier.
>>
>>How does one get every implementation, especially mass market software
>>implementations, to support a particular policy qualifier?  Beats me.  That
>>is why they cause interoperability problems.
>>
>>In drafting RFC 2459, I suggested that policy qualifiers be forbidden.
>>Others disagreed, so we have a compromise position documented in RFC 2459.
>>It says:
>>
>>   To promote interoperability, this profile RECOMMENDS that policy
>>   information terms consist of only an OID.  Where an OID alone is
>>   insufficient, this profile strongly recommends that use of qualifiers
>>   be limited to those identified in this section.
>>
>>A small set of policy qualifiers was included with the hope that all
>>implementations would include support for them.
>>
>>So, my advice is to avoid policy qualifiers.
>>
>>Russ
>>
>>
>>At 01:34 PM 6/17/99 +0200, Stefan Santesson wrote:
>>>Denis,
>>>
>>>I hope you don't mind that I copy this to the list, but I think this
>>>clarification may be of public interest. 
>>>
>>>The problem has nothing to do with criticality.
>>>
>>>The only way to communicate (from a CA) to a relaying party (according to
>>>the semantics of the policy extension) that he/she must "verify that the
>>>expected OID is present" is by ONLY including that policy OID in the
>>>certificate.
>>>
>>>Further, the client of a relying party can't use the logical AND function
>>>when examining combinations of policies (regardless or criticality)
>>>
>>>I.e. follwoing X.509 and RFC 2459 path validation logic, you cant say to
>>>the client:
>>>
>>>1) The policy OID xxyy-qc-eu (EU QC OID) MUST be present AND;
>>>2) One of the policies xx-1, xx-2, xx-3, xx-4 or xx-5 (accepted
>>>CA-policies) MUST be present.
>>>
>>>Today, the only thing you can say to a client is:
>>>
>>>- Make sure that at least one of the policies xx-yy-eu, xx-1, xx-2, xx-3,
>>>xx-4 or xx-5 is present in each certificate in the validated path.
>>>
>>>So if you want to mandate presence of xx-yy-eu, you can't at the same time
>>>require presence of any other policy.
>>>
>>>
>>>/Stefan
>>>
>>>At 01:07 PM 6/17/99 +0200, you wrote:
>>>>Stefan,
>>>>
>>>>This is response where I have NOT copied the PKIX mailing list.
>>>>
>>>>> X.509 does not allow inclusion of several policy OID:s in a certificate
>>>>> with the meaning that the relying party MUST accept more than one.
>>>>>
>>>>> X.509, section "12.2.2.6  Certificate policies field" states:
>>>>>
>>>>> "If the extension is flagged critical, it indicates that the certificate
>>>>> shall only be used for the purpose, and in accordance with the rules
>>>>> implied by ONE of the indicated certificate policies. The rules of a
>>>>> particular policy may require the certificate-using system to process the
>>>>> qualifier value in a particular way."
>>>>
>>>>Nothing in the Directive mandates that the certificate shall only be
>used for
>>>>the Directive.
>>>>The Policy OID does not need to be made critical. However the receiver must
>>>>verify that the expected OID is present.
>>>>
>>>>This solves the problem, in a fairly different way. :-)
>>>>
>>>>Denis
>>>>
>>>>
>>>>> First of all... This logic is not clearly stated in RFC 2459  section
>>>>> 4.3.1.5. This is a problem since RFC 2459 implicitly requires this
>logic in
>>>>> order to comply with the basic path validation logic stated in
section 6.1
>>>>>
>>>>> Secondly... This logic may impose a problem under some circumstances.
>>>>>
>>>>> This cause problems for the EU-standardization initiative as they have
>>>>> discussed a solution with a EU-defined policy OID stating that the
>>>>> certificate is a "Qualified Certificate" according to the EU-directive.
>>>>> Such statement would then have to be combined with a CA specific policy
>>OID.
>>>>>
>>>>> This is not the only field where there has been discussions related to
>>>>> "combine" several policy OID:s in order to formulate the complete policy
>>>>> statement by the CA. The advantage of this could be the fact that some
>>>>> policy OID's could be well defined and commonly understood (as some EU
>>>>> defined statements)
>>>>>
>>>>> One general solution to this problem could be define a policy qualifier
>>>>> where the CA can enter policy OID:s that have to be accepted in
>combination
>>>>> with the "parent" policy.
>>>>>
>>>>> This could then be processed within the current path logic of X.509 and
>>>>> RFC2459.
>>>>>
>>>>> My questions related to this solution is:
>>>>>
>>>>> - Would this be a desired solution to the problem?
>>>>> - If so, where should it be specified?
>>>>>
>>>>> It could be specified in the QC draft, but since this is a general
>problem,
>>>>> it could be better to define it in RFC 2459 (next issue).
>>>>>
>>>>> Comments?
>>>>>
>>>>> /Stefan
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> Stefan Santesson                <[e-mail]>
>>>>> Accurata Systemsäkerhet AB      http://www.accurata.se
>>>>> Slagthuset                      Tel. [phone]
>>>>> 211 20  Malmö                   Fax. [phone]
>>>>> Sweden                        Mobile [phone]
>>>>>
>>>>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>>>> -------------------------------------------------------------------
>>>
>>>-------------------------------------------------------------------
>>>Stefan Santesson                <[e-mail]>
>>>Accurata Systemsäkerhet AB      http://www.accurata.se
>>>Slagthuset                      Tel. [phone]              
>>>211 20  Malmö                   Fax. [phone]              
>>>Sweden                        Mobile [phone]
>>>
>>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>>-------------------------------------------------------------------



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA04576; Fri, 18 Jun 1999 10:42:54 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 10:42:53 -0700
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA04553 for <[e-mail]>; Fri, 18 Jun 1999 10:42:52 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with SMTP id KAA07198; Fri, 18 Jun 1999 10:40:49 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 18 Jun 1999 10:57:45 -0400
To: "Todd S. Glassey - ELN" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Combination of policy OID:s
Cc: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>, <[e-mail]>
In-Reply-To: <002c01beb990$6682a620$930aff0c@brick>
References: <[e-mail]> <[e-mail]> <v04020a0fb383271ddc78@[128.89.0.110]> <[e-mail]> <41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 816437e92532d7120b23e9d7978dd831

Todd:

I believe that your proposal is in conflict with RFC 2459.  It says:

   4.2.1.5  Certificate Policies

      The certificate policies extension contains a sequence of one or more
      policy information terms, each of which consists of an object
      identifier (OID) and optional qualifiers.  These policy information
      terms indicate the policy under which the certificate has been issued
      and the purposes for which the certificate may be used.  Optional
      qualifiers, which may be present, are not expected to change the
      definition of the policy.

I think that the use of certificate policy qualifier you are proposing does
change the definition of the policy.  In my view, that means that a new
certificate policy OID should me assigned.

Russ


At 06:42 AM 6/18/99 -0700, Todd S. Glassey - ELN wrote:
>
>----- Original Message -----
>From: Russ Housley <[e-mail]>
>To: Denis Pinkas <[e-mail]>; Stefan Santesson
><[e-mail]>
>Cc: <[e-mail]>
>Sent: Thursday, June 17, 1999 9:29 AM
>Subject: Re: Combination of policy OID:s
>
>
>> Stefan & Denis:
>>
>> Persoanally, I really dislike policy qualifiers.  They have a negative
>> imapct on interoperability.  If a policy is specified by an OID, then the
>> cert path validation does not need to know any details of that policy.  On
>> the other hand, when qualifiers are used, cert path validation must
>> understand the syntax and possibly the semantics of the qualifier.
>>
>> How does one get every implementation, especially mass market software
>> implementations, to support a particular policy qualifier?  Beats me.
>That
>> is why they cause interoperability problems.
>
>Seems to me that there are many parts of the process that are application
>depedent Russ - leave it up to the apps that use the data fioelds
>
>>
>> In drafting RFC 2459, I suggested that policy qualifiers be forbidden.
>> Others disagreed, so we have a compromise position documented in RFC 2459.
>> It says:
>>
>>    To promote interoperability, this profile RECOMMENDS that policy
>>    information terms consist of only an OID.  Where an OID alone is
>>    insufficient, this profile strongly recommends that use of qualifiers
>>    be limited to those identified in this section.
>>
>> A small set of policy qualifiers was included with the hope that all
>> implementations would include support for them.
>>
>> So, my advice is to avoid policy qualifiers.
>>
>> Russ
>>
>
>>From the purist's point I agree with you, but there is also the issue of
>creating functional services that address commercial requirements, and
>becuase that is what pays the bills I suggest that perhaps there is a class
>of OIDs that can support Policy.
>
>One of the policy control OID Structures I would like to see is a mechanism
>to indicate a legal hierarchy. That is to say a representation of mechanism
>for legal jusridictions.
>
>This may be a subset of the policy OID concept but would be of tremendous
>value in the world of Online EC enabled business, and while it is strictly a
>"non challenging" technical aspect of EC it is a requirement none the less.
>
>Todd
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA03378; Fri, 18 Jun 1999 09:50:36 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 09:50:32 -0700
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03356 for <[e-mail]>; Fri, 18 Jun 1999 09:50:32 -0700 (PDT)
From: [e-mail]
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA74540; Fri, 18 Jun 1999 12:53:02 -0400
Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.03) with SMTP id MAA66712; Fri, 18 Jun 1999 12:53:07 -0400
Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256794.005CC033 ; Fri, 18 Jun 1999 12:53:05 -0400
X-Lotus-FromDomain: IBMUS
To: Stephen Farrell <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 18 Jun 1999 11:43:29 -0500
Subject: Re: X.509 ACs vs. SPKI?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: ac70c9d7efb9e93b62ee8441d2f8945e

My preference is for the use of CMS.  It's proven very useful for the Kerberos
PK-Init work in the CAT WG.  And, as you said, it's relatively easy to pick up
freeware or vendor S/MIME tooklits with CMS/PKCS#7 support.

David K. Hemsath, Team Lead (Security)
SecureWay SysMgmt/Architecture/Standards
IBM Corporation; 11400 Burnet Road; Austin, TX 78758 USA
Tel.: [phone] T/L 678; Fax: 0156
Pager: 800-946-4646/PIN=1400035/www.mobilecomm.com
[e-mail]



Stephen Farrell <[e-mail]> on 06/18/99 08:59:56 AM

To:   "Miklos, Sue A." <[e-mail]>
cc:   David Hemsath/Austin/IBM@IBMUS, [e-mail], [e-mail]
Subject:  Re: X.509 ACs vs. SPKI?






Sandi,

I did look at EncryptedAttributeSyntax when I was writing up the
draft but chose to go with CMS EnvelopedData for a few reasons:-

- CMS (or at least pkcs#7) is much more widely implemented today
- referencing CMS requires much less work for the group than
  profiling EncryptedAttributeSyntax from scratch
- I find it handy to use EnvelopedData, since I can check
  interop easily (I extract the ciphertext attribute value,
  put on some MIME headers and feed it to our S/MIME
  product)
- ignorance:-) Personally, I just don't understand what bytes
  to generate for things like:

      keyProtection PROTECTION-MAPPING ::=
               SECURITY-TRANSFORMATION {genEncryption}

However, if there were significant advantages from, or lots of
support for, moving to the X.501 syntax then I guess we should
consider it.

Regards,
Stephen.







Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA02267; Fri, 18 Jun 1999 08:22:08 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 08:22:05 -0700
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02244 for <[e-mail]>; Fri, 18 Jun 1999 08:22:04 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id RAA20279; Fri, 18 Jun 1999 17:24:01 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 18 Jun 1999 17:24:05 +0200
To: "Todd S. Glassey - ELN" <[e-mail]>, "Russ Housley" <[e-mail]>, Stephen Kent <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Combination of policy OID:s
Cc: <[e-mail]>
In-Reply-To: <002c01beb990$6682a620$930aff0c@brick>
References: <[e-mail]> <[e-mail]> <v04020a0fb383271ddc78@[128.89.0.110]> <[e-mail]> <41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA02245
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 6a6d5e164d0e88449d327ef310835931

I would like to discuss another solution which has surfaced during some
internal discussions.

We can conclude that there are several clear requirements statetd from the
"non-technical" society (mostly related to Qualified Certificates), which
demands inclusion of small explicit policy-related statements. The most
important one is "This is a Qualified Certificate according to EU-directive
Annex I and II"

They will just not go for the current policy oriented solution where everything
is said in just one OID, specific to the CA.

Putting additional OID:s in a policy qualifier can make a mess, so lets try to
avoid that.

Lets also assume that the policy OID:s used will be identifiers of COMPLETE
policy statements. I.e. they will work to support path validation as intended.

So additional OID-statements for speciffic policy related info would be
"redundant" but important by practical reasons (e.g. a common OID would cause
all compliant clients to express that "This is a Qualified Certificate
according to ......) 

So the alternative solution would be to create a new general extension for
"Qualified Certificate Statements" as follows:


   QualifiedCertifcateStatement  EXTENSION ::= {
      SYNTAX             QCStatementSyntax
      IDENTIFIED BY      id-qext-qCStatement }
 
    id-qext-qCStatement    OBJECT IDENTIFIER  ::= {id-qext xx}
  
    QCStatementSyntax ::= SEQUENCE OF QCStatement
   
    QCStatement ::= SEQUENCE {
        qCStatementId        OBJECTIDENTIFIER
        qCStatementInfo      ANY DEFINED BY qCStatementId OPTIONAL}


Within this extension it would be a free market to define and include
"redundant" explicit statements without detsroying path validation
interoperability.

Comments ?

Suggestions ?


/Stefan

At 06:42 AM 6/18/99 -0700, Todd S. Glassey - ELN wrote:
>
>----- Original Message -----
>From: Russ Housley <[e-mail]>
>To: Denis Pinkas <[e-mail]>; Stefan Santesson
><[e-mail]>
>Cc: <[e-mail]>
>Sent: Thursday, June 17, 1999 9:29 AM
>Subject: Re: Combination of policy OID:s
>
>
>> Stefan & Denis:
>>
>> Persoanally, I really dislike policy qualifiers.  They have a negative
>> imapct on interoperability.  If a policy is specified by an OID, then the
>> cert path validation does not need to know any details of that policy.  On
>> the other hand, when qualifiers are used, cert path validation must
>> understand the syntax and possibly the semantics of the qualifier.
>>
>> How does one get every implementation, especially mass market software
>> implementations, to support a particular policy qualifier?  Beats me.
>That
>> is why they cause interoperability problems.
>
>Seems to me that there are many parts of the process that are application
>depedent Russ - leave it up to the apps that use the data fioelds
>
>>
>> In drafting RFC 2459, I suggested that policy qualifiers be forbidden.
>> Others disagreed, so we have a compromise position documented in RFC 2459.
>> It says:
>>
>>    To promote interoperability, this profile RECOMMENDS that policy
>>    information terms consist of only an OID.  Where an OID alone is
>>    insufficient, this profile strongly recommends that use of qualifiers
>>    be limited to those identified in this section.
>>
>> A small set of policy qualifiers was included with the hope that all
>> implementations would include support for them.
>>
>> So, my advice is to avoid policy qualifiers.
>>
>> Russ
>>
>
>>From the purist's point I agree with you, but there is also the issue of
>creating functional services that address commercial requirements, and
>becuase that is what pays the bills I suggest that perhaps there is a class
>of OIDs that can support Policy.
>
>One of the policy control OID Structures I would like to see is a mechanism
>to indicate a legal hierarchy. That is to say a representation of mechanism
>for legal jusridictions.
>
>This may be a subset of the policy OID concept but would be of tremendous
>value in the world of Online EC enabled business, and while it is strictly a
>"non challenging" technical aspect of EC it is a requirement none the less.
>
>Todd

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA29817; Fri, 18 Jun 1999 05:33:17 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 05:33:14 -0700
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA29795 for <[e-mail]>; Fri, 18 Jun 1999 05:33:13 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA21373 for <[e-mail]>; Fri, 18 Jun 1999 08:35:49 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA21361 for <[e-mail]>; Fri, 18 Jun 1999 08:35:45 -0400 (EDT)
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 IAA27700 for <[e-mail]>; Fri, 18 Jun 1999 08:35:47 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (avenger53.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Fri, 18 Jun 1999 08:33:39 -0400
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <LX8NTXFR>; Fri, 18 Jun 1999 08:35:35 -0400
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: X.509 ACs vs. SPKI?
Date: Fri, 18 Jun 1999 08:35:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BEB987.10176AEA"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: aea23983c96e2cababcc49fb59b03511

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0">
<TITLE>RE: X.509 ACs vs. SPKI?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I've excerpted the following clause from the 1997 X.501 with respect to an encrypted attribute template.&nbsp; Any comments on the usefulness of the structure are most appreciated.</FONT></P>

<P><FONT SIZE=2>Sandi</FONT>
</P>

<P><FONT SIZE=2>18.2.2&nbsp; Encrypted Attribute Value Template</FONT>
<BR><FONT SIZE=2>If an encrypted variant is required of an existing directory attribute type, the following syntax is used:</FONT>
<BR><FONT SIZE=2>EncryptedAttributeSyntax {AttributeSyntax} ::= SEQUENCE {</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>keyInfo&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; SEQUENCE OF KeyIdOrProtectedKey,</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>encAlg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; AlgorithmIdentifier,</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>encValue&nbsp;&nbsp;&nbsp; &nbsp; ENCRYPTED { AttributeSyntax } }</FONT></P>

<P><FONT SIZE=2>KeyIdOrProtectedKey ::= SEQUENCE {</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>keyIdentifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [0]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KeyIdentifier OPTIONAL,</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>protectedKeys&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [1]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ProtectedKey OPTIONAL}</FONT></P>

<P><FONT SIZE=2>-At least one key identifier or protected key must be present </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; <FONT SIZE=2>}</FONT>
<BR><FONT SIZE=2>ProtectedKey&nbsp; ::=&nbsp; SEQUENCE&nbsp; {</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>authReaders&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AuthReaders,</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>-- if absent, use attribute in authorized reader entry</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>keyEncAlg&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; AlgorithmIdentifier&nbsp; OPTIONAL,</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>--&nbsp; algorithm to encrypt encAttrKey</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>encAttKey&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; EncAttKey&nbsp; }</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>-- confidentiality key protected with authorized user's</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>-- protection mechanism</FONT></P>

<P><FONT SIZE=2>AuthReaders&nbsp; ::=&nbsp; SEQUENCE OF Name</FONT>
<BR><FONT SIZE=2>EncAttKey ::= PROTECTED {SymmetricKey, keyProtection}</FONT>
<BR><FONT SIZE=2>SymmetricKey ::= BIT STRING</FONT>
<BR><FONT SIZE=2>keyProtection PROTECTION-MAPPING ::= </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>SECURITY-TRANSFORMATION {genEncryption}</FONT>
</P>

<P><FONT SIZE=2>NOTE -&nbsp; It is not reasonable that ordering matching rules or sub-string matching rules be used for encrypted attributes. It is also recommended that encrypted attributes are only defined for user attributes.</FONT></P>
<BR>

<P><FONT SIZE=2>AttributeSyntax is the clear text syntax of the attribute and EncryptedAttributeSyntax the syntax of the equivalent confidential attribute. </FONT></P>

<P><FONT SIZE=2>The keyIdentifier may be the identifier of a certified public key as held in the Subject Public Key Identifier extension field defined in ITU-T X.509| ISO/IEC 9594-8 Clause 12, or the identifier of a symmetric key and associated security control information. </FONT></P>

<P><FONT SIZE=2>The authReaders identifies those subjects who are permitted to retrieve the ProtectedKey. </FONT>
<BR><FONT SIZE=2>The keyEncAlg is the identifier for the algorithm used to encrypt the encAttKey, which is the&nbsp; identifier for the key used to apply the confidentiality service.</FONT></P>

<P><FONT SIZE=2>The genEncryption SECURITY-TRANSFORMATION defines the transformation which is used for key distribution. This is further defined in Clause 15.3.1. This transformation may be used with any encryption algorithm, including reversible public key algorithms and symmetric key algorithms. </FONT></P>

<P><FONT SIZE=2>NOTE -&nbsp; Key management, which includes key distribution, is within the purview of some administratively controlled security policy. Therefore, this specification does not constrain the genEncryption SECURITY-TRANSFORMATION in such a manner as to preclude the security manager of the DMD from specifying the precise details of key distribution. Furthermore, this specification does not require qualities of the genEncryption SECURITY-TRANSFORMATION such that these qualities preclude the use of particular key distribution mechanisms.</FONT></P>

<P><FONT SIZE=2>Support for an attribute does not imply support for the equivalent encrypted attribute.</FONT>
<BR><FONT SIZE=2>Where a user attribute is defined in this set of specifications, the object identifiers for the encrypted equivalent of that attribute are&nbsp; allocated in ITU-T X.520 | ISO/IEC 9594-6, Annex A.</FONT></P>

<P><FONT SIZE=2>18.2.3&nbsp; Attribute for Confidentiality Key</FONT>
<BR><FONT SIZE=2>If it is necessary to distribute information about the encryption that provides confidentiality of stored data, the following attribute shall be used:</FONT></P>

<P><FONT SIZE=2>confKeyInfo&nbsp; ATTRIBUTE&nbsp; ::=&nbsp; {</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>WITH SYNTAX&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ConfKeyInfo,</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>EQUALITY MATCHING-RULE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; readerAndKeyIDMatch</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>ID&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; id-at-confKeyInfo }</FONT></P>

<P><FONT SIZE=2>ConfKeyInfo&nbsp; ::=&nbsp; SEQUENCE&nbsp; {</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>keyIdentifierKeyIdentifier,&nbsp;&nbsp; </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>protectedKey&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ProtectedKey }</FONT></P>

<P><FONT SIZE=2>18.2.4&nbsp; Reader and Key Identifier Matching Rule</FONT>
<BR><FONT SIZE=2>A matching rule for a list of authorized readers and their associated keys is as follows:</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>readerAndKeyIDMatch MATCHING-RULE&nbsp; ::=&nbsp; {</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ReaderAndKeyIDAssertion</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>ID&nbsp;&nbsp;&nbsp; &nbsp; id-mr-readerAndKeyIDMatch&nbsp; }</FONT>
<BR><FONT SIZE=2>ReaderAndKeyIDAssertion&nbsp; ::=&nbsp; SEQUENCE {</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>keyIdentifierKeyIdentifier,</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>authReaders&nbsp;&nbsp; AuthReaders OPTIONAL&nbsp; }</FONT>
<BR><FONT SIZE=2>The matching rule returns a TRUE if all of the components that are present in the presented value match the corresponding components of the attribute value, as follows:</FONT></P>

<P><FONT SIZE=2>a)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; keyIdentifier matches if it is equal to the keyIdentifier component of the ProtectedKey in the stored attribute value;</FONT></P>

<P><FONT SIZE=2>b)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if present the authReaders matches if it is equal to one of the names in the authReaders component of the ProtectedKey in the stored attribute value.</FONT></P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: [e-mail] [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, June 17, 1999 5:07 PM</FONT>
<BR><FONT SIZE=2>To: [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: Re: X.509 ACs vs. SPKI?</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>Steven Kent wrote:</FONT>
</P>

<P><FONT SIZE=2>&gt;Denis,</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I tend to agree with Russ and Stephen on this one.&nbsp; It seems reasonable to</FONT>
<BR><FONT SIZE=2>&gt;be able to encrypt some parameters in an AC, for any of the application</FONT>
<BR><FONT SIZE=2>&gt;examples cited.&nbsp; If we want to be able to store ACs in directories without</FONT>
<BR><FONT SIZE=2>&gt;having to rely exclusively on directory access controls for</FONT>
<BR><FONT SIZE=2>&gt;confidentiality, then encryption of the attributes seems like a good</FONT>
<BR><FONT SIZE=2>&gt;mechanism. Yes, this may mean that the encrypted fields in the AC will be</FONT>
<BR><FONT SIZE=2>&gt;accessable by a limited set of entities, who may often be known at the time</FONT>
<BR><FONT SIZE=2>&gt;of AC creation. (Thye don't have to be know at this time, since it may be</FONT>
<BR><FONT SIZE=2>&gt;feasible to dynamically distributed the necessary decryption material</FONT>
<BR><FONT SIZE=2>&gt;later, e.g., incrementally.) I don't see this as a problem; often an AC may</FONT>
<BR><FONT SIZE=2>&gt;be quite constrained in the set of entities that will accept it anyway, if</FONT>
<BR><FONT SIZE=2>&gt;one views ACs as capabilities.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Steve</FONT>
</P>

<P><FONT SIZE=2>More generally, I think there will be many instances where</FONT>
<BR><FONT SIZE=2>selected entries in the directory will need to be cryptographically</FONT>
<BR><FONT SIZE=2>protected, *in addition* to robust directory access controls.</FONT>
<BR><FONT SIZE=2>This is especially true as more and more &quot;user account&quot; type</FONT>
<BR><FONT SIZE=2>of information is stored/_aggregated_ in the directory.</FONT>
</P>

<P><FONT SIZE=2>David K. Hemsath, Team Lead (Security)</FONT>
<BR><FONT SIZE=2>SecureWay SysMgmt/Architecture/Standards</FONT>
<BR><FONT SIZE=2>IBM Corporation; 11400 Burnet Road; Austin, TX 78758 USA</FONT>
<BR><FONT SIZE=2>Tel.: [phone] T/L 678; Fax: 0156</FONT>
<BR><FONT SIZE=2>Pager: 800-946-4646/PIN=1400035/www.mobilecomm.com</FONT>
<BR><FONT SIZE=2>[e-mail]</FONT>
</P>

</BODY>
</HTML>
>From ???@??? Fri Jun 18 08:22:32 1999
Received: from localhost (daemon@localhost)
	by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA00139;
	Fri, 18 Jun 1999 05:36:04 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 05:36:03 -0700
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 FAA00116
	for <[e-mail]>; Fri, 18 Jun 1999 05:36:02 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213])
	by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id OAA12246;
	Fri, 18 Jun 1999 14:35:23 +0200
Message-ID: <[e-mail]>
Date: Fri, 18 Jun 1999 14:37:01 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <[e-mail]> <v04020a0ab38ee48b48a9@[128.33.238.16]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 76c56089372a4b592934f572383165e8

Steve,

> Denis,
>
> I tend to agree with Russ and Stephen on this one.  It seems reasonable to
> be able to encrypt some parameters in an AC, for any of the application
> examples cited.

I have not seen a good argumentation for them, up to now. But the problem is
much deeper, as indicated after.

> If we want to be able to store ACs in directories without
> having to rely exclusively on directory access controls for
> confidentiality, then encryption of the attributes seems like a good
> mechanism.

Hum ! You are implictly supporting there a push model whereas I am a supportive
of a pull model where that functionality is not needed. With a push model you
not have have these kind of problems: no encryption and no access control. :-)


> Yes, this may mean that the encrypted fields in the AC will be
> accessable by a limited set of entities, who may often be known at the time
> of AC creation. (Thye don't have to be know at this time, since it may be
> feasible to dynamically distributed the necessary decryption material
> later, e.g., incrementally.) I don't see this as a problem; often an AC may
> be quite constrained in the set of entities that will accept it anyway, if
> one views ACs as capabilities.

Once again a push model is much simpler ! I do know that anyway some people
will go or have to go for a pull model, ... at their own risk. For the sake of
simplicity, I am advocating a basic document covering the basic needs of a push
model, which does not need the support of encrypted attributes. If some other
people want to go further, then I would have no problem to let them draft
another document. But this is a problem to be discussed both in the corridors
and the next PKIX meeting  at Oslo.   :-)

Denis

>
> Steve



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA00909; Fri, 18 Jun 1999 06:41:38 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 06:41:31 -0700
Received: from penguin.prod.itd.earthlink.net (penguin.prod.itd.earthlink.net [207.217.120.134]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA00887 for <[e-mail]>; Fri, 18 Jun 1999 06:41:31 -0700 (PDT)
Received: from brick (sdn-ar-004casfraP109.dialsprint.net [158.252.211.111]) by penguin.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id GAA15842; Fri, 18 Jun 1999 06:43:49 -0700 (PDT)
Message-ID: <002c01beb990$6682a620$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]><[e-mail]><v04020a0fb383271ddc78@[128.89.0.110]><[e-mail]><41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15><[e-mail]> <[e-mail]>
Subject: Re: Combination of policy OID:s
Date: Fri, 18 Jun 1999 06:42:22 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 380b3030b7128960ee8b60ea6c9e283b

----- Original Message -----
From: Russ Housley <[e-mail]>
To: Denis Pinkas <[e-mail]>; Stefan Santesson
<[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, June 17, 1999 9:29 AM
Subject: Re: Combination of policy OID:s


> Stefan & Denis:
>
> Persoanally, I really dislike policy qualifiers.  They have a negative
> imapct on interoperability.  If a policy is specified by an OID, then the
> cert path validation does not need to know any details of that policy.  On
> the other hand, when qualifiers are used, cert path validation must
> understand the syntax and possibly the semantics of the qualifier.
>
> How does one get every implementation, especially mass market software
> implementations, to support a particular policy qualifier?  Beats me.
That
> is why they cause interoperability problems.

Seems to me that there are many parts of the process that are application
depedent Russ - leave it up to the apps that use the data fioelds

>
> In drafting RFC 2459, I suggested that policy qualifiers be forbidden.
> Others disagreed, so we have a compromise position documented in RFC 2459.
> It says:
>
>    To promote interoperability, this profile RECOMMENDS that policy
>    information terms consist of only an OID.  Where an OID alone is
>    insufficient, this profile strongly recommends that use of qualifiers
>    be limited to those identified in this section.
>
> A small set of policy qualifiers was included with the hope that all
> implementations would include support for them.
>
> So, my advice is to avoid policy qualifiers.
>
> Russ
>

>From the purist's point I agree with you, but there is also the issue of
creating functional services that address commercial requirements, and
becuase that is what pays the bills I suggest that perhaps there is a class
of OIDs that can support Policy.

One of the policy control OID Structures I would like to see is a mechanism
to indicate a legal hierarchy. That is to say a representation of mechanism
for legal jusridictions.

This may be a subset of the policy OID concept but would be of tremendous
value in the world of Online EC enabled business, and while it is strictly a
"non challenging" technical aspect of EC it is a requirement none the less.

Todd




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA01272; Fri, 18 Jun 1999 07:03:29 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 07:03:28 -0700
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA01250 for <[e-mail]>; Fri, 18 Jun 1999 07:03:27 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Fri, 18 Jun 1999 14:59:59 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id OAA14413; Fri, 18 Jun 1999 14:59:57 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id OAA20543; Fri, 18 Jun 1999 14:59:56 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: "Miklos, Sue A." <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI? 
In-reply-to: Your message of "Fri, 18 Jun 1999 08:35:26 EDT." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 Jun 1999 14:59:56 +0100
From: Stephen Farrell <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: ea63d7dc8304f79e0df3ee1f165e3f40

Sandi,

I did look at EncryptedAttributeSyntax when I was writing up the
draft but chose to go with CMS EnvelopedData for a few reasons:-

- CMS (or at least pkcs#7) is much more widely implemented today
- referencing CMS requires much less work for the group than
  profiling EncryptedAttributeSyntax from scratch
- I find it handy to use EnvelopedData, since I can check
  interop easily (I extract the ciphertext attribute value,
  put on some MIME headers and feed it to our S/MIME 
  product)
- ignorance:-) Personally, I just don't understand what bytes
  to generate for things like:

	 keyProtection PROTECTION-MAPPING ::= 
			SECURITY-TRANSFORMATION {genEncryption}

However, if there were significant advantages from, or lots of
support for, moving to the X.501 syntax then I guess we should
consider it.

Regards,
Stephen.




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA28728; Fri, 18 Jun 1999 03:16:19 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 18 Jun 1999 03:16:12 -0700
Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.64.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA28703 for <[e-mail]>; Fri, 18 Jun 1999 03:16:07 -0700 (PDT)
Received: from npwork2 (e2c2p54.scotland.net [148.176.236.118]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id LAA03563; Fri, 18 Jun 1999 11:18:16 +0100 (BST)
From: "Nick Pope" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Russ Housley" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Policy Qualifierts     Was: Re: Combination of policy OID:s
Date: Fri, 18 Jun 1999 11:20:36 +0100
Message-ID: <002801beb974$3494e270$0500000a@npwork2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Importance: Normal
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 7cf941534a6aa7d35a8cb06df8147c52

Given that we cannot say whther a particular policy will be critical on not,
the problem with qualifiers applies to work on qualified certificates.

Nick

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: 17 June 1999 21:02
> To: Russ Housley; Stephen Kent
> Cc: [e-mail]
> Subject: Policy Qualifierts Was: Re: Combination of policy OID:s
>
>
> Russ,
>
> I agree in principle, but maybe not totally.
>
> Unless the policy extension is critical, it is perfectly OK for a
> client to
> ignore any qualifier. And qualifiers may have some advantages if used
> properly. They will however most certainly only make sense to those
> applications who are specifically trained for them.
>
> In Qualified Certificates we have discussed inclusion of a monetary value
> (to be used to specify a max reliance limit). It is proposed that this MAY
> be specified by a qualifier , defined by a ISO defined ASN.1 field.
>
> In this case the qualifier may make sense. It will only have to be
> understood by those application who have been trained to react upon this
> information. Further, the CA can see through that only
> specifically trained
> clients will accept the certificates by setting this extension to
> critical.
>
> Stephen Kent has expressed his preliminary support for this solution. At
> least our conclusion has been that qualifier is the only possible
> way if we
> should do anything at all. An extension can't be defined since it would be
> to complex to define the semantics of such extension anyway, plus the fact
> that policy information in additional extensions is generally deprecated.
> So a qualifier is the only possible solution, if defined by PKIX,
> since the
> semantics then is defined by the associated policy and not by the
> specification.
>
>
> But, what you say also makes sense and maybe we should not do
> anything at all.
>
> At least... for the purpose of combining policy OID:s, I agree that using
> policy qualifiers is NOT a good idea. I never really liked it but I wanted
> comments on this in order to see it straight.
>
> Steve, do you have any comment on this as well?
>
> /Stefan
>
>
>
> At 12:29 1999-06-17 -0400, Russ Housley wrote:
> >Stefan & Denis:
> >
> >Persoanally, I really dislike policy qualifiers.  They have a negative
> >imapct on interoperability.  If a policy is specified by an OID, then the
> >cert path validation does not need to know any details of that
> policy.  On
> >the other hand, when qualifiers are used, cert path validation must
> >understand the syntax and possibly the semantics of the qualifier.
> >
> >How does one get every implementation, especially mass market software
> >implementations, to support a particular policy qualifier?
> Beats me.  That
> >is why they cause interoperability problems.
> >
> >In drafting RFC 2459, I suggested that policy qualifiers be forbidden.
> >Others disagreed, so we have a compromise position documented in
> RFC 2459.
> >It says:
> >
> >   To promote interoperability, this profile RECOMMENDS that policy
> >   information terms consist of only an OID.  Where an OID alone is
> >   insufficient, this profile strongly recommends that use of qualifiers
> >   be limited to those identified in this section.
> >
> >A small set of policy qualifiers was included with the hope that all
> >implementations would include support for them.
> >
> >So, my advice is to avoid policy qualifiers.
> >
> >Russ
> >
> >
> >At 01:34 PM 6/17/99 +0200, Stefan Santesson wrote:
> >>Denis,
> >>
> >>I hope you don't mind that I copy this to the list, but I think this
> >>clarification may be of public interest.
> >>
> >>The problem has nothing to do with criticality.
> >>
> >>The only way to communicate (from a CA) to a relaying party
> (according to
> >>the semantics of the policy extension) that he/she must "verify that the
> >>expected OID is present" is by ONLY including that policy OID in the
> >>certificate.
> >>
> >>Further, the client of a relying party can't use the logical
> AND function
> >>when examining combinations of policies (regardless or criticality)
> >>
> >>I.e. follwoing X.509 and RFC 2459 path validation logic, you cant say to
> >>the client:
> >>
> >>1) The policy OID xxyy-qc-eu (EU QC OID) MUST be present AND;
> >>2) One of the policies xx-1, xx-2, xx-3, xx-4 or xx-5 (accepted
> >>CA-policies) MUST be present.
> >>
> >>Today, the only thing you can say to a client is:
> >>
> >>- Make sure that at least one of the policies xx-yy-eu, xx-1,
> xx-2, xx-3,
> >>xx-4 or xx-5 is present in each certificate in the validated path.
> >>
> >>So if you want to mandate presence of xx-yy-eu, you can't at
> the same time
> >>require presence of any other policy.
> >>
> >>
> >>/Stefan
> >>
> >>At 01:07 PM 6/17/99 +0200, you wrote:
> >>>Stefan,
> >>>
> >>>This is response where I have NOT copied the PKIX mailing list.
> >>>
> >>>> X.509 does not allow inclusion of several policy OID:s in a
> certificate
> >>>> with the meaning that the relying party MUST accept more than one.
> >>>>
> >>>> X.509, section "12.2.2.6  Certificate policies field" states:
> >>>>
> >>>> "If the extension is flagged critical, it indicates that the
> certificate
> >>>> shall only be used for the purpose, and in accordance with the rules
> >>>> implied by ONE of the indicated certificate policies. The rules of a
> >>>> particular policy may require the certificate-using system
> to process the
> >>>> qualifier value in a particular way."
> >>>
> >>>Nothing in the Directive mandates that the certificate shall only be
> used for
> >>>the Directive.
> >>>The Policy OID does not need to be made critical. However the
> receiver must
> >>>verify that the expected OID is present.
> >>>
> >>>This solves the problem, in a fairly different way. :-)
> >>>
> >>>Denis
> >>>
> >>>
> >>>> First of all... This logic is not clearly stated in RFC 2459  section
> >>>> 4.3.1.5. This is a problem since RFC 2459 implicitly requires this
> logic in
> >>>> order to comply with the basic path validation logic stated
> in section 6.1
> >>>>
> >>>> Secondly... This logic may impose a problem under some circumstances.
> >>>>
> >>>> This cause problems for the EU-standardization initiative as
> they have
> >>>> discussed a solution with a EU-defined policy OID stating that the
> >>>> certificate is a "Qualified Certificate" according to the
> EU-directive.
> >>>> Such statement would then have to be combined with a CA
> specific policy
> >OID.
> >>>>
> >>>> This is not the only field where there has been discussions
> related to
> >>>> "combine" several policy OID:s in order to formulate the
> complete policy
> >>>> statement by the CA. The advantage of this could be the fact
> that some
> >>>> policy OID's could be well defined and commonly understood
> (as some EU
> >>>> defined statements)
> >>>>
> >>>> One general solution to this problem could be define a
> policy qualifier
> >>>> where the CA can enter policy OID:s that have to be accepted in
> combination
> >>>> with the "parent" policy.
> >>>>
> >>>> This could then be processed within the current path logic
> of X.509 and
> >>>> RFC2459.
> >>>>
> >>>> My questions related to this solution is:
> >>>>
> >>>> - Would this be a desired solution to the problem?
> >>>> - If so, where should it be specified?
> >>>>
> >>>> It could be specified in the QC draft, but since this is a general
> problem,
> >>>> it could be better to define it in RFC 2459 (next issue).
> >>>>
> >>>> Comments?
> >>>>
> >>>> /Stefan
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> Stefan Santesson                <[e-mail]>
> >>>> Accurata Systemsäkerhet AB      http://www.accurata.se
> >>>> Slagthuset                      Tel. [phone]
> >>>> 211 20  Malmö                   Fax. [phone]
> >>>> Sweden                        Mobile [phone]
> >>>>
> >>>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> >>>> -------------------------------------------------------------------
> >>
> >>-------------------------------------------------------------------
> >>Stefan Santesson                <[e-mail]>
> >>Accurata Systemsäkerhet AB      http://www.accurata.se
> >>Slagthuset                      Tel. [phone]
> >>211 20  Malmö                   Fax. [phone]
> >>Sweden                        Mobile [phone]
> >>
> >>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> >>-------------------------------------------------------------------
>
>



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA22107; Thu, 17 Jun 1999 17:20:31 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 17:20:23 -0700
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA22085 for <[e-mail]>; Thu, 17 Jun 1999 17:20:21 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <M6BT2W4R>; Fri, 18 Jun 1999 10:22:49 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC1077E5@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Charles Moore'" <[e-mail]>, Denis Pinkas <[e-mail]>, Stefan Santesson <[e-mail]>, Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: RE: Combination of policy OID:s
Date: Fri, 18 Jun 1999 10:22:48 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 6a11044d78fae2dce3eb04198c5d882b

> -----Original Message-----
> From:	Charles Moore 
> Sent:	Friday, June 18, 1999 7:58 AM
> To:	Denis Pinkas; Stefan Santesson; Russ Housley
> Cc:	[e-mail]
> Subject:	Re: Combination of policy OID:s
> 
> 
> ----- Original Message -----
> From: Russ Housley <[e-mail]>
> To: Denis Pinkas <[e-mail]>; Stefan Santesson
> <[e-mail]>
> Cc: <[e-mail]>
> Sent: Friday, June 18, 1999 2:29 AM
> Subject: Re: Combination of policy OID:s
> 
> 
> Stefan & Denis:
> 
> Persoanally, I really dislike policy qualifiers.  They have a negative
> imapct on interoperability.
> 
	snip

	Charles, dont you worry about that, its a small issue  -
interoperability will be even more difficult now anyway - Msoft (active
directory) have redefined TOP using the ISO-ITU ID - see the LDAP ext
list.

	Q: When is an OID and what it represents trusted - ie this has
to be an info assurance issue.

	I read OID from A it comes back with 60 +  attributes and when I
read the same OID from B it comes back with 1. :-)

	Oh well 

	regards alan



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA20747; Thu, 17 Jun 1999 14:55:25 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 14:55:23 -0700
Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20724 for <[e-mail]>; Thu, 17 Jun 1999 14:55:21 -0700 (PDT)
Message-ID: <003c01beb90c$6f2e1630$[e-mail]>
From: "Charles Moore" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]><[e-mail]><v04020a0fb383271ddc78@[128.89.0.110]><[e-mail]><41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15><[e-mail]> <[e-mail]>
Subject: Re: Combination of policy OID:s
Date: Fri, 18 Jun 1999 07:57:41 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 38b38e3c37a3a691f33530896f320ada

----- Original Message -----
From: Russ Housley <[e-mail]>
To: Denis Pinkas <[e-mail]>; Stefan Santesson
<[e-mail]>
Cc: <[e-mail]>
Sent: Friday, June 18, 1999 2:29 AM
Subject: Re: Combination of policy OID:s


Stefan & Denis:

Persoanally, I really dislike policy qualifiers.  They have a negative
imapct on interoperability.

cm> Interoperability is a two edged sord, higher semantics can be benifital
to interoperability, but is a bit like a VPN it can limit the scope f
interoperabiltiy, but in many business situations this is the norm.

If a policy is specified by an OID, then the
cert path validation does not need to know any details of that policy.

cm> Would disagree, on this point, if you dont know the rules to process the
path you realy dont know what you are accepting as"valid".  Once again
depends on the scope of interoperability, the no rules approach is fine for
most of the non value transations that are more privacy based than anything
else.

On
the other hand, when qualifiers are used, cert path validation must
understand the syntax and possibly the semantics of the qualifier.
cm> See above, for anything usefull this is needed anyway.


How does one get every implementation, especially mass market software
implementations, to support a particular policy qualifier?  Beats me.  That
is why they cause interoperability problems.

cm> We have been isusing certs with policy qualifiers for some time, the
results... almost all end applications dont understand policy OID so happly
pass qualifier OIDs without problem. b) for those that care these have
policy enforcement processing that takes care of the policy and qualifier
issues. As product mature more semantic content and hence syntax can be
useful within communties, thse communities may start out small and grow as
required ( how interoperability actually happens).


In drafting RFC 2459, I suggested that policy qualifiers be forbidden.

cm> I would STRONGLY disagree with this approach, we ahve deployed
implementations that make use of these, and candemonstarte this does not
limit or degrade your view of ineroperabiltiy, but allows us and our
customers to support their business needs.


Others disagreed, so we have a compromise position documented in RFC 2459.
It says:

   To promote interoperability, this profile RECOMMENDS that policy
   information terms consist of only an OID.  Where an OID alone is
   insufficient, this profile strongly recommends that use of qualifiers
   be limited to those identified in this section.

cm> Disagree as above.....

A small set of policy qualifiers was included with the hope that all
implementations would include support for them.

So, my advice is to avoid policy qualifiers.

cm> My advise is to use what supports the business need, the technology s
NOt the driver here, dont confuse a lack of product and market maturity with
infrastruture support. This is not the time to limit functionality, when the
applications for this stuff is just begining to happen, especially when it
has not negative aspects for ineroperability...


Russ


At 01:34 PM 6/17/99 +0200, Stefan Santesson wrote:
>Denis,
>
>I hope you don't mind that I copy this to the list, but I think this
>clarification may be of public interest.
>
>The problem has nothing to do with criticality.
>
>The only way to communicate (from a CA) to a relaying party (according to
>the semantics of the policy extension) that he/she must "verify that the
>expected OID is present" is by ONLY including that policy OID in the
>certificate.
>
>Further, the client of a relying party can't use the logical AND function
>when examining combinations of policies (regardless or criticality)
>
>I.e. follwoing X.509 and RFC 2459 path validation logic, you cant say to
>the client:
>
>1) The policy OID xxyy-qc-eu (EU QC OID) MUST be present AND;
>2) One of the policies xx-1, xx-2, xx-3, xx-4 or xx-5 (accepted
>CA-policies) MUST be present.
>
>Today, the only thing you can say to a client is:
>
>- Make sure that at least one of the policies xx-yy-eu, xx-1, xx-2, xx-3,
>xx-4 or xx-5 is present in each certificate in the validated path.
>
>So if you want to mandate presence of xx-yy-eu, you can't at the same time
>require presence of any other policy.
>
>
>/Stefan
>
>At 01:07 PM 6/17/99 +0200, you wrote:
>>Stefan,
>>
>>This is response where I have NOT copied the PKIX mailing list.
>>
>>> X.509 does not allow inclusion of several policy OID:s in a certificate
>>> with the meaning that the relying party MUST accept more than one.
>>>
>>> X.509, section "12.2.2.6  Certificate policies field" states:
>>>
>>> "If the extension is flagged critical, it indicates that the certificate
>>> shall only be used for the purpose, and in accordance with the rules
>>> implied by ONE of the indicated certificate policies. The rules of a
>>> particular policy may require the certificate-using system to process
the
>>> qualifier value in a particular way."
>>
>>Nothing in the Directive mandates that the certificate shall only be used
for
>>the Directive.
>>The Policy OID does not need to be made critical. However the receiver
must
>>verify that the expected OID is present.
>>
>>This solves the problem, in a fairly different way. :-)
>>
>>Denis
>>
>>
>>> First of all... This logic is not clearly stated in RFC 2459  section
>>> 4.3.1.5. This is a problem since RFC 2459 implicitly requires this logic
in
>>> order to comply with the basic path validation logic stated in section
6.1
>>>
>>> Secondly... This logic may impose a problem under some circumstances.
>>>
>>> This cause problems for the EU-standardization initiative as they have
>>> discussed a solution with a EU-defined policy OID stating that the
>>> certificate is a "Qualified Certificate" according to the EU-directive.
>>> Such statement would then have to be combined with a CA specific policy
OID.
>>>
>>> This is not the only field where there has been discussions related to
>>> "combine" several policy OID:s in order to formulate the complete policy
>>> statement by the CA. The advantage of this could be the fact that some
>>> policy OID's could be well defined and commonly understood (as some EU
>>> defined statements)
>>>
>>> One general solution to this problem could be define a policy qualifier
>>> where the CA can enter policy OID:s that have to be accepted in
combination
>>> with the "parent" policy.
>>>
>>> This could then be processed within the current path logic of X.509 and
>>> RFC2459.
>>>
>>> My questions related to this solution is:
>>>
>>> - Would this be a desired solution to the problem?
>>> - If so, where should it be specified?
>>>
>>> It could be specified in the QC draft, but since this is a general
problem,
>>> it could be better to define it in RFC 2459 (next issue).
>>>
>>> Comments?
>>>
>>> /Stefan
>>>
>>> -------------------------------------------------------------------
>>> Stefan Santesson                <[e-mail]>
>>> Accurata Systemsäkerhet AB      http://www.accurata.se
>>> Slagthuset                      Tel. [phone]
>>> 211 20  Malmö                   Fax. [phone]
>>> Sweden                        Mobile [phone]
>>>
>>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>> -------------------------------------------------------------------
>
>-------------------------------------------------------------------
>Stefan Santesson                <[e-mail]>
>Accurata Systemsäkerhet AB      http://www.accurata.se
>Slagthuset                      Tel. [phone]
>211 20  Malmö                   Fax. [phone]
>Sweden                        Mobile [phone]
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA20331; Thu, 17 Jun 1999 14:10:14 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 14:09:59 -0700
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20301 for <[e-mail]>; Thu, 17 Jun 1999 14:09:59 -0700 (PDT)
From: [e-mail]
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA68964 for <[e-mail]>; Thu, 17 Jun 1999 17:12:25 -0400
Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.03) with SMTP id RAA48884 for <[e-mail]>; Thu, 17 Jun 1999 17:12:29 -0400
Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256793.00747E3E ; Thu, 17 Jun 1999 17:12:24 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 17 Jun 1999 16:06:52 -0500
Subject: Re: X.509 ACs vs. SPKI?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 022235f07c40b346881cc2dd883470d3

Steven Kent wrote:

>Denis,
>
>I tend to agree with Russ and Stephen on this one.  It seems reasonable to
>be able to encrypt some parameters in an AC, for any of the application
>examples cited.  If we want to be able to store ACs in directories without
>having to rely exclusively on directory access controls for
>confidentiality, then encryption of the attributes seems like a good
>mechanism. Yes, this may mean that the encrypted fields in the AC will be
>accessable by a limited set of entities, who may often be known at the time
>of AC creation. (Thye don't have to be know at this time, since it may be
>feasible to dynamically distributed the necessary decryption material
>later, e.g., incrementally.) I don't see this as a problem; often an AC may
>be quite constrained in the set of entities that will accept it anyway, if
>one views ACs as capabilities.
>
>Steve

More generally, I think there will be many instances where
selected entries in the directory will need to be cryptographically
protected, *in addition* to robust directory access controls.
This is especially true as more and more "user account" type
of information is stored/_aggregated_ in the directory.

David K. Hemsath, Team Lead (Security)
SecureWay SysMgmt/Architecture/Standards
IBM Corporation; 11400 Burnet Road; Austin, TX 78758 USA
Tel.: [phone] T/L 678; Fax: 0156
Pager: 800-946-4646/PIN=1400035/www.mobilecomm.com
[e-mail]




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA19589; Thu, 17 Jun 1999 13:01:41 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 13:01:40 -0700
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 NAA19567 for <[e-mail]>; Thu, 17 Jun 1999 13:01:40 -0700 (PDT)
Received: from [128.33.238.33] (TC033.BBN.COM [128.33.238.33]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA14160; Thu, 17 Jun 1999 16:04:08 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a0ab38ee48b48a9@[128.33.238.16]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 17 Jun 1999 13:50:42 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail]
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0c53d9d0ca14a647259561c5e25deb0b

Denis,

I tend to agree with Russ and Stephen on this one.  It seems reasonable to
be able to encrypt some parameters in an AC, for any of the application
examples cited.  If we want to be able to store ACs in directories without
having to rely exclusively on directory access controls for
confidentiality, then encryption of the attributes seems like a good
mechanism. Yes, this may mean that the encrypted fields in the AC will be
accessable by a limited set of entities, who may often be known at the time
of AC creation. (Thye don't have to be know at this time, since it may be
feasible to dynamically distributed the necessary decryption material
later, e.g., incrementally.) I don't see this as a problem; often an AC may
be quite constrained in the set of entities that will accept it anyway, if
one views ACs as capabilities.

Steve


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA19517; Thu, 17 Jun 1999 12:59:33 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 12:58:26 -0700
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19493 for <[e-mail]>; Thu, 17 Jun 1999 12:58:24 -0700 (PDT)
Received: from foo.telia.se (t4o68p93.telia.com [62.20.139.213]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id WAA10165; Thu, 17 Jun 1999 22:00:45 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 17 Jun 1999 22:01:43 +0200
To: Russ Housley <[e-mail]>, Stephen Kent <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Policy Qualifierts     Was: Re: Combination of policy OID:s
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <v04020a0fb383271ddc78@[128.89.0.110]> <[e-mail]> <41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA19494
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 80487e0a08578b0e293da8c4d513f311

Russ,

I agree in principle, but maybe not totally.

Unless the policy extension is critical, it is perfectly OK for a client to
ignore any qualifier. And qualifiers may have some advantages if used
properly. They will however most certainly only make sense to those
applications who are specifically trained for them.

In Qualified Certificates we have discussed inclusion of a monetary value
(to be used to specify a max reliance limit). It is proposed that this MAY
be specified by a qualifier , defined by a ISO defined ASN.1 field.

In this case the qualifier may make sense. It will only have to be
understood by those application who have been trained to react upon this
information. Further, the CA can see through that only specifically trained
clients will accept the certificates by setting this extension to critical.

Stephen Kent has expressed his preliminary support for this solution. At
least our conclusion has been that qualifier is the only possible way if we
should do anything at all. An extension can't be defined since it would be
to complex to define the semantics of such extension anyway, plus the fact
that policy information in additional extensions is generally deprecated.
So a qualifier is the only possible solution, if defined by PKIX, since the
semantics then is defined by the associated policy and not by the
specification.


But, what you say also makes sense and maybe we should not do anything at all.

At least... for the purpose of combining policy OID:s, I agree that using
policy qualifiers is NOT a good idea. I never really liked it but I wanted
comments on this in order to see it straight. 

Steve, do you have any comment on this as well?

/Stefan



At 12:29 1999-06-17 -0400, Russ Housley wrote:
>Stefan & Denis:
>
>Persoanally, I really dislike policy qualifiers.  They have a negative
>imapct on interoperability.  If a policy is specified by an OID, then the
>cert path validation does not need to know any details of that policy.  On
>the other hand, when qualifiers are used, cert path validation must
>understand the syntax and possibly the semantics of the qualifier.
>
>How does one get every implementation, especially mass market software
>implementations, to support a particular policy qualifier?  Beats me.  That
>is why they cause interoperability problems.
>
>In drafting RFC 2459, I suggested that policy qualifiers be forbidden.
>Others disagreed, so we have a compromise position documented in RFC 2459.
>It says:
>
>   To promote interoperability, this profile RECOMMENDS that policy
>   information terms consist of only an OID.  Where an OID alone is
>   insufficient, this profile strongly recommends that use of qualifiers
>   be limited to those identified in this section.
>
>A small set of policy qualifiers was included with the hope that all
>implementations would include support for them.
>
>So, my advice is to avoid policy qualifiers.
>
>Russ
>
>
>At 01:34 PM 6/17/99 +0200, Stefan Santesson wrote:
>>Denis,
>>
>>I hope you don't mind that I copy this to the list, but I think this
>>clarification may be of public interest. 
>>
>>The problem has nothing to do with criticality.
>>
>>The only way to communicate (from a CA) to a relaying party (according to
>>the semantics of the policy extension) that he/she must "verify that the
>>expected OID is present" is by ONLY including that policy OID in the
>>certificate.
>>
>>Further, the client of a relying party can't use the logical AND function
>>when examining combinations of policies (regardless or criticality)
>>
>>I.e. follwoing X.509 and RFC 2459 path validation logic, you cant say to
>>the client:
>>
>>1) The policy OID xxyy-qc-eu (EU QC OID) MUST be present AND;
>>2) One of the policies xx-1, xx-2, xx-3, xx-4 or xx-5 (accepted
>>CA-policies) MUST be present.
>>
>>Today, the only thing you can say to a client is:
>>
>>- Make sure that at least one of the policies xx-yy-eu, xx-1, xx-2, xx-3,
>>xx-4 or xx-5 is present in each certificate in the validated path.
>>
>>So if you want to mandate presence of xx-yy-eu, you can't at the same time
>>require presence of any other policy.
>>
>>
>>/Stefan
>>
>>At 01:07 PM 6/17/99 +0200, you wrote:
>>>Stefan,
>>>
>>>This is response where I have NOT copied the PKIX mailing list.
>>>
>>>> X.509 does not allow inclusion of several policy OID:s in a certificate
>>>> with the meaning that the relying party MUST accept more than one.
>>>>
>>>> X.509, section "12.2.2.6  Certificate policies field" states:
>>>>
>>>> "If the extension is flagged critical, it indicates that the certificate
>>>> shall only be used for the purpose, and in accordance with the rules
>>>> implied by ONE of the indicated certificate policies. The rules of a
>>>> particular policy may require the certificate-using system to process the
>>>> qualifier value in a particular way."
>>>
>>>Nothing in the Directive mandates that the certificate shall only be
used for
>>>the Directive.
>>>The Policy OID does not need to be made critical. However the receiver must
>>>verify that the expected OID is present.
>>>
>>>This solves the problem, in a fairly different way. :-)
>>>
>>>Denis
>>>
>>>
>>>> First of all... This logic is not clearly stated in RFC 2459  section
>>>> 4.3.1.5. This is a problem since RFC 2459 implicitly requires this
logic in
>>>> order to comply with the basic path validation logic stated in section 6.1
>>>>
>>>> Secondly... This logic may impose a problem under some circumstances.
>>>>
>>>> This cause problems for the EU-standardization initiative as they have
>>>> discussed a solution with a EU-defined policy OID stating that the
>>>> certificate is a "Qualified Certificate" according to the EU-directive.
>>>> Such statement would then have to be combined with a CA specific policy
>OID.
>>>>
>>>> This is not the only field where there has been discussions related to
>>>> "combine" several policy OID:s in order to formulate the complete policy
>>>> statement by the CA. The advantage of this could be the fact that some
>>>> policy OID's could be well defined and commonly understood (as some EU
>>>> defined statements)
>>>>
>>>> One general solution to this problem could be define a policy qualifier
>>>> where the CA can enter policy OID:s that have to be accepted in
combination
>>>> with the "parent" policy.
>>>>
>>>> This could then be processed within the current path logic of X.509 and
>>>> RFC2459.
>>>>
>>>> My questions related to this solution is:
>>>>
>>>> - Would this be a desired solution to the problem?
>>>> - If so, where should it be specified?
>>>>
>>>> It could be specified in the QC draft, but since this is a general
problem,
>>>> it could be better to define it in RFC 2459 (next issue).
>>>>
>>>> Comments?
>>>>
>>>> /Stefan
>>>>
>>>> -------------------------------------------------------------------
>>>> Stefan Santesson                <[e-mail]>
>>>> Accurata Systemsäkerhet AB      http://www.accurata.se
>>>> Slagthuset                      Tel. [phone]
>>>> 211 20  Malmö                   Fax. [phone]
>>>> Sweden                        Mobile [phone]
>>>>
>>>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>>> -------------------------------------------------------------------
>>
>>-------------------------------------------------------------------
>>Stefan Santesson                <[e-mail]>
>>Accurata Systemsäkerhet AB      http://www.accurata.se
>>Slagthuset                      Tel. [phone]              
>>211 20  Malmö                   Fax. [phone]              
>>Sweden                        Mobile [phone]
>>
>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>-------------------------------------------------------------------



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA18432; Thu, 17 Jun 1999 11:38:35 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 11:38:27 -0700
Received: from irwell.zetnet.co.uk ([e-mail] [194.247.47.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18410 for <[e-mail]>; Thu, 17 Jun 1999 11:38:26 -0700 (PDT)
Received: from dwc-acer (manr-049.dialup.zetnet.co.uk [194.247.43.179]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA12183; Thu, 17 Jun 1999 19:40:50 +0100
Message-Id: <[e-mail]>
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: "John Hughes" <[e-mail]>
Date: Thu, 17 Jun 1999 19:43:35 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: New ID on LDAPv3
Reply-to: [e-mail]
CC: [e-mail]
Priority: normal
In-reply-to: <002001beb8c0$56b35ee0$[e-mail]>
References: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 01c2a87edde4c3851cab02b0a3976e12

From:           	"John Hughes" <[e-mail]>
To:             	<[e-mail]>
Subject:        	RE: New ID on LDAPv3
Date sent:      	Thu, 17 Jun 1999 13:53:04 +0100

> David,
> 
> the one thing missing from LDAPv3 is the ability to retrieve a given value
> in a multi-value attribute.
> 
> Some PKI products need this!

Good point, I will add this to the next version.

David

> 
> John
> 
> 
> 
> > -----Original Message-----
> > From: David Chadwick [mailto:[e-mail]]
> > Sent: 15 June 1999 18:36
> > To: [e-mail]
> > Subject: New ID on LDAPv3
> >
> >
> > Folks,
> >
> > A new ID has just been (or is just about to be) published
> >
> > <draft-chadwick-pkixldap-v3-00.txt>
> >
> > This gives a profile for the use of LDAPv3 to retrieve X.509
> > certificates and CRLs.
> >
> > I append a copy to this message. I believe there will be a brief
> > discussion of this on the Wednesday morning in Oslo> > 

> > David
> >
> > ***************************************************
> >
> > David Chadwick
> > IT Institute, University of Salford, Salford M5 4WT
> > Tel [phone]  Fax [phone]
> > *NEW* Mobile [phone] *NEW*
> > Email [e-mail]
> > Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> > Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> > Entrust key validation string MLJ9-DU5T-HV8J
> >
> > ***************************************************
> >
> >
> 
> 


***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
*NEW* Mobile [phone] *NEW*
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA16665; Thu, 17 Jun 1999 09:30:57 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 09:30:44 -0700
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA16641 for <[e-mail]>; Thu, 17 Jun 1999 09:30:43 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with SMTP id JAA16022; Thu, 17 Jun 1999 09:28:39 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 17 Jun 1999 12:29:46 -0400
To: Denis Pinkas <[e-mail]>, Stefan Santesson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Combination of policy OID:s
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <v04020a0fb383271ddc78@[128.89.0.110]> <[e-mail]> <41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 5aae515e1474ffb44329262b4fdb381b

Stefan & Denis:

Persoanally, I really dislike policy qualifiers.  They have a negative
imapct on interoperability.  If a policy is specified by an OID, then the
cert path validation does not need to know any details of that policy.  On
the other hand, when qualifiers are used, cert path validation must
understand the syntax and possibly the semantics of the qualifier.

How does one get every implementation, especially mass market software
implementations, to support a particular policy qualifier?  Beats me.  That
is why they cause interoperability problems.

In drafting RFC 2459, I suggested that policy qualifiers be forbidden.
Others disagreed, so we have a compromise position documented in RFC 2459.
It says:

   To promote interoperability, this profile RECOMMENDS that policy
   information terms consist of only an OID.  Where an OID alone is
   insufficient, this profile strongly recommends that use of qualifiers
   be limited to those identified in this section.

A small set of policy qualifiers was included with the hope that all
implementations would include support for them.

So, my advice is to avoid policy qualifiers.

Russ


At 01:34 PM 6/17/99 +0200, Stefan Santesson wrote:
>Denis,
>
>I hope you don't mind that I copy this to the list, but I think this
>clarification may be of public interest. 
>
>The problem has nothing to do with criticality.
>
>The only way to communicate (from a CA) to a relaying party (according to
>the semantics of the policy extension) that he/she must "verify that the
>expected OID is present" is by ONLY including that policy OID in the
>certificate.
>
>Further, the client of a relying party can't use the logical AND function
>when examining combinations of policies (regardless or criticality)
>
>I.e. follwoing X.509 and RFC 2459 path validation logic, you cant say to
>the client:
>
>1) The policy OID xxyy-qc-eu (EU QC OID) MUST be present AND;
>2) One of the policies xx-1, xx-2, xx-3, xx-4 or xx-5 (accepted
>CA-policies) MUST be present.
>
>Today, the only thing you can say to a client is:
>
>- Make sure that at least one of the policies xx-yy-eu, xx-1, xx-2, xx-3,
>xx-4 or xx-5 is present in each certificate in the validated path.
>
>So if you want to mandate presence of xx-yy-eu, you can't at the same time
>require presence of any other policy.
>
>
>/Stefan
>
>At 01:07 PM 6/17/99 +0200, you wrote:
>>Stefan,
>>
>>This is response where I have NOT copied the PKIX mailing list.
>>
>>> X.509 does not allow inclusion of several policy OID:s in a certificate
>>> with the meaning that the relying party MUST accept more than one.
>>>
>>> X.509, section "12.2.2.6  Certificate policies field" states:
>>>
>>> "If the extension is flagged critical, it indicates that the certificate
>>> shall only be used for the purpose, and in accordance with the rules
>>> implied by ONE of the indicated certificate policies. The rules of a
>>> particular policy may require the certificate-using system to process the
>>> qualifier value in a particular way."
>>
>>Nothing in the Directive mandates that the certificate shall only be used for
>>the Directive.
>>The Policy OID does not need to be made critical. However the receiver must
>>verify that the expected OID is present.
>>
>>This solves the problem, in a fairly different way. :-)
>>
>>Denis
>>
>>
>>> First of all... This logic is not clearly stated in RFC 2459  section
>>> 4.3.1.5. This is a problem since RFC 2459 implicitly requires this logic in
>>> order to comply with the basic path validation logic stated in section 6.1
>>>
>>> Secondly... This logic may impose a problem under some circumstances.
>>>
>>> This cause problems for the EU-standardization initiative as they have
>>> discussed a solution with a EU-defined policy OID stating that the
>>> certificate is a "Qualified Certificate" according to the EU-directive.
>>> Such statement would then have to be combined with a CA specific policy
OID.
>>>
>>> This is not the only field where there has been discussions related to
>>> "combine" several policy OID:s in order to formulate the complete policy
>>> statement by the CA. The advantage of this could be the fact that some
>>> policy OID's could be well defined and commonly understood (as some EU
>>> defined statements)
>>>
>>> One general solution to this problem could be define a policy qualifier
>>> where the CA can enter policy OID:s that have to be accepted in combination
>>> with the "parent" policy.
>>>
>>> This could then be processed within the current path logic of X.509 and
>>> RFC2459.
>>>
>>> My questions related to this solution is:
>>>
>>> - Would this be a desired solution to the problem?
>>> - If so, where should it be specified?
>>>
>>> It could be specified in the QC draft, but since this is a general problem,
>>> it could be better to define it in RFC 2459 (next issue).
>>>
>>> Comments?
>>>
>>> /Stefan
>>>
>>> -------------------------------------------------------------------
>>> Stefan Santesson                <[e-mail]>
>>> Accurata Systemsäkerhet AB      http://www.accurata.se
>>> Slagthuset                      Tel. [phone]
>>> 211 20  Malmö                   Fax. [phone]
>>> Sweden                        Mobile [phone]
>>>
>>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>> -------------------------------------------------------------------
>
>-------------------------------------------------------------------
>Stefan Santesson                <[e-mail]>
>Accurata Systemsäkerhet AB      http://www.accurata.se
>Slagthuset                      Tel. [phone]              
>211 20  Malmö                   Fax. [phone]              
>Sweden                        Mobile [phone]
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA17087; Thu, 17 Jun 1999 09:50:39 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 09:50:38 -0700
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17065 for <[e-mail]>; Thu, 17 Jun 1999 09:50:38 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id JAA03459; Thu, 17 Jun 1999 09:51:31 -0700 (PDT)
Received: from rhone (dhcp-3-128.engineering.valicert.com [192.168.3.128]) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id JAA15817; Thu, 17 Jun 1999 09:52:39 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Problem with RFC 2459?
Date: Thu, 17 Jun 1999 09:55:27 -0700
Message-ID: <001b01beb8e2$345a85e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: fbe4450fa5bf1644cf9d6ac7e430cfcf

Hi Russ,
    Yes, I suspected (from Dave's mail) that what I proposed wouldn't
be acceptable. However, Dave did suggest a great solution to the
problem - as long as the CA tells me the DistributionPointName
he will put in full CRLs (or none if he won't put any), I can
figure out full CRLs for a CA. That solves my issue.

Thanks,
Ambarish

P.S. Thanks Dave for the idea.

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


> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Wednesday, June 16, 1999 5:45 PM
> To: Ambarish Malpani
> Cc: [e-mail]
> Subject: RE: Problem with RFC 2459?
> 
> 
> Ambarish:
> 
> It cannot distinguish a complete CRL from a partial CRL in 
> the example you
> have given.  However, a relying party that wants to validate 
> a particular
> certificate does not need to tell the difference.  Given the 
> certificate to
> be validated, the replying party can readily determine which 
> of the CRLs
> needs to be checked.  The CRL Distribution Point extension in the
> certificate to be validated explicitly names the CRL that is needed.
> 
> I think that I understand why you might be interested in a way to
> distinguish complete CRLs and partial CRLs.  However, the X.509v3
> specification was developed with a simple model in mind.  
> That is, given a
> certificate, how can a relying party determine it's validity. 
>  The X.509v3
> specification was not intended to support the 
> determinaltionof validity of
> every certificate in existance at a particular moment.  This 
> harder problem
> seems to require additional information from the CA.  I think 
> that you will
> need an out of band mechanism to obtain this additonal information.
> Perhaps a list of every CRL Distribution Point used by the CA will be
> sufficient.
> 
> Russ
> 
> 
> At 03:12 PM 6/7/99 -0700, Ambarish Malpani wrote:
> >
> >Hi Russ,
> >    Here is a potential model a CA could assume, comply with
> >the spec and still produce partial CRLs without any of the
> >issuingDistributionPoint flags set:
> >
> >If the CA partitions CRLs based on the serial number of the
> >certificate (say serialNumber %13). Now, the CA has 13 partial
> >CRLs, with onlyContainsUserCerts and onlyContainsCACerts set
> >to false and onlySomeReasons not set. How can an application
> >distinguish any of these 13 CRLs from a full CRL?
> >
> >Regards,
> >Ambarish
> >
> >---------------------------------------------------------------------
> >Ambarish Malpani
> >Architect					         650.567.5457
> >ValiCert, Inc.				        
> [e-mail]
> >1215 Terra Bella Ave.		              
http://www.valicert.com
> >Mountain View, CA 94043-1833
> >
> >
> >> -----Original Message-----
> >> From: Russ Housley [mailto:[e-mail]]
> >> Sent: Friday, June 04, 1999 3:02 PM
> >> To: Ambarish Malpani
> >> Cc: [e-mail]
> >> Subject: Re: Problem with RFC 2459?
> >> 
> >> 
> >> Ambarish:
> >> 
> >> The IDP has the following syntax:
> >> 
> >>    issuingDistributionPoint ::= SEQUENCE {
> >>         distributionPoint       [0] DistributionPointName OPTIONAL,
> >>         onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
> >>         onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
> >>         onlySomeReasons         [3] ReasonFlags OPTIONAL,
> >>         indirectCRL             [4] BOOLEAN DEFAULT FALSE }
> >> 
> >> If indirectCRL is false (the default case), then 
> X.509-1993 says the
> >> following three things that taken together answer your question:
> >> 
> >> 1.  If onlyContainsUserCerts is true, the CRL only contains 
> >> revocations for
> >> end-entity certificates.
> >> 
> >> 2.  If onlyContainsCACerts is true, the CRL only contains 
> >> revocations for
> >> CA-certificates.
> >> 
> >> 3.  If onlySomeReasons is present, the CRL only contains 
> >> revocations for
> >> the identified reason or reasons, otherwise the CRL contains 
> >> revocations
> >> for all reasons.
> >> 
> >> Thus, if the onlyContainsUserCerts is false AND 
> onlyContainsCACerts is
> >> false AND onlySomeReasons is absent AND indirectCRL is false, 
> >> then the CRL
> >> is complete.
> >> 
> >> Russ
> >> 
> >> 
> >> At 11:48 AM 6/3/99 -0700, Ambarish Malpani wrote:
> >> >
> >> >Hi Folks,
> >> >    Have a quick question about RFC 2459 and CRLDPs.
> >> >
> >> >If a CA issues both full CRLs and CRLDPs (which are partitioned
> >> >based on the serial number of the cert), how can an application
> >> >figure out whether it has the full CRL or a DP?
> >> >
> >> >I know a DP (if it is not the full CRL), must contain the Issuing
> >> >Distribution Point (IDP) extension. However, I believe most CAs
> >> >are putting the IDP extension within their full CRLs also. So,
> >> >is there any way for a application to figure out whether it has
> >> >the full CRL or just a DP?
> >> >
> >> >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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA14154; Thu, 17 Jun 1999 06:21:37 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 06:21:36 -0700
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA14128 for <[e-mail]>; Thu, 17 Jun 1999 06:21:35 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with SMTP id GAA12086; Thu, 17 Jun 1999 06:18:58 -0700 (PDT)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 16 Jun 1999 20:11:39 -0400
To: "Linn, John" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: attribute encryption (was: Re: X.509 ACs vs. SPKI?)
Cc: "'Bob Blakley'" <[e-mail]>, Denis Pinkas <[e-mail]>, Stephen Farrell <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail] mics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 6a55d1f3e7d8c90173f500f9ce8a1d0b

John:

I agree with your direction.  Can you suggest more appropriate names for
the conformance groupings?

Russ


At 04:31 PM 6/8/99 -0400, Linn, John wrote:
>I agree with Stephen's earlier comments supporting the inclusion of an
>encrypted attribute facility, which is explicitly excluded from ac509prof's
>basic conformance level.  While attribute encryption (like PKIs generally)
>introduces infrastructure requirements, it also allows valuable functions
>unavailable otherwise. Can we navigate this argument by retaining the
>definition of encrypted attributes, but separating any conformance
>requirements therefor from conformance to other aspects of the
>"proxy-enabled tier"?  I can envision non-proxy cases where encrypted
>attributes would be useful, and proxy cases where they wouldn't be
>necessary. 
>
>--jl
>
>> -----Original Message-----
>> From: Bob Blakley [mailto:[e-mail]]
>> Sent: Tuesday, June 08, 1999 2:53 PM
>> To: Denis Pinkas; Stephen Farrell
>> Cc: [e-mail]
>> Subject: Re: attribute encryption (was: Re: X.509 ACs vs. SPKI?)
>> 
>> 
>> Denis Pinkas writes:
>> 
>> >The complexity lies in the fact that to encrypt a field the 
>> public key of the
>> target is
>> >needed. This places an additional constraint in terms of key 
>> management: this
>> mandates
>> >targets to possess public encryption keys while ACs may work 
>> without the
>> target to have
>> >such keys and certificates. This "doubles" the complexity. I 
>> would like AC to
>> be
>> >deployable without the need for targets to possess any 
>> private key, which is
>> possible as
>> >long as attributes are in clear text.
>> 
>> I fear the added complexity much more than doubles....
>> 
>> >To be very precise, I would like a basic document NOT 
>> supporting encrypted
>> attributes.
>> >If you think it is very important, then make a *separate* 
>> document so that I
>> can refer
>> >to one (simple) RFC and so that I comply with it without any 
>> need/requirement
>> for
>> >supporting encrypted attributes and the related infrastructure.
>> 
>> I agree with Denis here.
>> 
>> --bob
>> 
>> Bob Blakley ([e-mail])
>> Chief Scientist, Dascom
>> 
>> 
>> 


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA14028; Thu, 17 Jun 1999 06:20:36 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 06:20:31 -0700
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA14005 for <[e-mail]>; Thu, 17 Jun 1999 06:20:30 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with SMTP id GAA12104; Thu, 17 Jun 1999 06:19:01 -0700 (PDT)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 16 Jun 1999 20:45:21 -0400
To: "Ambarish Malpani" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Problem with RFC 2459?
Cc: <[e-mail]>
In-Reply-To: <001a01beb132$d9cdb1d0$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b4f64906bba930f0f511f3f51dc8dd6f

Ambarish:

It cannot distinguish a complete CRL from a partial CRL in the example you
have given.  However, a relying party that wants to validate a particular
certificate does not need to tell the difference.  Given the certificate to
be validated, the replying party can readily determine which of the CRLs
needs to be checked.  The CRL Distribution Point extension in the
certificate to be validated explicitly names the CRL that is needed.

I think that I understand why you might be interested in a way to
distinguish complete CRLs and partial CRLs.  However, the X.509v3
specification was developed with a simple model in mind.  That is, given a
certificate, how can a relying party determine it's validity.  The X.509v3
specification was not intended to support the determinaltionof validity of
every certificate in existance at a particular moment.  This harder problem
seems to require additional information from the CA.  I think that you will
need an out of band mechanism to obtain this additonal information.
Perhaps a list of every CRL Distribution Point used by the CA will be
sufficient.

Russ


At 03:12 PM 6/7/99 -0700, Ambarish Malpani wrote:
>
>Hi Russ,
>    Here is a potential model a CA could assume, comply with
>the spec and still produce partial CRLs without any of the
>issuingDistributionPoint flags set:
>
>If the CA partitions CRLs based on the serial number of the
>certificate (say serialNumber %13). Now, the CA has 13 partial
>CRLs, with onlyContainsUserCerts and onlyContainsCACerts set
>to false and onlySomeReasons not set. How can an application
>distinguish any of these 13 CRLs from a full CRL?
>
>Regards,
>Ambarish
>
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect					         650.567.5457
>ValiCert, Inc.				        [e-mail]
>1215 Terra Bella Ave.		              http://www.valicert.com
>Mountain View, CA 94043-1833
>
>
>> -----Original Message-----
>> From: Russ Housley [mailto:[e-mail]]
>> Sent: Friday, June 04, 1999 3:02 PM
>> To: Ambarish Malpani
>> Cc: [e-mail]
>> Subject: Re: Problem with RFC 2459?
>> 
>> 
>> Ambarish:
>> 
>> The IDP has the following syntax:
>> 
>>    issuingDistributionPoint ::= SEQUENCE {
>>         distributionPoint       [0] DistributionPointName OPTIONAL,
>>         onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
>>         onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
>>         onlySomeReasons         [3] ReasonFlags OPTIONAL,
>>         indirectCRL             [4] BOOLEAN DEFAULT FALSE }
>> 
>> If indirectCRL is false (the default case), then X.509-1993 says the
>> following three things that taken together answer your question:
>> 
>> 1.  If onlyContainsUserCerts is true, the CRL only contains 
>> revocations for
>> end-entity certificates.
>> 
>> 2.  If onlyContainsCACerts is true, the CRL only contains 
>> revocations for
>> CA-certificates.
>> 
>> 3.  If onlySomeReasons is present, the CRL only contains 
>> revocations for
>> the identified reason or reasons, otherwise the CRL contains 
>> revocations
>> for all reasons.
>> 
>> Thus, if the onlyContainsUserCerts is false AND onlyContainsCACerts is
>> false AND onlySomeReasons is absent AND indirectCRL is false, 
>> then the CRL
>> is complete.
>> 
>> Russ
>> 
>> 
>> At 11:48 AM 6/3/99 -0700, Ambarish Malpani wrote:
>> >
>> >Hi Folks,
>> >    Have a quick question about RFC 2459 and CRLDPs.
>> >
>> >If a CA issues both full CRLs and CRLDPs (which are partitioned
>> >based on the serial number of the cert), how can an application
>> >figure out whether it has the full CRL or a DP?
>> >
>> >I know a DP (if it is not the full CRL), must contain the Issuing
>> >Distribution Point (IDP) extension. However, I believe most CAs
>> >are putting the IDP extension within their full CRLs also. So,
>> >is there any way for a application to figure out whether it has
>> >the full CRL or just a DP?
>> >
>> >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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA14479; Thu, 17 Jun 1999 06:33:20 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 06:33:17 -0700
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 GAA14457 for <[e-mail]>; Thu, 17 Jun 1999 06:33:10 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <LSH85V4A>; Thu, 17 Jun 1999 09:35:36 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E3995DE@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, Ambarish Malpani <[e-mail]>
Cc: [e-mail]
Subject: RE: Problem with RFC 2459?
Date: Thu, 17 Jun 1999 09:35:35 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 75297b75fdb622e0c898fc24b0acd9d9

I agree with Russ.

In addition, the following rules can be used to determine completeness
of CRL altogether or vis-a-vis scope.

1.  If the IDP is absent from the CRL, it is a full and complete CRL for
the scope.

2.  If the DP is missing from the CRL, it is a complete CRL for the
entity type and/or reason codes asserted in the IDP.

3.  If the DP is missing and no reason code is asserted, it is a
complete CRL for the entity type.

4.  If the DP is missing and no entity type is asserted, it is a
complete CRL for the reason code asserted.

5.  If all three, DP, entity type and reason code are missing, it is a
complete CRL for the CA.  Please note that in that case, it could
contain indirectCRL field of the IDP.


> -----Original Message-----
> From:	Russ Housley [SMTP:[e-mail]]
> Sent:	Wednesday, June 16, 1999 8:45 PM
> To:	Ambarish Malpani
> Cc:	[e-mail]
> Subject:	RE: Problem with RFC 2459?
> 
> Ambarish:
> 
> It cannot distinguish a complete CRL from a partial CRL in the example
> you
> have given.  However, a relying party that wants to validate a
> particular
> certificate does not need to tell the difference.  Given the
> certificate to
> be validated, the replying party can readily determine which of the
> CRLs
> needs to be checked.  The CRL Distribution Point extension in the
> certificate to be validated explicitly names the CRL that is needed.
> 
> I think that I understand why you might be interested in a way to
> distinguish complete CRLs and partial CRLs.  However, the X.509v3
> specification was developed with a simple model in mind.  That is,
> given a
> certificate, how can a relying party determine it's validity.  The
> X.509v3
> specification was not intended to support the determinaltionof
> validity of
> every certificate in existance at a particular moment.  This harder
> problem
> seems to require additional information from the CA.  I think that you
> will
> need an out of band mechanism to obtain this additonal information.
> Perhaps a list of every CRL Distribution Point used by the CA will be
> sufficient.
> 
> Russ
> 
> 
> At 03:12 PM 6/7/99 -0700, Ambarish Malpani wrote:
> >
> >Hi Russ,
> >    Here is a potential model a CA could assume, comply with
> >the spec and still produce partial CRLs without any of the
> >issuingDistributionPoint flags set:
> >
> >If the CA partitions CRLs based on the serial number of the
> >certificate (say serialNumber %13). Now, the CA has 13 partial
> >CRLs, with onlyContainsUserCerts and onlyContainsCACerts set
> >to false and onlySomeReasons not set. How can an application
> >distinguish any of these 13 CRLs from a full CRL?
> >
> >Regards,
> >Ambarish
> >
> >---------------------------------------------------------------------
> >Ambarish Malpani
> >Architect					         650.567.5457
> >ValiCert, Inc.
> [e-mail]
> >1215 Terra Bella Ave.
> http://www.valicert.com
> >Mountain View, CA 94043-1833
> >
> >
> >> -----Original Message-----
> >> From: Russ Housley [mailto:[e-mail]]
> >> Sent: Friday, June 04, 1999 3:02 PM
> >> To: Ambarish Malpani
> >> Cc: [e-mail]
> >> Subject: Re: Problem with RFC 2459?
> >> 
> >> 
> >> Ambarish:
> >> 
> >> The IDP has the following syntax:
> >> 
> >>    issuingDistributionPoint ::= SEQUENCE {
> >>         distributionPoint       [0] DistributionPointName OPTIONAL,
> >>         onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
> >>         onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
> >>         onlySomeReasons         [3] ReasonFlags OPTIONAL,
> >>         indirectCRL             [4] BOOLEAN DEFAULT FALSE }
> >> 
> >> If indirectCRL is false (the default case), then X.509-1993 says
> the
> >> following three things that taken together answer your question:
> >> 
> >> 1.  If onlyContainsUserCerts is true, the CRL only contains 
> >> revocations for
> >> end-entity certificates.
> >> 
> >> 2.  If onlyContainsCACerts is true, the CRL only contains 
> >> revocations for
> >> CA-certificates.
> >> 
> >> 3.  If onlySomeReasons is present, the CRL only contains 
> >> revocations for
> >> the identified reason or reasons, otherwise the CRL contains 
> >> revocations
> >> for all reasons.
> >> 
> >> Thus, if the onlyContainsUserCerts is false AND onlyContainsCACerts
> is
> >> false AND onlySomeReasons is absent AND indirectCRL is false, 
> >> then the CRL
> >> is complete.
> >> 
> >> Russ
> >> 
> >> 
> >> At 11:48 AM 6/3/99 -0700, Ambarish Malpani wrote:
> >> >
> >> >Hi Folks,
> >> >    Have a quick question about RFC 2459 and CRLDPs.
> >> >
> >> >If a CA issues both full CRLs and CRLDPs (which are partitioned
> >> >based on the serial number of the cert), how can an application
> >> >figure out whether it has the full CRL or a DP?
> >> >
> >> >I know a DP (if it is not the full CRL), must contain the Issuing
> >> >Distribution Point (IDP) extension. However, I believe most CAs
> >> >are putting the IDP extension within their full CRLs also. So,
> >> >is there any way for a application to figure out whether it has
> >> >the full CRL or just a DP?
> >> >
> >> >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 localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA12478; Thu, 17 Jun 1999 04:32:20 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 04:32:12 -0700
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA12455 for <[e-mail]>; Thu, 17 Jun 1999 04:32:10 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id NAA05631; Thu, 17 Jun 1999 13:34:37 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 17 Jun 1999 13:34:46 +0200
To: Denis Pinkas <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Combination of policy OID:s
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <v04020a0fb383271ddc78@[128.89.0.110]> <[e-mail]> <41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA12456
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0d036d17e97700e3bcfebd01fc51416d

Denis,

I hope you don't mind that I copy this to the list, but I think this
clarification may be of public interest. 

The problem has nothing to do with criticality.

The only way to communicate (from a CA) to a relaying party (according to
the semantics of the policy extension) that he/she must "verify that the
expected OID is present" is by ONLY including that policy OID in the
certificate.

Further, the client of a relying party can't use the logical AND function
when examining combinations of policies (regardless or criticality)

I.e. follwoing X.509 and RFC 2459 path validation logic, you cant say to
the client:

1) The policy OID xxyy-qc-eu (EU QC OID) MUST be present AND;
2) One of the policies xx-1, xx-2, xx-3, xx-4 or xx-5 (accepted
CA-policies) MUST be present.

Today, the only thing you can say to a client is:

- Make sure that at least one of the policies xx-yy-eu, xx-1, xx-2, xx-3,
xx-4 or xx-5 is present in each certificate in the validated path.

So if you want to mandate presence of xx-yy-eu, you can't at the same time
require presence of any other policy.


/Stefan

At 01:07 PM 6/17/99 +0200, you wrote:
>Stefan,
>
>This is response where I have NOT copied the PKIX mailing list.
>
>> X.509 does not allow inclusion of several policy OID:s in a certificate
>> with the meaning that the relying party MUST accept more than one.
>>
>> X.509, section "12.2.2.6  Certificate policies field" states:
>>
>> "If the extension is flagged critical, it indicates that the certificate
>> shall only be used for the purpose, and in accordance with the rules
>> implied by ONE of the indicated certificate policies. The rules of a
>> particular policy may require the certificate-using system to process the
>> qualifier value in a particular way."
>
>Nothing in the Directive mandates that the certificate shall only be used for
>the Directive.
>The Policy OID does not need to be made critical. However the receiver must
>verify that the expected OID is present.
>
>This solves the problem, in a fairly different way. :-)
>
>Denis
>
>
>> First of all... This logic is not clearly stated in RFC 2459  section
>> 4.3.1.5. This is a problem since RFC 2459 implicitly requires this logic in
>> order to comply with the basic path validation logic stated in section 6.1
>>
>> Secondly... This logic may impose a problem under some circumstances.
>>
>> This cause problems for the EU-standardization initiative as they have
>> discussed a solution with a EU-defined policy OID stating that the
>> certificate is a "Qualified Certificate" according to the EU-directive.
>> Such statement would then have to be combined with a CA specific policy OID.
>>
>> This is not the only field where there has been discussions related to
>> "combine" several policy OID:s in order to formulate the complete policy
>> statement by the CA. The advantage of this could be the fact that some
>> policy OID's could be well defined and commonly understood (as some EU
>> defined statements)
>>
>> One general solution to this problem could be define a policy qualifier
>> where the CA can enter policy OID:s that have to be accepted in combination
>> with the "parent" policy.
>>
>> This could then be processed within the current path logic of X.509 and
>> RFC2459.
>>
>> My questions related to this solution is:
>>
>> - Would this be a desired solution to the problem?
>> - If so, where should it be specified?
>>
>> It could be specified in the QC draft, but since this is a general problem,
>> it could be better to define it in RFC 2459 (next issue).
>>
>> Comments?
>>
>> /Stefan
>>
>> -------------------------------------------------------------------
>> Stefan Santesson                <[e-mail]>
>> Accurata Systemsäkerhet AB      http://www.accurata.se
>> Slagthuset                      Tel. [phone]
>> 211 20  Malmö                   Fax. [phone]
>> Sweden                        Mobile [phone]
>>
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA09051; Thu, 17 Jun 1999 02:54:19 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 17 Jun 1999 02:53:59 -0700
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA09027 for <[e-mail]>; Thu, 17 Jun 1999 02:53:58 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id LAA04370; Thu, 17 Jun 1999 11:56:27 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 17 Jun 1999 11:56:36 +0200
To: [e-mail], Stephen Kent <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Combination of policy OID:s 
Cc: Hans Nilsson <[e-mail]>
In-Reply-To: <v04020a10b38b45a34213@[128.33.238.203]>
References: <[e-mail]> <v04020a0fb383271ddc78@[128.89.0.110]> <[e-mail]> <41ACC8CF2BF1D011AEDD00805F31E54C02F232CD@AUNT15>
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 CAA09029
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 8782ee539c63bd7ad1b0a1d6a0a2f548

X.509 does not allow inclusion of several policy OID:s in a certificate
with the meaning that the relying party MUST accept more than one.

X.509, section "12.2.2.6  Certificate policies field" states:

"If the extension is flagged critical, it indicates that the certificate
shall only be used for the purpose, and in accordance with the rules
implied by ONE of the indicated certificate policies. The rules of a
particular policy may require the certificate-using system to process the
qualifier value in a particular way."

First of all... This logic is not clearly stated in RFC 2459  section
4.3.1.5. This is a problem since RFC 2459 implicitly requires this logic in
order to comply with the basic path validation logic stated in section 6.1 

Secondly... This logic may impose a problem under some circumstances.

This cause problems for the EU-standardization initiative as they have
discussed a solution with a EU-defined policy OID stating that the
certificate is a "Qualified Certificate" according to the EU-directive.
Such statement would then have to be combined with a CA specific policy OID.

This is not the only field where there has been discussions related to
"combine" several policy OID:s in order to formulate the complete policy
statement by the CA. The advantage of this could be the fact that some
policy OID's could be well defined and commonly understood (as some EU
defined statements)

One general solution to this problem could be define a policy qualifier
where the CA can enter policy OID:s that have to be accepted in combination
with the "parent" policy.

This could then be processed within the current path logic of X.509 and
RFC2459.

My questions related to this solution is:

- Would this be a desired solution to the problem?
- If so, where should it be specified?

It could be specified in the QC draft, but since this is a general problem,
it could be better to define it in RFC 2459 (next issue).

Comments?

/Stefan



-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA01166; Wed, 16 Jun 1999 12:23:14 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Wed, 16 Jun 1999 12:21:28 -0700
Received: from irwell.zetnet.co.uk ([e-mail] [194.247.47.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01128 for <[e-mail]>; Wed, 16 Jun 1999 12:21:27 -0700 (PDT)
Received: from dwc-acer (man-281.dialup.zetnet.co.uk [194.247.43.101]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA12563; Wed, 16 Jun 1999 20:23:44 +0100
Message-Id: <[e-mail]>
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: [e-mail], [e-mail] (Rob Weltman)
Date: Wed, 16 Jun 1999 20:26:46 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: I-D ACTION:draft-chadwick-pkixldap-v3-00.txt
Reply-to: [e-mail]
CC: [e-mail]
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: ffb03c1dd8b811752dc84c77dddba1c6

Date sent:      	Tue, 15 Jun 1999 20:41:37 -0700
From:           	[e-mail] (Rob Weltman)
Organization:   	Netscape Communications Corp.
To:             	[e-mail], [e-mail]
Subject:        	Re: I-D ACTION:draft-chadwick-pkixldap-v3-00.txt

> David,
> 
>   Section 2  seems to contradict RFC 2252 concerning altServer. RFC 2252
>   says:
> 
> 5.2.2. altServer
> 
>    The values of this attribute are URLs of other servers which may be
>    contacted when this server becomes unavailable.  If the server does not
>    know of any other servers which could be used this attribute will be
>    absent.
> 
>   while your X.509 draft says:
> 
> The altServer attribute is used by servers to point to alternative
> servers that may be contacted if this server is temporarily
> unavailable. This attribute MUST be stored in the root DSE of the
> server and MUST be available to clients for retrieval. If no
> alternative servers exist this attribute MUST point to the current
> server.
> 
> 

The first thing to note is that this is a profile for certificate and CRL 
use of LDAP servers, and not for generic use of LDAP servers 
(which is the remit of RFC 2252). Thus there are some special 
requirements that the PKIX group will decide upon in due course. 
Some of these may make mandatory what are currently optional 
features in RFC 2252. I dont see a conflict in this. If you conform to 
PKIX your server will always have this particular feature (whatever it 
is), whereas if you dont conform to PKIX you may or may not have 
this feature. Similarly other PKIX requirements may determine that 
some RFC 2252 features are not needed at all for PKIX use. Again I 
dont see this as a problem, do you? My draft is a strawman with my 
initial thoughts about these issues, but ultimately the PKIX group will 
decide collectively what they require from LDAPv3.

My rationale for making altServer mandatory is that CRLs 
(especially) should be available 24 hours a day 365 days a year. 
Thus a failsafe installation will have backup servers. These might be 
at different addresses or at the same address (a cluster for 
example), and altServer will say where they are located. Hence the 
reason for making it mandatory.

>   Also, I don't understand section 4 (Features Of Ldapv3 That SHOULD NOT
>   Be
> Supported):
> 
> The client SHOULD NOT support the ModifyDN, Compare and Abandon
> operations.
> 
> etc.
> 
>   While it may not be necessary for an LDAP client using PKI to support
>   these
> operations, why is it significant for PKI that a client NOT support them?

Here I was trying to simplify (minimise) the number of features that 
a client has to implement. We can argue whether they should be 
optional or not really necessary. (Note that SHOULD NOT does not 
forbid implementation if you really want to, it says that you should 
have a good reason for implementing it if you want to, otherwise 
dont)

> 
>   The Abstract of the document says:
> 
> This document describes the features of the Lightweight Directory
> Access Protocol v3 that are needed in order to support a public key
> infrastructure based on X.509 certificates and CRLs.
> 
>   but section 4 seems to list a number of LDAPv3 features which the
>   document feels
> are not only not needed, but detrimental to a PKI infrastructure, and it
> does so without explaining why.

The reason is to minimise the implementation effort for both clients 
and servers that are PKI specific. (For example there is an LDAPv2 
client built into our PKI client, that is not a fully fledged client, but is 
limited in its capabilities)

Hope this helps.
BTW, my draft is a stawman to shoot at, so keep on firing.

David


> 
> Rob
> 
> 
> [e-mail] wrote:
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >         Title           : Internet X.509 Public Key Infrastructure
> > Operational Protocols - LDAPv3
> >         Author(s)       : D. Chadwick
> >         Filename        : draft-chadwick-pkixldap-v3-00.txt
> >         Pages           :
> >         Date            : 14-Jun-99
> >
> > This document describes the features of the Lightweight Directory
> > Access Protocol v3 that are needed in order to support a public key
> > infrastructure based on X.509 certificates and CRLs.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-chadwick-pkixldap-v3-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> > username "anonymous" and a password of your e-mail address. After
> > logging in, type "cd internet-drafts" and then
> >         "get draft-chadwick-pkixldap-v3-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >         [e-mail].
> > In the body type:
> >         "FILE /internet-drafts/draft-chadwick-pkixldap-v3-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]>
> 
> 


***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
*NEW* Mobile [phone] *NEW*
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA22860; Tue, 15 Jun 1999 09:47:23 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 15 Jun 1999 09:46:23 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA22789 for <[e-mail]>; Tue, 15 Jun 1999 09:46:21 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Tue, 15 Jun 1999 09:48:08 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Fwd: I-D ACTION:draft-clynn-bgp-x509-auth-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: 0106ff2a03244ebeddab2762d276b105

This might be of interest to this group (might not).

>To: IETF-Announce: ;
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-clynn-bgp-x509-auth-00.txt
>Date: Tue, 15 Jun 1999 12:03:44 -0400
>Sender: [e-mail]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : X.509 Extensions for Authorization of IP Addresses,
>                           AS Numbers, and Routers within an AS
>         Author(s)       : C. Lynn
>         Filename        : draft-clynn-bgp-x509-auth-00.txt
>         Pages           : 13
>         Date            : 14-Jun-99
>
>This document defines three X.509 v3 Certificate Extensions.  The
>first binds a list of IP Address blocks to the public key of the
>subject of a certificate.  The second binds a list of Autonomous
>System Numbers to the public key of the subject of a certificate.
>The third binds a BGP Router Identifier and an Autonomous System
>Number to the public key of the subject of a certificate.  Third
>parties, e.g., BGP routers, may use these certificates to verify that
>the holder of the private key corresponding to the public key in the
>certificate has been properly authorized to use resources specified
>in the certificate extension.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-clynn-bgp-x509-auth-00.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-clynn-bgp-x509-auth-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [e-mail].
>In the body type:
>         "FILE /internet-drafts/draft-clynn-bgp-x509-auth-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-clynn-bgp-x509-auth-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-clynn-bgp-x509-auth-00.txt>


--Paul Hoffman, Director
--Internet Mail Consortium



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA24822; Tue, 15 Jun 1999 10:31:06 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 15 Jun 1999 10:30:56 -0700
Received: from irwell.zetnet.co.uk ([e-mail] [194.247.47.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24792 for <[e-mail]>; Tue, 15 Jun 1999 10:30:48 -0700 (PDT)
Received: from dwc-acer (manr-050.dialup.zetnet.co.uk [194.247.43.180]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA22964 for <[e-mail]>; Tue, 15 Jun 1999 18:32:51 +0100
Message-Id: <[e-mail]>
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: [e-mail]
Date: Tue, 15 Jun 1999 18:35:59 +0100
MIME-Version: 1.0
Content-type: Multipart/Mixed; boundary=Message-Boundary-10577
Subject: New ID on LDAPv3
Reply-to: [e-mail]
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.01d)
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: edf715e3de2278b30bd015039f0e7c97

Folks,

A new ID has just been (or is just about to be) published

<draft-chadwick-pkixldap-v3-00.txt>

This gives a profile for the use of LDAPv3 to retrieve X.509 
certificates and CRLs.

I append a copy to this message. I believe there will be a brief 
discussion of this on the Wednesday morning in Oslo

David

***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
*NEW* Mobile [phone] *NEW*
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

Internet-Draft                                       D.W.Chadwick
PKIX WG                       		   University of Salford      
Intended Category: Standards Track             
Expires: 12 December 1999                            12 June, 1999



                 Internet X.509 Public Key Infrastructure
                      Operational Protocols – LDAPv3
                 <draft-chadwick-pkixldap-v3-00.txt>


STATUS OF THIS MEMO

This document is an Internet-Draft and is in full conformance with 
all the provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering 
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft expires on December 12, 1999. Comments and 
suggestions on this document are encouraged. Comments on this 
document should be sent to the PKIX working group discussion list:
                <[e-mail]>
or directly to the author.


ABSTRACT

This document describes the features of the Lightweight Directory 
Access Protocol v3 that are needed in order to support a public key 
infrastructure based on X.509 certificates and CRLs.


1. Introduction

RFC 2559 [1] specifies the subset of LDAPv2 [2] that is necessary to 
retrieve X.509 [9] certificates and CRLs from LDAP servers. However 
LDAPv2 has a number of deficiencies that may limit its usefulness in 
certain circumstances. The most notable of these are:

      - LDAPv2 distinguished names must be composed from the IA5 
character set and cannot contain accented or non-latin characters,

      - LDAPv2 only has a limited number of supported authentication 
schemes for binding to the server, in particular the use of hashed 
passwords or TLS [3] are not supported,

       - LDAPv2 only supports a single directory server. It is the 
responsibility of the user to pre-configure his client with the 
required set of LDAP servers, and to choose the correct one for each 
certificate and CRL retrieval.

It is for these reasons (and others not listed here) that the IETF 
have stopped the standardisation of the LDAPv2 protocol and have 
replaced it with the LDAPv3 protocol [4]. However the LDAPv3 protocol 
is much more complex than the LDAPv2 protocol and many of its 
features are not essential for simple PKIX use. This document 
describes the features of LDAPv3 that are essential, or not required, 
or are optional for servers to support a PKI based on X.509.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",  
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [5].


2. Features Of Ldapv3 That MUST Be Supported

Attribute descriptions are a superset of attribute type definitions. 
They allow attribute subtyping to be specified in the LDAPv3 
protocol. The ;binary option is exception to this. This option allows 
certificates and CRLs to be asked for and returned as binary values 
encoded using the Basic Encoding Rules [11]. The mechanism described 
in PKIX LDAPv2 [1] is fully compliant with the ;binary option of 
LDAPv3. The ;binary option of attribute descriptions MUST be 
supported by all implementations.  Other attribute description 
options SHOULD NOT be supported by clients. Servers MAY choose to 
support them at their discretion.

UTF8 encoding [12] allows the full ISO 10646 character set to be used 
in the creation of distinguished names. UTF8 encoding of 
distinguished names MUST be supported as specified in RFC2253 [6].

The altServer attribute is used by servers to point to alternative 
servers that may be contacted if this server is temporarily 
unavailable. This attribute MUST be stored in the root DSE of the 
server and MUST be available to clients for retrieval. If no 
alternative servers exist this attribute MUST point to the current 
server. Clients MAY make use of this feature but do not need to. 
Servers MAY store any other operational attributes in the root DSE, 
but do not need to.


3. Features Of Ldapv3 That SHOULD Be Supported

In a distributed directory with multiple servers, LDAPv3 supports 
referrals as the mechanism to allow one server that cannot fulfil a 
client’s request, to refer the client to another server that might be 
better able to fulfil the request. Servers SHOULD be able to return 
referrals to clients. Clients SHOULD be able to receive referrals, 
although they are not required to automatically process them and 
support multiple asynchronous outgoing connections. As a minimum, 
clients SHOULD be able to ask the user if the referrals are be cached 
locally and added to the set of servers known to the client. 

Partial Search results are returned when a server only has a subset 
of the certificates requested by the client. Referrals to other 
servers are embedded in the SearchResultReference field. Clients and 
servers SHOULD be able to handle SearchResultReferences in the same 
way as they handle referrals.


4. Features Of Ldapv3 That SHOULD NOT Be Supported

The client SHOULD NOT support the ModifyDN, Compare and Abandon 
operations. The server MAY choose to support these operations at its 
discretion.

The LDAPv3 protocol is infinitely extensible via two mechanisms: 
extended operations and controls on existing operations. The client 
SHOULD NOT generate any LDAPv3 protocol extensions (extended 
operations or controls).  The server SHOULD NOT return any LDAPv3 
protocol extensions (extended operations or controls).

LDAPv3 has the concept of unsolicited notifications that can be sent 
from the server to the client. The server SHOULD NOT generate any 
unsolicited notifications.

LDAPv3 allows the subschema supported by the server to be published 
in a subschema subentry. Subschema publishing is not needed for 
normal PKI use, therefore the client SHOULD NOT try to retrieve 
either the contents of the subschema subentry or the pointer to it 
(held in the subschemaSubentry attribute of the root DSE) from the 
server. The server MAY publish its subschema at its discretion.

Operational attributes are attributes stored by the server that hold 
administrative information. Clients SHOULD NOT request any 
operational attributes from the server other than the altServer 
attribute, and the server need not store any operational attributes 
other than altServer.


5. Features Of Ldapv3 That MAY Be Supported

If the CPS allows unauthenticated anonymous access to the server, 
then the server MUST allow a client to perform a Search operation 
(for a "read" or "search" type request) without issuing a prior Bind 
operation. The server MUST also allow the client to present a Bind 
request with the simple authentication choice and a zero-length OCTET 
STRING.

If the CPS allows weak password based authentication for "read" or 
"search" access to the server, the client and the server SHOULD 
support the DIGEST-MD5 mechanism [7] as specified in [8], and may 
support a simple password Bind sequence following the negotiation of 
a TLS ciphersuite to provide connection confidentiality, as specified 
in [10].

If the CPS requires strong authentication for access to the server 
then the client and the server SHOULD support certificate based 
authentication as specified in [10].

The parameters of the Search operation for "read" or "search" type 
queries will usually be set as specified in RFC 2559. However, 
X.509(1997) [9] supports flexible certificate matching by the server, 
via the certificateMatch MATCHING-RULE. For example, a client may 
search for certificates with a particular validity time, key usage, 
policy or other field. If the server supports flexible matching, then 
the extensibleMatch filter item MUST be supported. Clients MAY 
support the extensibleMatch filter item.


6. Security Considerations

The PKI information to be retrieved from LDAPv3 servers (certificates 
and CRLs) is digitally signed and therefore additional integrity 
services are NOT REQUIRED. The CPS will specify whether the 
information should be publicly available or not. If publicly 
available, privacy services will NOT be REQUIRED for retrieval 
requests. If not publicly available, privacy services MAY be REQUIRED 
and these can be provided by a TLS ciphersuite as specified in clause 
5.

For update of the information by CAs either strong authentication or 
weaker password based authentication MUST be supported as specified 
in clause 5. Additional access controls SHOULD be provided.

Organizations are NOT REQUIRED to provide external CAs or users with 
access to their directories.


7 Copyright

Copyright (C) The Internet Society (date). All Rights Reserved.

This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works.  However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English.

The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


8. References

[1] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key 
Infrastructure Operational Protocols - LDAPv2", RFC 2559, April 1999
[2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access 
Protocol", RFC 1777, March 1995.
[3] T. Dierks, C. Allen. "The TLS Protocol Version 1.0", RFC 2246, 
January 1999.
[4] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access  
Protocol (v3)", Dec. 1997, RFC 2251
[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement 
Levels", RFC 2119, March 1997.
[6] M. Wahl, S. Kille, T. Howes. "Lightweight Directory Access 
Protocol (v3): UTF-8 String Representation of Distinguished Names", 
RFC2253, December 1997.
[7] Digest md5
[8] P. Leach, C. Newman, "Using Digest Authentication as a SASL 
Mechanism", INTERNET DRAFT <draft-leach-digest-sasl-01.txt>, November 
1998.
[9] X.509(97)
[10] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan. 
"Authentication Methods for LDAP" <draft-ietf-ldapext-authmeth-
03.txt>, November 1998
[11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, 
Canonical, and Distinguished Encoding Rules", 1994.
[12] F. Yergeau. "UTF-8, a transformation format of ISO 10646", RFC 
2279, January 1998.


10 Authors Address

David Chadwick
IS Institute
University of Salford
Salford
England
M5 4WT 

Email: [e-mail]




Internet-Draft   PKIX Operational Protocols – LDAPv3     12 June 1999
>From ???@??? Tue Jun 15 13:17:53 1999
Received: from localhost (daemon@localhost)
	by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA28798;
	Tue, 15 Jun 1999 12:51:06 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 15 Jun 1999 12:51:01 -0700
Received: from aum (ip11.proper.com [165.227.249.11])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA28769
	for <[e-mail]>; Tue, 15 Jun 1999 12:51:00 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Tue, 15 Jun 1999 12:51:36 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Fwd: I-D ACTION:draft-chadwick-pkixldap-v3-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: cbf825ff783f2589d3bb2512437e1c72

Another new draft of possible interest to the group.


>To: IETF-Announce: ;
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-chadwick-pkixldap-v3-00.txt
>Date: Tue, 15 Jun 1999 14:56:36 -0400
>Sender: [e-mail]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Internet X.509 Public Key Infrastructure
>Operational Protocols - LDAPv3
>         Author(s)       : D. Chadwick
>         Filename        : draft-chadwick-pkixldap-v3-00.txt
>         Pages           :
>         Date            : 14-Jun-99
>
>This document describes the features of the Lightweight Directory
>Access Protocol v3 that are needed in order to support a public key
>infrastructure based on X.509 certificates and CRLs.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-chadwick-pkixldap-v3-00.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-chadwick-pkixldap-v3-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [e-mail].
>In the body type:
>         "FILE /internet-drafts/draft-chadwick-pkixldap-v3-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-chadwick-pkixldap-v3-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-chadwick-pkixldap-v3-00.txt>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA26670; Mon, 14 Jun 1999 17:36:26 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Jun 1999 17:36:21 -0700
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 RAA26648; Mon, 14 Jun 1999 17:36:21 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id RAA56086; Mon, 14 Jun 1999 17:38:41 -0700
Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (mailgate2.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Mon, 14 Jun 1999 17:38:37 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id RAA49632; Mon, 14 Jun 1999 17:38:36 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 14 Jun 1999 17:38:37 -0700
Subject: Back To Basics (Was "Re: Certificate requests for encryption keys")
From: "Aram Perez" <[e-mail]>
To: [e-mail], [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
X-UIDL: b2337ade3ed983e068a17a484bf15fb4

I've been away for a couple of weeks so I've read with great interest all 
the discussion on this subject. I'd like to add my comments, starting with
what Bob Jueneman wrote:

>This thread has engendered several interesting subthreads, but let's dispatch
>the first one, first.

I did not understand Bob's answer to what he called "the first one". I
thought what started this thread was that Ilan Shacham wrote:

>There has been much talk lately of using dual key pairs - one key pair
>for encryption, and one for signing.
>The following question arises - how does one create a certificate request
>for an encryption key pair? after all, the certificate request is signed by
>the key inside it, but the key is an encryption key, so this is illegal.

I'm assuming Ilan is talking about about the "Simple Enrollment Request"
from <draft-ietf-pkix-cmc-xx.txt> which based on a PKCS#10 message. PKCS#10
requires that "the certificate request is signed by the key inside it" and
thus his question. The "Full PKI Request" allows the request to "be signed
either by the private key material of the signature certification request,
or by a pre-existing signature key and certificate." I believe this
corresponds to Ilan's second solution. Ilan stated that this solution
provides "no Proof Of Posession of the encryption key". If I cannot attest
that a certificate request has my encryption public key with my signature,
of what use are digital signatures?

Also, I'm assuming that Ilan is talking about encryption keys used for key
management (key exchange, key wrapping, etc.) and not for encrypting data.
Hence Anne Anderson's comments about end-entities needing "to change
encryption keys frequently" does not make sense. The reason S/MIME uses
EnvelopedData is that is allows for a new *data encryption key* for every
message with a longer term *key management key*.

I agree with Bob Jueneman's position of having POP for the private key, but
I also agree with Terry Hayes' statement that even though Bob's suggestion
"is rather awkward", we should "Fix the operational level protocols
instead".

With respect to self-signed certificates, no matter what format (X.509, PGP,
SDSI, etc), whether it's from an end-entity or a CA, you have to verify it
out-of-band.

Regards,
Aram Perez


Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA23305; Mon, 14 Jun 1999 13:21:01 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Jun 1999 13:21:00 -0700
Received: from relay.gw.tislabs.com ([e-mail] [192.94.214.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA23283 for <[e-mail]>; Mon, 14 Jun 1999 13:21:00 -0700 (PDT)
Received: by relay.gw.tislabs.com; id QAA03079; Mon, 14 Jun 1999 16:38:27 -0400 (EDT)
Received: from clipper.gw.tislabs.com(10.33.1.2) by relay.gw.tislabs.com via smap (4.1) id xma002906; Mon, 14 Jun 99 16:37:43 -0400
Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.1/8.9.1) id QAA28519 for [e-mail]; Mon, 14 Jun 1999 16:16:51 -0400 (EDT)
Date: Mon, 14 Jun 1999 16:16:51 -0400 (EDT)
From: "David M. Balenson" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: NDSS 2000 SUBMISSION DEADLINE EXTENDED TO JUNE 23RD
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]\?body=unsubscribe
X-UIDL: 5cfe7b1ca93a9c178b2458a7de06a0d9

The Internet Society's Year 2000 Network and Distributed System
Security Symposium (NDSS 2000) deadline for submissions of technical
paper and panel proposals has been EXTENDED TO JUNE 23RD due to
the large number of requests for an extension and the desire to
accomodate people.

The complete Call for Papers (CFP) is available at
http://www.isoc.org/ndss2000/.

Submissions are being accepted electronically at http://www.isi.edu/~ndss00.

-David Balenson, NDSS 2000 Publicity Chair



Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA22872; Mon, 14 Jun 1999 13:01:00 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Jun 1999 13:00:52 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA22848 for <[e-mail]>; Mon, 14 Jun 1999 13:00:51 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Mon, 14 Jun 1999 12:59:41 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Fwd: RFC 2560 on PKIX OCSP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]\?body=unsubscribe
X-UIDL: 6b3015a392e0b03fe1328b6bbd078a53

I think the IETF-Announce folks still have the wrong address for this list, 
so let me be the first to pass this message along.

>To: IETF-Announce: ;
>Subject: RFC 2560 on PKIX OCSP
>Cc: [e-mail]
>Date: Mon, 14 Jun 1999 11:08:33 -0700
>From: RFC Editor <[e-mail]>
>
>
>A new Request for Comments is now available in online RFC libraries.
>
>
>         RFC 2560:
>
>         Title:      X.509 Internet Public Key Infrastructure
>                     Online Certificate Status Protocol - OCSP
>         Author(s):  M. Myers, R. Ankney, A. Malpani, S. Galperin,
>                     C. Adams
>         Status:     Proposed Standard
>         Date:       June 1999
>         Mailbox:    [e-mail], [e-mail],
>                     [e-mail], [e-mail],
>                     [e-mail],
>         Pages:      23
>         Characters: 43243
>         Updates/Obsoletes/See Also: None
>         I-D Tag:    draft-ietf-pkix-ocsp-08.txt
>
>
>         URL:        ftp://ftp.isi.edu/in-notes/rfc2560.txt
>
>
>This document specifies a protocol useful in determining the current
>status of a digital certificate without requiring CRLs. Additional
>mechanisms addressing PKIX operational requirements are specified in
>separate documents.
>
>This document is a product of the Public-Key Infrastructure (X.509)
>Working Group of the IETF.
>
>This document is now a Proposed Standard Protocol.
>
>This document specifies an Internet standards track protocol for
>the Internet community, and requests discussion and suggestions
>for improvements.  Please refer to the current edition of the
>"Internet Official Protocol Standards" (STD 1) for the
>standardization state and status of this protocol.  Distribution
>of this memo is unlimited.
>
>This announcement is sent to the IETF list and the RFC-DIST list.
>Requests to be added to or deleted from the IETF distribution list
>should be sent to [e-mail].  Requests to be
>added to or deleted from the RFC-DIST distribution list should
>be sent to [e-mail].
>
>Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
>an EMAIL message to [e-mail] with the message body
>help: ways_to_get_rfcs.  For example:
>
>         To: [e-mail]
>         Subject: getting rfcs
>
>         help: ways_to_get_rfcs
>
>Requests for special distribution should be addressed to either the
>author of the RFC in question, or to [e-mail].  Unless
>specifically noted otherwise on the RFC itself, all RFCs are for
>unlimited distribution.echo
>Submissions for Requests for Comments should be sent to
>[e-mail].  Please consult RFC 2223, Instructions to RFC
>Authors, for further information.
>
>
>Joyce K. Reynolds and Alegre Ramos
>USC/Information Sciences Institute
>
>...
>
>Below is the data which will enable a MIME compliant Mail Reader
>implementation to automatically retrieve the ASCII version
>of the RFCs.
>Content-Type: text/plain
>Content-ID: <[e-mail]>
>
>RETRIEVE: rfc
>DOC-ID: rfc2560
>
><ftp://ftp.isi.edu/in-notes/rfc2560.txt>




Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA20047; Mon, 14 Jun 1999 08:55:39 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 14 Jun 1999 08:55:36 -0700
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA20025 for <[e-mail]>; Mon, 14 Jun 1999 08:55:34 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Mon, 14 Jun 1999 08:55:49 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Administrivia: new mailer
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:[e-mail]\?body=unsubscribe
X-UIDL: fc02da24fd7eba94d9e555bdc5d25805

Greetings. I'm experimenting with a new method of sending out the ietf-pkix 
mailing list that should be more efficient. It also might not work. Please 
let me know if you have any new problems with the list.

(For those of you wondering, the ietf-pkix mailing list has over 1100 
people on it.)

--Paul Hoffman, Director
--Internet Mail Consortium



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA18877 for ietf-pkix-bks; Mon, 14 Jun 1999 06:44:33 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA18871 for <[e-mail]>; Mon, 14 Jun 1999 06:44:30 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Mon, 14 Jun 1999 14:45:11 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id OAA22336; Mon, 14 Jun 1999 14:45:08 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id OAA05536; Mon, 14 Jun 1999 14:45:07 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: Denis Pinkas <[e-mail]>
cc: Stephen Farrell <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: Re: X.509 ACs vs. SPKI? 
In-reply-to: Your message of "Mon, 14 Jun 1999 15:17:58 +0200." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 14 Jun 1999 14:45:05 +0100
From: Stephen Farrell <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,
 
> This can be provided using a confidentiality channel, e.g. a VPN or TLS or
> whatever. This does not mean that the attribute itself, i.e. inside the AC
> must be encrypted.

Of course. The I-D never says "must be encrypted", its a mechanism which
is sometimes suitable to use, sometimes not. I'd say that confidentiality
protection of an entire AC is out of scope of this work, but would be
in scope for say TLS or the S/MIME message I-D.
 
> When an AC contains attributes in clear text then it not targeted for a
> specific target when requested from an AA (Attribute Authority). It may be
> re-used several times at any targeting place. 

Fine.

> If attributes are/were
> encrypted, it is first needed to define a target for every encrypted attribute
> and that AC can only be understandable by the nominated targets. 

Not fine:-) The I-D doesn't say that encryption applies to all or nothing.
An AA can decide however it likes which attributes are to be encrypted
for which recipients and bundle the (sets of) EnvelopedData in at least
a few different ways.

Sice the EnvelopedData blobs are sent as the values of an encryptedAttribtues
attribute, any verifier that isn't a recipient can still see all the
remaining cleartext attributes.

This means that so long as your AA (implementation and operation) is 
competent, there's no necessary loss of reusability.

In fact, I'd argue that the use of encryption increases the reusabillity
of an AC. This is because without attribute encryption the AA may
have to partition the attributes of a EE into many ACs. If encryption
is available and usable, then the AA can stuff more into a single
AC without loss of security.

> A further
> disadvantage is that the AA will know the targets of the client and may infer
> from that information what the client is doing. This goes against some privacy
> considerations ... but may be very good, from an AA point of view,  for
> marketing or other reasons.

That's right, and it may be a (slight) disadvantage for some environments.
However, I'd imagine that mechanisms that remove this constraint would
be quite hard to handle, but I'd be interested in any ideas...

Regards,
Stephen.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA18692 for ietf-pkix-bks; Mon, 14 Jun 1999 06:18:04 -0700 (PDT)
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 GAA18681 for <[e-mail]>; Mon, 14 Jun 1999 06:17:49 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id PAA20510; Mon, 14 Jun 1999 15:16:32 +0200
Message-ID: <[e-mail]>
Date: Mon, 14 Jun 1999 15:17:58 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stephen Farrell <[e-mail]>
CC: Russ Housley <[e-mail]>, [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen,

You took advantage of the time difference to answer before Russ could reply.
:-)


> Denis,
>
> > The basic question is the way(s) that are used to prevent the
> > stealing of the attributes. They can be a clear text, with a good way to
> > protect them against stealing using only integrity mechanism techniques.
>
> I guess this is where the difference arises. If I have a clearance
> of SECRET then (it can be the case that) I'm not just concerned that
> someone else could steal that attribute, but I'm also concerned that
> no-one (except certain people/servers) should find out that I've got
> SECRET clearance.

This can be provided using a confidentiality channel, e.g. a VPN or TLS or
whatever. This does not mean that the attribute itself, i.e. inside the AC
must be encrypted.

When an AC contains attributes in clear text then it not targeted for a
specific target when requested from an AA (Attribute Authority). It may be
re-used several times at any targeting place. If attributes are/were
encrypted, it is first needed to define a target for every encrypted attribute
and that AC can only be understandable by the nominated targets. A further
disadvantage is that the AA will know the targets of the client and may infer
from that information what the client is doing. This goes against some privacy
considerations ... but may be very good, from an AA point of view,  for
marketing or other reasons.

Regards,

Denis

> So, prevention of attribute stealing is not the only basic question.
>
> Regards,
> Stephen.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA18453 for ietf-pkix-bks; Mon, 14 Jun 1999 05:52:39 -0700 (PDT)
Received: from Newman.GSC.GTE.Com ([e-mail] [207.175.88.67]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA18448; Mon, 14 Jun 1999 05:52:37 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 3799"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #29038) with ESMTP id <[e-mail]>; Mon, 14 Jun 1999 08:54:51 -0400 (EDT)
Received: by gscex01.ndhm.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <MXXT4HRX>; Mon, 14 Jun 1999 08:54:50 -0400
Content-return: allowed
Date: Mon, 14 Jun 1999 08:54:50 -0400
From: "Sweigert, David" <[e-mail]>
Subject: new email address
To: "Kent, Steve-GTEI" <[e-mail]>, Paul Hoffman / IMC <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

New email address:

[e-mail]

replaces

[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA18246 for ietf-pkix-bks; Mon, 14 Jun 1999 05:22:49 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA18242 for <[e-mail]>; Mon, 14 Jun 1999 05:22:44 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Mon, 14 Jun 1999 13:22:38 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id NAA18777; Mon, 14 Jun 1999 13:22:36 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id NAA04957; Mon, 14 Jun 1999 13:22:35 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: Denis Pinkas <[e-mail]>
cc: Russ Housley <[e-mail]>, Stephen Farrell <[e-mail]>, [e-mail]
Subject: Re: X.509 ACs vs. SPKI? 
In-reply-to: Your message of "Mon, 14 Jun 1999 14:08:49 +0200." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 14 Jun 1999 13:22:34 +0100
From: Stephen Farrell <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

> The basic question is the way(s) that are used to prevent the
> stealing of the attributes. They can be a clear text, with a good way to 
> protect them against stealing using only integrity mechanism techniques.

I guess this is where the difference arises. If I have a clearance
of SECRET then (it can be the case that) I'm not just concerned that 
someone else could steal that attribute, but I'm also concerned that
no-one (except certain people/servers) should find out that I've got
SECRET clearance.

So, prevention of attribute stealing is not the only basic question.

Regards,
Stephen.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA18101 for ietf-pkix-bks; Mon, 14 Jun 1999 05:08:24 -0700 (PDT)
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 FAA18095 for <[e-mail]>; Mon, 14 Jun 1999 05:08:17 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id OAA20538; Mon, 14 Jun 1999 14:07:23 +0200
Message-ID: <[e-mail]>
Date: Mon, 14 Jun 1999 14:08:49 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Stephen Farrell <[e-mail]>, [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I receive more messages than I can read, hence the reason why I reply late to this
one sent two weeks ago.

> Denis:
>
> I disagree.  There are a few real needs for encrypted attributes.  When a
> user is granted certain authorizations, even briefly, they may become a
> prime target.

This is not still an argument that demonstrates the need for encryption.

> I would hate for plaintext authorizations to flag these
> particular users.

I do not understand.

> Encryption of these attributes is not the whole solution, but it is an
> important aspect of the solution.  If one AA issues all of these highly
> valuable authorizations, then the AA must also issue other less valuable
> (and encrypted) authorizations.

You are making a categorization of the value of the attributes on the basis that
high value attributes are encrypted and low value are not. I do not think that this
view is correct. The basic question is the way(s) that are used to prevent the
stealing of the attributes. They can be a clear text, with a good way to protect
them against stealing using only integrity mechanism techniques.

> Otherwise, any recipient of an AC from
> that AA becomes a target.
>
> In summary:  encryption is necessary but not sufficient.

On the contrary, I think that the above explanations do not demonstrate that
encryption is necessary..

Denis

>
> Russ
>
> At 12:40 PM 5/28/99 +0200, Denis Pinkas wrote:
> >Stephen,
> >
> >I don't want to get into deep discussion here but ...
> >
> >> Aram,
> >>
> >> > Does either path offer the ability to grant a permission without revealing
> >> > the identity of who is being granted the permission? I was talking with
> >some
> >> > folks yesterday who want to implement a very large PKI system used to
> >access
> >> > control but they have legal requirements in certain cases to keep the
> >> > identity of the user private.
> >>
> >> Can't recall for spki, but the ACs I-D does have support
> >> for encrypted attributes,
> >
> >I would not recommend to support encrypted attributes even if the ISO
> >document and
> >the current draft allow for it. It is an extra level of complexity and we
> >can live
> >without it for the moment (and maybe for ever).
> >
> >
> >> but this is more a case
> >> of concealing the permissions, rather than the identity
> >> which is presumably visible in a public key cert anyway.
> >
> >Pseudonyms can be used in a public key certificate and thus the name of the
> >signer
> >maybe be reasonably cancelled.
> >
> >Regards,
> >
> >Denis
> >
> >>
> >> Regards,
> >> Stephen.
> >



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA17255 for ietf-pkix-bks; Mon, 14 Jun 1999 03:33:53 -0700 (PDT)
Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA17251; Mon, 14 Jun 1999 03:33:51 -0700 (PDT)
Received: from GK-Portable (unverified [62.188.136.187]) by pegasus.group5.co.uk (Rockliffe SMTPRA 2.1.5) with SMTP id <[e-mail]>; Mon, 14 Jun 1999 11:26:40 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 14 Jun 1999 11:35:17 +0100
To: [e-mail]
From: Graham Klyne <[e-mail]>
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 05:57 12/06/99, Peter Gutmann wrote:

>Since the distribution now includes new people (ietf-smime) I'll give the 
>Readers Digest version of what I said in an earlier message:

Thanks for that.

>[...]   and since I'm pretty picky about 
>doing things the way PKIX requires the only way they could get self-issued 
>certs to work is to make everyone a CA.

Time for a dumb question, if I may.

What is the problem with this?  Unless I'm missing something (likely :-),
being a CA is no big deal security-wise.  I don't see any special trust
conferred on that basis alone.

#g



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA10635 for ietf-pkix-bks; Fri, 11 Jun 1999 10:56:34 -0700 (PDT)
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 KAA10605; Fri, 11 Jun 1999 10:55:56 -0700 (PDT)
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 FAA22465; Sat, 12 Jun 1999 05:57:32 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92912385229677>; Sat, 12 Jun 1999 05:57:32 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail], [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 12 Jun 1999 05:57:32 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"David P. Kemp" <[e-mail]> writes:

>>From: Paul Hoffman / IMC <[e-mail]>
>>
>>Exactly right. And, as Peter has pointed out yet again, there is a business
>>desire for "trust me after some out-of-band validation" certs that is so
>>strong, there are many examples IN USE TODAY of them. I'll trust him when
>>he says they are not interoperable; that certainly sounds likely to me.
>>
>>Telling these people "don't use PKIX" is silly. We want as many people
>>using PKIX as possible so that application vendors don't have to support
>>two different cert formats to hold keys that are being used in the same way.

>I'm confused about exactly what the "strong business desire" is for, and how 
>it relates to the proposed solutions.

Since the distribution now includes new people (ietf-smime) I'll give the 
Readers Digest version of what I said in an earlier message:

1. Free or low-cost certificate tools are becoming more and more widespread.
2. Businesses are using these more and more: "The software's free, we have
   the expertise to do it in-house, why do we need to pay a CA for it?"
   (Classical manglement thinking at work).

The problem with this approach is that X.509 doesn't define a format for:

1. A standalone end-entity certificate verified using out-of-band means.
2. An encryption-only cert signed with an end-entity signature-only cert
   verified via the usual CA mechanism.

Both of these results are what businesses are trying to do based on the
manglement thinking presented above, with the result that you end up with
whatever cert kludges are required by the toolkit they're using to make this
possible (eg everyone is a CA and signs their own certs, a single certificate
vending machine-type app is used to sign everyone's certs just to get the 
public key into X.509 format, someone is appointed to generate everyone's keys
for them so they can sign the public portion with a fixed CA cert before they 
send them out to the users(!!!), etc etc etc).

The result was a thread containing various ways to achieves this, with no
clear consensus being reached (several people had done it, but their ways
of doing it were all different).

>Here's a simple proposal, involving the addition of one signed attribute to 
>CMS section 11:

That's a nice way to do it using existing mechanisms, but it's almost but not 
quite completely unlike the required solution :-).  What people are trying to 
do is create certs managed through means other than the full CA 
infrastructure, and use the resulting certs (full certs, not just raw public 
keys) with web servers, in custom signing applications, in EDI software, and 
God knows what else (for example I know of one company who do a web-browser
plugin which signs data sent from the user back to a central server where 
noone's going to pay a CA for a cert when the entire app with an infinite-user
license sells for a few hundred dollars.  In this case they're going to set up
every user as a CA with their own self-signed CA cert, and the software is 
coded to treat them as EE certs.  The reason I know about this particular case
is that they're using my software to do it, and since I'm pretty picky about 
doing things the way PKIX requires the only way they could get self-issued 
certs to work is to make everyone a CA.  I don't know whether they've released 
this yet, but from talking to them in the past they're going to end up with a 
fair number of users, and there are many other companies doing things this way
as well).

As I see it, there are three options:

1. Define a format for the two cases described above and try and get 
   developers of toolkits and whatnot to stick with it, so that when people
   do employ these certs you can identify them and work with them as required
   (which could include just refusing to handle them if you feel so inclined).
2. Educate every IT person on the planet about the wonders of X.509 and
   convince them all to do it the way they're supposed to do it rather than in
   a way where they can ship a product as quickly and cheaply as possible.
3. Continue to ignore the issue and end up with an ever-increasing number of 
   homegrown kludges which at best won't interoperate with anything else and
   at worst will severely screw up any other software which tries to use it.

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA10547 for ietf-pkix-bks; Fri, 11 Jun 1999 10:45:25 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA10543 for <[e-mail]>; Fri, 11 Jun 1999 10:45:24 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id KAA11658; Fri, 11 Jun 1999 10:43:54 -0700 (PDT)
Received: from peternt (static-3-26.engineering.valicert.com [192.168.3.26] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id KAA07198; Fri, 11 Jun 1999 10:44:57 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Certificate requests for encryption keys
Date: Fri, 11 Jun 1999 10:52:38 -0500
Message-ID: <091901beb422$6e57ad00$[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 V5.00.2314.1300
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Adding subscriber-issued X.509 certs is a
perfectly reasonable value-add. As Steve
says, however, one way to accomplish this, and it
works today, is for each S/MIME user
to subscribe to a licensed legalistic CA
to obtain a msg-signing capability; and then
use that S/MIME signed msg to distribute
their own unlicensed, self-signed CA cert around the
world to register their own
domain with whoever can receive S/MIME
messages, and learn authoritative
trust-points contained in the signed content.
Today this community is at least the size
of the modern Windows-using population....
via MSIE and Netscape Communicator.

Nothing in the VeriSign CPS prohibits
this behavior, BTW. ("this" = use
S/MIME and verisign certs to
authoritatively distribute self-signed
public keys)









> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf
> Of Peter Gutmann
> Sent: Thursday, June 10, 1999 8:00 AM
> To: [e-mail]; [e-mail]
> Subject: Re: Certificate requests for encryption keys
>
>
> Al Arsenault <[e-mail]> writes:
>
> >It's actually very straightforward.  In fact, we implemented it
> several years
> >ago.
>
> And so, I suspect, has half the rest of the planet :-).  All in
> incompatible
> ways.
>
> >(2) change the rules so that
>
> That's one way to do it, but pretty much any way is fine as long
> as you choose
> a consistent interpretation and stick with it.
>
> >But, after doing all of this, the question that arises is the one already
> >posed by Dave Kemp:  why do you want to do this?  Certainly, I
> can understand
> >financially-based desires - for security reasons, you want a new key
> >management certificate every month, or every day, and you don't
> want to pay
> >$24.95 or $159.95 everytime you get one. But that doesn't strike
> me as being
> >a good reason to change a technical system so dramatically.
>
> I'm not asking for any great change, merely the opportunity to
> store and/or
> exchange a key without requiring all the usual CA baggage which
> X.509 currently
> requires.  Define a format and let the market decide - if there's
> really no
> demand then, as the style guide says, "It will founder upon the rocks of
> iniquity and sink headfirst to vanish without trace into the seas
> of oblivion".
>
> I mentioned earlier that I've seen a number of organisations who are using
> self-signed certificates, this process works roughly as follows:
>
> Management, stage 1:
>
>   "We need to use certificates" (they generally don't know why,
> but they know
>    they need to use them for something).
>
> Management, stage 2:
>
>   "Look at these prices!  And we have to pay this each year for all 50,000
>    users... we should have the expertise to do this in-house".
>
> Overworked sysadmin who didn't run fast enough when he heard the
> key phrase "we
>     should have the in-house expertise":
>
>   [Playing with whatever that certificate program is which MS
> ships free with
>    MSDN, or whatever mechanism it is they use to get it into
> every Windows shop
>    on the planet]
>   "We can issue our own certificates, and it'll cost us nothing.
> It took me
>    awhile to find, but if you set it up like this (self-signed
> certs) it works"
>
> Management:
>
>   "Very good.  Have a scooby snack".
>
> I realise that this is probably great news for Microsoft and less
> great news
> for people pushing CA's and CA software, but that's the situation
> I've found
> God knows how many times when talking to smaller companies who
> are playing with
> the use of certs.  I'm sure that if MS added some standard option
> to create
> self-issued EE certs with one or two mouse clicks, half the
> Windows shops on
> the planet would be using nothing but these certs (free and
> self-issued) within
> a few service packs time.
>
> Peter.
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA09035 for ietf-pkix-bks; Fri, 11 Jun 1999 08:06:13 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA09031; Fri, 11 Jun 1999 08:06:12 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA02279; Fri, 11 Jun 1999 11:08:13 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA02272; Fri, 11 Jun 1999 11:08:13 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA00723; Fri, 11 Jun 1999 11:08:16 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id LAA16764; Fri, 11 Jun 1999 11:01:09 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 11 Jun 1999 11:01:09 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Certificate requests for encryption keys
To: [e-mail]@ara.missi.ncsc.mil
Cc: [e-mail]@ara.missi.ncsc.mil
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: w5LphXXmPJtyWof6sPduDw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: Paul Hoffman / IMC <[e-mail]>
> 
> Exactly right. And, as Peter has pointed out yet again, there is a business 
> desire for "trust me after some out-of-band validation" certs that is so 
> strong, there are many examples IN USE TODAY of them. I'll trust him when 
> he says they are not interoperable; that certainly sounds likely to me.
> 
> Telling these people "don't use PKIX" is silly. We want as many people 
> using PKIX as possible so that application vendors don't have to support 
> two different cert formats to hold keys that are being used in the same way.


Paul,
  I think you're a nice guy too :-), but I'm confused about exactly what
the "strong business desire" is for, and how it relates to the proposed
solutions.

I believe this thread began with a desire to *NOT* do out-of-band
validation, but instead to leverage the assurance provided by X.509
identity certificates (and the Internet X.509 PKI or a closed/local
X.509 PKI) to validate encryption keys.  I'm certain that that is the
need expressed by Bill Burr.

I also believe that the need for encryption keys can be grouped into
two categories: protecting data at rest, and protecting data in
transit.  IPSEC/IKE is one mechanism for protecting data in transit,
which uses identity certificates and uncertified key establishment
keys.

This message addresses protecting data at rest, similarly using
an encryption key with assurance inherited from a certified identity
(an X.509 signature certificate). It does not require any out-of-band
operations on the encryption key. It assumes that the out-of-band
operations related to establishing trust in the signature key are
already in place.  Given that environment, it seems to me that it is
more appropriate to standardize a single mechanism and promote
interoperability in the data protection protocol - CMS - than in
the key certification infrastructure protocol - X.509.

Here's a simple proposal, involving the addition of one signed attribute
to CMS section 11:


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

11  Useful Attributes
   ...

11.6  Public Key

  The PublicKey attribute type specifies a public key which can be
  referenced in lieu of X.509 certificates in the EnvelopedData content
  type.  This attribute is used to allow the message signer to specify
  a public encryption key to be used in enveloped messages sent
  to the signer.
  
  The following object identifier identifies the PublicKey attribute:
  
    id-publicKey OBJECT IDENTIFIER ::= { ... }
  
  PublicKey attribute values have ASN.1 type PublicKey:
    
    PublicKey ::= SEQUENCE {
      kid           SubjectKeyIdentifier,
      keyInfo       SubjectPublicKeyInfo  }

    SubjectPublicKeyInfo ::= SEQUENCE {    -- Copied or Imported from X.509
      algorithm     AlgorithmIdentifier,
      publicKey     BIT STRING  }
    
  
----------------------------------------------------------------------

Note that almost no other changes should be required to the CMS specification
to enable the use of keys instead of certificates:

Section 6.1: "originatorInfo optionally provides information about the
  originator.  It is present only if required by the key management
  algorithm."      (OriginatorInfo contains certs and CRLs.)
  
Section 6.2.1: 

    rid  EntityIdentifier,
   
  EntityIdentifier ::= CHOICE {
    issuerAndSerialNumber  IssuerAndSerialNumber,
    subjectKeyIdentifier   [0] SubjectKeyIdentifier  }

  "rid specifies the recipient's certificate or key that
   was used by the sender to protect the content-encryption key."


Change:
  "The EntityIdentifier is a CHOICE with two alternatives specifying the
  recipient's certificate, and thereby the recipient's public key."
  
to:
  "The EntityIdentifier is a CHOICE with two alternatives specifying the
  recipient's certificate or the recipient's public key."


Add a line to the table in ESS Section 1.3.4 specifying that the
PublicKey attribute MUST be signed, and may be either Inner or Outer
in a triple-wrapped message.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA10794 for ietf-pkix-bks; Thu, 10 Jun 1999 11:46:35 -0700 (PDT)
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 LAA10790 for <[e-mail]>; Thu, 10 Jun 1999 11:46:34 -0700 (PDT)
Received: from [128.33.238.219] (tc238-219.bbn.com [128.33.238.219]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA25547; Thu, 10 Jun 1999 14:48:20 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a01b38597e116fc@[128.33.238.73]>
In-Reply-To: <[e-mail]>
Date: Thu, 10 Jun 1999 12:34:40 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Your description of the problem, and the home grown solutions does not
sound that far off from what I suggested.  A self-signed CA cert is just as
legitimate in a local setting as are the self-signed CA "root" certs built
into the browsers.  I see no need to change anything to accommodate this
approach of creating PKIs.  Note that several of the complaints that your
think IT managers may cite are common misperceptions, e.g., the need to pay
a third party to create certs for all of your staff, and to pay again every
year. This may be the VeriSign model of business, but it is not intrinsic
to X.509 nor to PKIX.

So, given the growing availability of cheap or free CA software (which
usually does not scale well notr have all the nice features of the more
costly stuff), why nit follow the approachj I suggested, create self-signed
a CA cert, and issue EE certs under it as a means of facilitating the key
exchange that is the desired goal?  if client software is designed to work
in such environments, which it should be if PKIX compliant, then one can
piggyback on this software, which is also everyones goal, right?  That
seems preferable, and more amenable to scaling that developing changes to
the standards and changes to client software to accommodate an OOB
distriubution mechanism other than one based on self-signed CA certs.

steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA07928 for ietf-pkix-bks; Thu, 10 Jun 1999 07:59:35 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA07924 for <[e-mail]>; Thu, 10 Jun 1999 07:59:34 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA09098 for <[e-mail]>; Thu, 10 Jun 1999 11:01:30 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA09094 for <[e-mail]>; Thu, 10 Jun 1999 11:01:29 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA20364 for <[e-mail]>; Thu, 10 Jun 1999 11:01:32 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA15416 for <[e-mail]>; Thu, 10 Jun 1999 10:58:53 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 10 Jun 1999 10:58:53 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Possible clarification to RFC 2459
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 5uKKdXFppjuk86U9JCBDPA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The preferred approach depends on how we choose to define "CA" for
scoping the requirement to "issue complete CRLs covering all
certificates it issues".

One could regard a CA as a "virtual CA" covering a single distribution
point, and the complete CRL requirement would be satisfied by a CRL
which covers all user certs, all CA certs, and all revocation reasons
for that distribution point plus all non-DP certs.

Or one could regard a CA as a single issuer DN, in which case the
complete CRL would cover all user certs, all CA certs, and all revocation
reasons for all distribution points plus all non-DP certs.

Since it is possible to create an arbitrary number of "CAs" (issuer
DNs) operating on a single piece of hardware or run by a single trained
operator, partitioning for CRL scaling purposes can be achieved by
creating more issuer DNs instead of creating more distribution points.
If the goal is to minimize the size of the largest CRL which must
be generated and distributed (through the directory system or otherwise)
when an administrative entity (an equipment operator with a Certificate
Policy) is responsible for a huge number of certs, then there is a
choice between:
1) treating each DP as a virtual CA for completeness purposes, and
2) creating a set of actual CAs (issuer DNs) sharing the same
   operator and CP.

I think that it is more natural and intuitive to have a single DN and a
set of DPs than a set of (somewhat artificial) DNs.  I think that
X.509, by allowing the directoryName form of distributionPoint,
recognizes the value of keeping a single issuer DN for multiple CRL
partitions.  But I recognize that regarding the DN/DP combination as
the definition of "it" in "covering all certificates it issues" might
not be intuitive.


I agree with your likely deployment scenarios.  One way to transition
from non-DP certs to exclusively DP certs would be to initially create
a single DP which is the default location for non-DP certs, and issue
certs (and CRLs) for only that DP until all non-DP certs have expired.
After the transition period has ended, additional DPs can be created.
Under that transition plan, there is no penalty for including non-DP
certs in the DP CRL.

Under a transition plan where a large number of DPs are created
immediately, there is a penalty for including non-DP certs in all of
the DP CRLs, but the penalty is temporary, lasting only until the
non-DP certs expire.

But if there must always be a non-DP CRL that covers all DP and non-DP
certs, then the penalty for maintaining that CRL never goes away.
That's what I'd like to avoid.

  Dave Kemp



> From: [e-mail]
>
>   [...]
>
>      In considering which CRL's should need to contain revocations for non-DP
> certificates (those which contain no CRLDistributionPoint extension), it might
> be useful to consider under what circumstances a CA would have generated both 
DP
> and non-DP certificates.  It seems to me that the  likeliest scenarios are
> first, that a software upgrade has been performed that "turns on" distribution
> points as a feature so that old certificates are non-DP while new ones are DP;
> second, that CA certificates are considered as belonging to an existing
> partitioned CRL of manageable size (one with no name, but with the
> onlyContainsCACerts flag set) so that they are non-DP while user certificates
> are DP; and third, a combination of the two effects, in which the only new
> non-DP certificates are CA certificates.  In all of these cases, no new non-DP
> user certificates are being issued.
>      The other issue here is how a verifier gets a CRL and then knows that he
> has obtained the correct CRL.  For any non-DP certificate, the verifier will
> have to try to get the CRL from the default repository for the CA.  Since the
> global CRL will have to be maintained anyway, in conformance to X.509's note f
> to section 12.6.1 (June '97 version) which states, "every CA shall, as a 
common
> fall-back approach, issue complete CRLs covering all certificates it issues", 
it
> will presumably be reachable there.  Thus I don't see why other CRL's should
> have to include the non-DP certificates.
> 
>           Tom Gindin



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA01620 for ietf-pkix-bks; Thu, 10 Jun 1999 02:45:04 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA01613 for <[e-mail]>; Thu, 10 Jun 1999 02:44:59 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id TAA16563; Thu, 10 Jun 1999 19:48:32 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: "'Juan G. de la Vega'" <[e-mail]>, "'Manger, James'" <[e-mail]>, <[e-mail]>
Subject: RE: Timestamp: TDA in timestamp
Date: Thu, 10 Jun 1999 19:44:01 +1000
Message-ID: <003d01beb325$c7bff300$[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: <00db01beb314$40447a60$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juan, James, All,
So, I believe, we all tend to agree that having TDA token inside TSA token
is redundant, right?

I'd like to speculate a bit on the avail of having TDA as a separate
service.

The major difference between TDA and TSA is that a TD token can demonstrate
that the datum WAS STAMPED NOT BEFORE certain time (the photo of a person
with a newspaper was taken NOT BEFORE the newspaper has been published).
My question is - what is the commercial value of knowing that?
It does NOT prove that the document DID NOT exist before (the person could
be there long before the paper was published and the photo taken).
It does NOT prove that the document DID exist before (a man-with-the-paper
could magically appear out of the universe a second before the photo was
taken).
It does NOT prove that the document existed at some particular moment of
time, unless TDA uses services of third-party TSA, instantly making itself
redundant.

So my conclusion is that TD is pretty useless. I am prepared to receive a
lot of mail with a lot of abuse with a lot of happy :).

Regards
MichaelZ

-----Original Message-----
From: Juan G. de la Vega [mailto:[e-mail]]
Sent: Thursday, June 10, 1999 5:39 PM
To: [e-mail]; 'Manger, James'; [e-mail]
Subject: RE: Timestamp: TDA in timestamp


All,

    I think that TD issues need clarification within this draft. Assuming
that temporal data are values derived from the result of a given
unpredictable, high-entropy, and *recent* event (if this is not so, then I
doubt the utility for this and please disregard the rest of the message),
from the very theoretical point of view this kind of data are useful per se.
Their unpredictable nature makes them suitable for providing proofs of
"after than", the association of a given datum with these temporal data
(i.e. hashing together or signing) provides that the datum existed after
that the event ocurred (It is the case of the photograph of a hostage
holding a newspaper).
This is useful to construct proofs of possesion, to prevent from forward
dating and to provide leaps of existence (after-before). It is therefore
sensible to think of a TD Service as an independent service provided to end
users and not only to TSAs.

The interest of these data is their unpredictable nature and the possiblity
to check its validity using widely spread resources afterwards (dow jones
average closing value is a good example).
So the question is whether it is needed to sign those data, since no further
value is added (verification process implies the query those available
trusted sources not the formal verification of a signature). If a TSA is to
provide an interval service, then temporal data should be provided by the
TSA itself for the trust on temporal data is in the data themselves not
provided by external wrappings (i.e. the authority signing). So it may be
understood that a TDA is a TTP in the sense of assuring a given *quality* of
the events selected to provide temporal data.

Summarizing, TDS can be a useful service itself, the value is in the data
themselves (everyone who has access to that data could become a TDA, even
the client of the TSA). In terms of trust, TDA does not grant anything but
the impossibility to forward date, so if the TSA is trusted for providing
accurate time there is no need for TDA tokens, in this case TDA is not
supplementary, it is redundant in terms of time (i.e. event result contained
in TSToken will always be available previos to the time stamped).

regards,
Juan.





>Well, I guess the reason for having TDA tokens INSIDE time stamp token and
>OPTIONAL is explained by the draft as "...TDA... provides supplementary
>evidence for the time...". The time stamp is the prime goal ("datum existed
>before a particular time"), and anything else (i.e. "datum existed during a
>particular event's life span") is supplementary and largely redundant
>knowledge.
>To me, the fact that TDA handling and associated structures are described
in
>the dark and gloomy corner of the draft, signifies that the authors have
>reasonable amount of doubts in potential usefulness of TDA tokens. I feel
>that as the time stamping infrastructure matures, the TDA will eventually
>either 1) evolve into a separate service, used directly by the clients,
>supplying time stamped data (exactly what you have proposed), or 2)
>disappear from the PKI fields.
>
>After all, why do we need any supplementary evidence of timing if you trust
>TSA? If you do not trust TSA, then how can you trust TDA token obtained and
>verified by [non-trusted] TSA? The complexity of dealing with TDAs does not
>seem to justify the value of extra supplementary info in the time token.
>Would like to hear any other opinions.
>
>Regards
>MichaelZ
>
>
>>Why are TDA tokens included in timestamp tokens?  Why not the other way
>around?  Why shouldn't clients go directly to a TDA?
>
>>A TDA says a datum existed before a particular event.
>>A TSA says a datum existed before a particular time.
>>Their similarities should means similar syntaxes can be used for their
>tokens & similar protocols for interacting with them.  Perhaps even common
>syntaxes and >protocols with a small number CHOICE or OPTIONAL fields could
>be used.
>
>>Nesting TDAs within TSA tokens, however, does not make much sense.  This
is
>highlighted by the fact that the TemporalDataToken, as used for the
>tdaTokens field of >TSTInfo, is not even defined in the main body of the
>draft standard (it is in an appendix).  Appendix C.3. adds lots of onerous
>requirements to a TSA that it is not >interested in: verifying TDA
>signatures, checking TDA names, nonces, interacting with a TDA, etc.
>
>>If nesting of TDA & TSA tokens is a useful feature
>>Nesting can always be implemented "outside" the protocol by getting, say,
a
>TDA token then having this timestamped (i.e. send the hash of the TDA token
>as a >messageImprint to a TSA).  Attribute syntaxes to hold all the
>resulting tokens would then be useful.
>
>
>>=> remove the tdaTokens field from TSTInfo
>>=> perhaps replace tstTime with
>> value CHOICE {
>> time TSTTime, -- used by TSA
>> temporalData TemporalData -- used by TDA
>> }
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA29671 for ietf-pkix-bks; Thu, 10 Jun 1999 00:39:59 -0700 (PDT)
Received: from fnmt.es ([194.224.76.148]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA29666 for <[e-mail]>; Thu, 10 Jun 1999 00:39:57 -0700 (PDT)
Received: from [192.168.1.176] by fnmt.es (NTMail 3.02.13) with ESMTP id wa009148 for <[e-mail]>; Thu, 10 Jun 1999 09:42:34 +0100
Message-ID: <00db01beb314$40447a60$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: <[e-mail]>, "'Manger, James'" <[e-mail]>, <[e-mail]>
Subject: RE: Timestamp: TDA in timestamp
Date: Thu, 10 Jun 1999 09:38:32 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

    I think that TD issues need clarification within this draft. Assuming
that temporal data are values derived from the result of a given
unpredictable, high-entropy, and *recent* event (if this is not so, then I
doubt the utility for this and please disregard the rest of the message),
from the very theoretical point of view this kind of data are useful per se.
Their unpredictable nature makes them suitable for providing proofs of
"after than", the association of a given datum with these temporal data
(i.e. hashing together or signing) provides that the datum existed after
that the event ocurred (It is the case of the photograph of a hostage
holding a newspaper).
This is useful to construct proofs of possesion, to prevent from forward
dating and to provide leaps of existence (after-before). It is therefore
sensible to think of a TD Service as an independent service provided to end
users and not only to TSAs.

The interest of these data is their unpredictable nature and the possiblity
to check its validity using widely spread resources afterwards (dow jones
average closing value is a good example).
So the question is whether it is needed to sign those data, since no further
value is added (verification process implies the query those available
trusted sources not the formal verification of a signature). If a TSA is to
provide an interval service, then temporal data should be provided by the
TSA itself for the trust on temporal data is in the data themselves not
provided by external wrappings (i.e. the authority signing). So it may be
understood that a TDA is a TTP in the sense of assuring a given *quality* of
the events selected to provide temporal data.

Summarizing, TDS can be a useful service itself, the value is in the data
themselves (everyone who has access to that data could become a TDA, even
the client of the TSA). In terms of trust, TDA does not grant anything but
the impossibility to forward date, so if the TSA is trusted for providing
accurate time there is no need for TDA tokens, in this case TDA is not
supplementary, it is redundant in terms of time (i.e. event result contained
in TSToken will always be available previos to the time stamped).

regards,
Juan.





>Well, I guess the reason for having TDA tokens INSIDE time stamp token and
>OPTIONAL is explained by the draft as "...TDA... provides supplementary
>evidence for the time...". The time stamp is the prime goal ("datum existed
>before a particular time"), and anything else (i.e. "datum existed during a
>particular event's life span") is supplementary and largely redundant
>knowledge.
>To me, the fact that TDA handling and associated structures are described
in
>the dark and gloomy corner of the draft, signifies that the authors have
>reasonable amount of doubts in potential usefulness of TDA tokens. I feel
>that as the time stamping infrastructure matures, the TDA will eventually
>either 1) evolve into a separate service, used directly by the clients,
>supplying time stamped data (exactly what you have proposed), or 2)
>disappear from the PKI fields.
>
>After all, why do we need any supplementary evidence of timing if you trust
>TSA? If you do not trust TSA, then how can you trust TDA token obtained and
>verified by [non-trusted] TSA? The complexity of dealing with TDAs does not
>seem to justify the value of extra supplementary info in the time token.
>Would like to hear any other opinions.
>
>Regards
>MichaelZ
>
>
>>Why are TDA tokens included in timestamp tokens?  Why not the other way
>around?  Why shouldn't clients go directly to a TDA?
>
>>A TDA says a datum existed before a particular event.
>>A TSA says a datum existed before a particular time.
>>Their similarities should means similar syntaxes can be used for their
>tokens & similar protocols for interacting with them.  Perhaps even common
>syntaxes and >protocols with a small number CHOICE or OPTIONAL fields could
>be used.
>
>>Nesting TDAs within TSA tokens, however, does not make much sense.  This
is
>highlighted by the fact that the TemporalDataToken, as used for the
>tdaTokens field of >TSTInfo, is not even defined in the main body of the
>draft standard (it is in an appendix).  Appendix C.3. adds lots of onerous
>requirements to a TSA that it is not >interested in: verifying TDA
>signatures, checking TDA names, nonces, interacting with a TDA, etc.
>
>>If nesting of TDA & TSA tokens is a useful feature
>>Nesting can always be implemented "outside" the protocol by getting, say,
a
>TDA token then having this timestamped (i.e. send the hash of the TDA token
>as a >messageImprint to a TSA).  Attribute syntaxes to hold all the
>resulting tokens would then be useful.
>
>
>>=> remove the tdaTokens field from TSTInfo
>>=> perhaps replace tstTime with
>> value CHOICE {
>> time TSTTime, -- used by TSA
>> temporalData TemporalData -- used by TDA
>> }
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA04103 for ietf-pkix-bks; Wed, 9 Jun 1999 16:20:18 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04097 for <[e-mail]>; Wed, 9 Jun 1999 16:20:13 -0700 (PDT)
Received: from mcg.org.br (pm02-13.sac.verio.net [209.162.64.32]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id QAA19945; Wed, 9 Jun 1999 16:21:50 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 09 Jun 1999 16:12:16 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Blakley <[e-mail]>
CC: [e-mail], Stephen Kent <[e-mail]>
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
References: <003201beb2a3$9768e540$[e-mail]>
Content-Type: multipart/alternative; boundary="------------E1D88D8018A7081228E223B8"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Bob Blakley wrote:

> I agree with Steve here.  I think this horse is dead now, and I resolve to stop arguing
> these points.

Yes. Good ideas have been exchanged, a general need for methods stressed,
as well as the need for considering not only the number of attributes (so-called
Steve's rule) but also their individual lifetimes when estimating a certificate lifetime.
The discussions also indicated that certificate lifetime seems to be more
closely given by an inverse function of the number of attributes, which is also
contrary to the so-called Steve's rule which predicated an inverse square-function
(based on the now revealed, suck principle). So, these two hit counts surely  give
Steve the right to call off this discussion as no parts of his rule are valid any
longer  ;-)

But, judging by list reactions -- pro, con and in disbelief -- Bob Blakley was
indeed IMO not only insightful but also persistent in following through the
initial discussions in order to question whether PKIX should consider
the question of certificate lifetime in connection to attributes and costs
(whatever cost metric one wants to use), risks, presumed validity,  policies,
etc.

The issue of actually *increasing* a certificate lifetime by adding attributes was
just briefly considered here by myself, but the question of redundancy was lively
debated also by Tony Bartoletti and by Veikko Punka. Two different approaches
to deal with attribute redundancy were revealed; one which discusses redundancy
as a question relative to the observer and which I might call a subjective-frame
approach was proposed early on by myself (original posting)  and another given
recently by a n-order lifetime equation, using  what is an objective-frame
approach (David Chia).

I will be including Veikko's interesting example, as well as Tony's comments
and a comparison with David's approach to deal with redundancy in my
final paper on this.  I wish to thank all suggestions,  for their high and
oftentimes enlightening or even amusing quality.   In particular, Tony's
"dynamite sticks" metaphor was  very graphic and I have used it effectively
with varied audiences.  Even lawyers understand it ;-), so its field-proven,
I may say. Kudos to Tony.

When the full paper is done, I will supply the URL. IMO,  ideas only grow
when shared and I am thus thankful for the examples and counterexamples
provided. For  those that led this into a personal campaign,  I say that I
took the challenge, not the offense.

BTW, some have given me the pleasure of very productive private discussions
and this channel is also open for off list discussion to anyone interested.

Cheers,

Ed Gerck
_________________________________________________________________
Dr.rer.nat. E. Gerck                                                                             [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---

--------------E1D88D8018A7081228E223B8
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
&nbsp;
<p>Bob Blakley wrote:
<p><font face="Arial,Helvetica"><font color="#000000"><font size=+0>> I
agree with Steve here.&nbsp; I think this horse is dead now, and I resolve
to stop arguing</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>>
these points.</font></font></font>
<p><font face="Arial,Helvetica"><font color="#000000"><font size=+0>Yes.
Good ideas have been exchanged, a general need for methods stressed,</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>as
well as the need for considering not only the number of attributes (so-called</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>Steve's
rule) but also their individual lifetimes when estimating a certificate
lifetime.</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>The
discussions also indicated that certificate lifetime seems to be more</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>closely
given by an inverse function of the number of attributes, which is also</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>contrary
to the so-called Steve's rule which predicated an inverse square-function</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>(based
on the now revealed, suck principle). So, these two hit counts surely&nbsp;
give</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>Steve
the right to call off this discussion as no parts of his rule are valid
any</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>longer&nbsp;
;-)</font></font></font><font face="Arial,Helvetica"><font color="#000000"><font size=+0></font></font></font>
<p><font face="Arial,Helvetica"><font color="#000000"><font size=+0>But,
judging by list reactions -- pro, con and in disbelief -- Bob Blakley was</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>indeed
IMO not only insightful but also persistent in following through the</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>initial
discussions in order to question whether PKIX should consider</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>the
question of certificate lifetime in connection to attributes and costs</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>(whatever
cost metric one wants to use), risks, presumed validity,&nbsp; policies,</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>etc.</font></font></font>
<p><font face="Arial,Helvetica"><font color="#000000"><font size=+0>The
issue of actually *increasing* a certificate lifetime by adding attributes
was</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>just
briefly considered here by myself, but the question of redundancy was lively</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>debated
also by Tony Bartoletti and by Veikko Punka. Two different approaches</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>to
deal with attribute redundancy were revealed; one which discusses redundancy</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>as
a question relative to the observer and which I might call a subjective-frame</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>approach
was proposed early on by myself (original posting)&nbsp; and another given</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>recently
by a n-order lifetime equation, using&nbsp; what is an objective-frame</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>approach
(David Chia).</font></font></font>
<p><font face="Arial,Helvetica"><font color="#000000"><font size=+0>I will
be including Veikko's interesting example, as well as Tony's comments</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>and
a comparison with David's approach to deal with redundancy in my</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>final
paper on this.&nbsp; I wish to thank all suggestions,&nbsp; for their high
and</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>oftentimes
enlightening or even amusing quality.&nbsp;&nbsp; In particular, Tony's</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>"dynamite
sticks" metaphor was&nbsp; very graphic and I have used it effectively</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>with
varied audiences.&nbsp; Even lawyers understand it ;-), so its field-proven,</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>I
may say. Kudos to Tony.</font></font></font><font face="Arial,Helvetica"><font color="#000000"><font size=+0></font></font></font>
<p><font face="Arial,Helvetica"><font color="#000000"><font size=+0>When
the full paper is done, I will supply the URL. IMO,&nbsp; ideas only grow</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>when
shared and I am thus thankful for the examples and counterexamples</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>provided.
For&nbsp; those that led this into a personal campaign,&nbsp; I say that
I</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>took
the challenge, not the offense.</font></font></font>
<p><font face="Arial,Helvetica"><font color="#000000"><font size=+0>BTW,
some have given me the pleasure of very productive private discussions</font></font></font>
<br><font face="Arial,Helvetica"><font color="#000000"><font size=+0>and
this channel is also open for off list discussion to anyone interested.</font></font></font><font face="Arial,Helvetica"></font>
<p><font face="Arial,Helvetica">Cheers,</font>
<p><font face="Arial,Helvetica">Ed Gerck</font>
<br><font face="Arial,Helvetica">_________________________________________________________________</font>
<br><font face="Arial,Helvetica">Dr.rer.nat. E. Gerck&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[e-mail]</font>
<br><font face="Arial,Helvetica">&nbsp; ---&nbsp; Meta-Certificate Group
member -- <A HREF="http://www.mcg.org.br">http://www.mcg.org.br</A>&nbsp; ---</font>
</body>
</html>

--------------E1D88D8018A7081228E223B8--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA04044 for ietf-pkix-bks; Wed, 9 Jun 1999 16:16:53 -0700 (PDT)
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 QAA04038; Wed, 9 Jun 1999 16:16:51 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA18279; Wed, 9 Jun 1999 19:18:32 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0fb384a285549b@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a04b38442c1cad4@[128.89.0.110]> <[e-mail]> <v04020a01b38437f941e6@[128.89.0.110]> <[e-mail]>
Date: Wed, 9 Jun 1999 19:13:26 -0400
To: Paul Hoffman / IMC <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

>How much more strongly would you disagree with me if I were nasty? :-)

You don't want to know :-(

>>We're not in the synatx-only business here.  Certificates are a powerful
>>tool for enabling secure applications.  However, security is a VERY HARD
>>problem and part of our task in this WG is to provide a context for
>>certificate use to minimize the risks attendant with the technology.
>
>Exactly right. And, as Peter has pointed out yet again, there is a business
>desire for "trust me after some out-of-band validation" certs that is so
>strong, there are many examples IN USE TODAY of them. I'll trust him when
>he says they are not interoperable; that certainly sounds likely to me.
>
>Telling these people "don't use PKIX" is silly. We want as many people
>using PKIX as possible so that application vendors don't have to support
>two different cert formats to hold keys that are being used in the same way.

I'm all in favor of supporting folks who want to use X.509 certs, and the
PKIX profile, but that does not mean that we should change the profile just
to get a bigger "market share."  What I would suggest is explaining how to
use the existing profile to facilitate what you cite as the pressing
busines need.  It would seem pretty easy:

	- exchange, via some out of band means, public keys or
'fingerptints" thereof plus name info
	- use these as root CA keys in a simple 2-tier tree
	- issue one of more user certs under the CA
	- exchange user certs using existing mechanisms

This should work. There is often a perception that being a CA is something
special, but it ain't necessarily so, if one wanst just a simle, closed
system.  Also, there is no rule saying that you have to pay money to issue
or to get certs.  We see a growing number of products that provide for
unlimited cert issuance, with no per-cert fee.  the next version of
Windows, I am told, will contain CA code.  So, just be a CA and perform the
OOB exchange for a CA key.  That way you might even have a nice standard
way to revoke user keys if needed.


>>  There
>>are limits on how much of this we can do, since differentr contexts have
>>different security requirements.  However, in the same sense that the IESG
>>and the IAB have adopted a position that mandate strong encryption
>>algorithms as defaults for crypto protocols, I think it consistent to adopt
>>a posture that tries to establish secure management frameworks for use of
>>X.509 certificates. If one elects to employ some unspecified, out-of-band
>>management to validate certs, to revoke them, etc. then we have no idea
>>what security is provided by the resulting system, and that is not
>>consistent with the higher level goals cited above.
>
>But this is exactly what PKIX is all about, given that we don't tell people
>how to "load" root certs for path validation. Trusting root certs is by
>definition out of scope, as it should be.
>
>Let me put this another way. I can create a self-signed EE cert today by
>signing the cert with my own CA-formatted root cert, and telling the
>recipient "accept this root cert so you can trust my EE cert." Did reading
>that sentence send shivers up your spine? It should have. We do not want
>users willy-nilly adding root certs that might not be properly constrained.
>Quite frankly, we don't want them adding well-constrained root certs
>because we know in our heart of hearts that much of the path validation
>software in use today does not follow constraints correctly. (I have been
>told this by the folks who wrote the software for at least three different
>companies; they'll revise it to work better sometime this year, maybe.)

Gee, you paint an interesting choice here: badly mamaged root CA certs vs.
badly managed EE certs.  I take door number three, better client software.
Ultimately there is no substitute for it.

>If you don't want that horror scenario, maybe you might want to help
>prevent it by coming up with a standard way to pass these certs so they can
>be used in future PKIX-compliant applications.

I presented one such way above.

>>I certainly can't prevent anyone from using the X.509 format for any
>>purpose they wish, but I will resist the notion that this WG add work items
>>that facilitate such activities.
>
>Then you are fighting against something that I think is important for any
>IETF Working Group: helping interoperability by choosing one way to do
>things. I do not feel that we should be telling people "we don't want to do
>that, we'd rather spend our time arguing about minutae of timestamping and
>LDAP schema" if we could spend some effort and get a single interoperable
>solution that has all the necessary security caveats in it.

Caveats are no substitute for good designs.  I'm more in favor of working
to satisfy a desire to use what we all hope will be a growing list of PKIX
compliant clients, both with CAs of broad scope and CAs of very local
scope.  However, if the clients are not compliant to begin with, then the
users are not making use of "PKIX" after all. I am not interested in
claiming market share (e.g., vs. OPGP) by saying that any code that does
some (lame) processing of an X.509 cert is PKIX and thus we have a big PKIX
community.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03411 for ietf-pkix-bks; Wed, 9 Jun 1999 15:50:24 -0700 (PDT)
Received: from ny.us.ibm.com. (e2.ny.us.ibm.com [32.97.182.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03407 for <[e-mail]>; Wed, 9 Jun 1999 15:50:23 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id SAA33468; Wed, 9 Jun 1999 18:52:06 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.0) with SMTP id SAA154642; Wed, 9 Jun 1999 18:52:08 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525678B.007D98C1 ; Wed, 9 Jun 1999 18:51:51 -0400
X-Lotus-FromDomain: IBMUS
To: "David P. Kemp" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 9 Jun 1999 18:51:40 -0400
Subject: RE: Possible clarification to RFC 2459
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

     Dave has proposed that all CRL's, whether they have a distributionPoint
field in their IDP (issuingDistributionPoint) extension or not, must be
considered authoritative for those certificates issued by that CA which do not
have distribution points.  Because of the potentially very large number of CRL's
with distributionPoint fields containing DN's for such CA's, I propose that they
should not be considered authoritative for such certificates, but only those
CRL's which are either missing the IDP extension or have no DN in its
distributionPoint field should be considered authoritative for such
certificates.
     In considering which CRL's should need to contain revocations for non-DP
certificates (those which contain no CRLDistributionPoint extension), it might
be useful to consider under what circumstances a CA would have generated both DP
and non-DP certificates.  It seems to me that the  likeliest scenarios are
first, that a software upgrade has been performed that "turns on" distribution
points as a feature so that old certificates are non-DP while new ones are DP;
second, that CA certificates are considered as belonging to an existing
partitioned CRL of manageable size (one with no name, but with the
onlyContainsCACerts flag set) so that they are non-DP while user certificates
are DP; and third, a combination of the two effects, in which the only new
non-DP certificates are CA certificates.  In all of these cases, no new non-DP
user certificates are being issued.
     The other issue here is how a verifier gets a CRL and then knows that he
has obtained the correct CRL.  For any non-DP certificate, the verifier will
have to try to get the CRL from the default repository for the CA.  Since the
global CRL will have to be maintained anyway, in conformance to X.509's note f
to section 12.6.1 (June '97 version) which states, "every CA shall, as a common
fall-back approach, issue complete CRLs covering all certificates it issues", it
will presumably be reachable there.  Thus I don't see why other CRL's should
have to include the non-DP certificates.

          Tom Gindin



"David P. Kemp" <[e-mail]> on 06/09/99 05:00:37 PM

Please respond to "David P. Kemp" <[e-mail]>

To:   [e-mail]
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Possible clarification to RFC 2459





>> [Dave]
>>   "A CRL containing an issuingDistributionPoint extension with the
>>   distributionPoint field present MUST be authoritative for all
>>   certificates* that do not contain a CRLDistributionPoints extension."
>>
>>  *user certs, CA certs, or both, as specified in the IDP.


> [Tom Gindin]   Should that really be "with the distributionPoint field
present"
> or "without the distributionPoint field present"?  It would seem to be true
when
> the distributionPoint field is absent.

I meant "with the distributionPoint field present or absent", but intended to
emphasise that the case where it is present should be interpreted no differently
with respect to certs without CRLdp than the case where it is absent.


> I would say that "A CRL containing an
> issuingDistributionPoint extension with the   distributionPoint field
containing
> a DN MUST be authoritative for all certificates that contain that value of the
> field in their  CRLDistributionPoints extension", and also that "A CRL
> containing an issuingDistributionPoint extension without the distributionPoint
> field present MUST be authoritative for all certificates* that do not contain
a
> CRLDistributionPoints extension."  What isn't obvious, I suppose, is whether
> CRL's at named distribution points (with a DN name, as there are specifics
about
> DP's with URI names) cover certificates without distribution points.


Tom,
That is an excellent statement of the problem!

Assume that a CA issues three certs with:
  Cert1[no CRLdp]  Cert2[CRLdp 2]    Cert3[CRLdp 3]

And assume that the CA may publish three CRLs, with the following
distributionPoint fields:
  CRL1[no DP]      CRL2[DP 2]        CRL3[DP 3]

Then the CRLs are authoritative for the following certs:

  CRL1             CRL2              CRL3
  -----            -----             -----
  Cert1            Cert1?            Cert1?
  Cert2            Cert2               -
  Cert3              -               Cert3

As you say, it may not be obvious that CRLs at named distribution
points cover certs without distribution points (the ones marked
with a ? in the table).

I believe that RFC 2459 should be clarified, if necessary, to ensure
that CRL2 and CRL3 MUST be authoritative for Cert1.  That way, CRL2 can
be regarded as a "full CRL", so can CRL3, and the CA has maximum
flexibility in deciding whether to populate the CRLdp extension in its
certs.  A CA taking maximum advantage of dynamic partitioning would
never have to issue a bulky CRL1 but could still meet the requirement
of publishing a "full CRL".


That's why I disagree with Ambarish's proposal that only CRL1 (the one
with no DP field) be defined as a "full CRL".





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03025 for ietf-pkix-bks; Wed, 9 Jun 1999 15:32:03 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03020 for <[e-mail]>; Wed, 9 Jun 1999 15:31:58 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <MS6DK1KV>; Thu, 10 Jun 1999 08:33:49 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC1077C3@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Delegation of rights -- end-entity issued certs.
Date: Thu, 10 Jun 1999 08:33:47 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

	snip

> I'm NOT acting as a CA in that case -- I'm not certifying that
> individual's identity
> at all.  I'm merely granting that person, presumably identified by
> someone 
> else, whatever rights I choose to delegate to that person.
	 Bob - the issue here  re "identified by someone else"  and you
are delegating rights - means that a) you trust someone else who has
done all the points of identification, and b) that they trust you  - and
you also have authority - in a certficate based system to grant
capability.. IMHO does that not make you a CA function.

	Also there is the issue of disconnection of trust by
cryptographic means - there is no reason why operationally one might
have an a system with two or more trust hierarchies - where and EE in
one relationship acts as a CA in another and that trust relationship
between the two is implied, by policy or what ever? but the question is
what is the trust, naming  and cryptographic binding between the two.

	My point is a standard defines what an EE is - in that its cert
cannot be used to verify certificate signatures 
	So if an entity generates confidentiality keys and self signs
the associated cert  - where did it get its signature key from? - and
who trusts it.

	The debate here sems to be about loosely coupling an
authentication trust hierarchy with a seperate confidentiality trust
system

	and IMHO - one should not say its a standards issue to start
with.. perhaps we need to understand the issue a bit more from a system
perspective names, trust and where the key generation for all
authentication and confidentiality services come from.

	regards alan


> Robert R. Jueneman
> Security Architect
> Network Security Development
> Novell, Inc.
> 122 East 1700 South
> Provo, UT 84606
> [e-mail]
> 1-801-861-7387


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02623 for ietf-pkix-bks; Wed, 9 Jun 1999 15:13:35 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02619 for <[e-mail]>; Wed, 9 Jun 1999 15:13:32 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <MS6DK1KQ>; Thu, 10 Jun 1999 08:15:22 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC1077C2@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: Certificate requests for encryption keys
Date: Thu, 10 Jun 1999 08:15:16 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some more comments -

> -----Original Message-----
> From:	[e-mail] 
> Sent:	Thursday, June 10, 1999 1:04 PM
> To:	[e-mail]
> Subject:	Re: Certificate requests for encryption keys
> 
> This is a general response to several messages which have pointed out
> that
> self-signed EE certs don't fit into the X.509 theology[0]... this is a
> valid
> point, however what people are trying to achieve with these certs is a
> means
> of sharing keys without external certification and authentication and
> fuzzy
> dice and chrome tailfins.  The X.509 format makes it impossible to
> just store
> or communicate a key without carrying a vast mountain of other (often
> unnecessary) baggage around with you. 
> 
	No it does not - one does not have to use a CA hierarchy of
trust with X.509 certificates  - if a common trust point is achieved by
other means or implied.
	If you dont want to obey the processing and entity definitions
of what has been standardised as an EE within a hierarchy of trust -
then dont.
	But dont say that the standard EE is at fault when you use it in
a non standard way.


	If you want to do non standard things - dont blame the
standard...
	PKI and Certficates are about information objects that tie NAMES
to key material in a shared named based system with a common point of
trust - 

	With what mechanism are you verifying names - without a PKI?.

>  I can't speak for others who have 
> posted an opinion on this, but all I'm trying to do is get a key from
> A to B
> without requiring a huge (and currently mostly nonexistant)
> infrastructure to
> do it, the same thing which PGP has been doing very successfully for
> nearly a
> decade.  All I want to do is store a key in a non-proprietary format,
> but 
> X.509 (currently) doesn't let me do that unless I get a CA to sign it
> first.
> 
	A CA is a function - not a global infrastructure - A CA can be a
bus ticket vending machine...

	Whats the operational requirement and points of trust?

	Regards alan
> I'm proposing is a key bit-bagging scheme which isn't entirely
> dependent 
> on the presence of a CA in order to function.
> 
> Peter.
> 
> [0] Whether X.509 is systematic or speculative theology is left for
> the reader
>     to decide :-).


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02537 for ietf-pkix-bks; Wed, 9 Jun 1999 15:10:20 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02533; Wed, 9 Jun 1999 15:10:18 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Wed, 09 Jun 1999 15:09:54 -0700
To: Stephen Kent <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail]
In-Reply-To: <v04020a04b38442c1cad4@[128.89.0.110]>
References: <[e-mail]> <v04020a01b38437f941e6@[128.89.0.110]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>I disagree strongly with almosty everything you said, even though you're a
>nice guy :-).

How much more strongly would you disagree with me if I were nasty? :-)

>We're not in the synatx-only business here.  Certificates are a powerful
>tool for enabling secure applications.  However, security is a VERY HARD
>problem and part of our task in this WG is to provide a context for
>certificate use to minimize the risks attendant with the technology.

Exactly right. And, as Peter has pointed out yet again, there is a business 
desire for "trust me after some out-of-band validation" certs that is so 
strong, there are many examples IN USE TODAY of them. I'll trust him when 
he says they are not interoperable; that certainly sounds likely to me.

Telling these people "don't use PKIX" is silly. We want as many people 
using PKIX as possible so that application vendors don't have to support 
two different cert formats to hold keys that are being used in the same way.

>  There
>are limits on how much of this we can do, since differentr contexts have
>different security requirements.  However, in the same sense that the IESG
>and the IAB have adopted a position that mandate strong encryption
>algorithms as defaults for crypto protocols, I think it consistent to adopt
>a posture that tries to establish secure management frameworks for use of
>X.509 certificates. If one elects to employ some unspecified, out-of-band
>management to validate certs, to revoke them, etc. then we have no idea
>what security is provided by the resulting system, and that is not
>consistent with the higher level goals cited above.

But this is exactly what PKIX is all about, given that we don't tell people 
how to "load" root certs for path validation. Trusting root certs is by 
definition out of scope, as it should be.

Let me put this another way. I can create a self-signed EE cert today by 
signing the cert with my own CA-formatted root cert, and telling the 
recipient "accept this root cert so you can trust my EE cert." Did reading 
that sentence send shivers up your spine? It should have. We do not want 
users willy-nilly adding root certs that might not be properly constrained. 
Quite frankly, we don't want them adding well-constrained root certs 
because we know in our heart of hearts that much of the path validation 
software in use today does not follow constraints correctly. (I have been 
told this by the folks who wrote the software for at least three different 
companies; they'll revise it to work better sometime this year, maybe.)

If you don't want that horror scenario, maybe you might want to help 
prevent it by coming up with a standard way to pass these certs so they can 
be used in future PKIX-compliant applications.

>I certainly can't prevent anyone from using the X.509 format for any
>purpose they wish, but I will resist the notion that this WG add work items
>that facilitate such activities.

Then you are fighting against something that I think is important for any 
IETF Working Group: helping interoperability by choosing one way to do 
things. I do not feel that we should be telling people "we don't want to do 
that, we'd rather spend our time arguing about minutae of timestamping and 
LDAP schema" if we could spend some effort and get a single interoperable 
solution that has all the necessary security caveats in it.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA01237 for ietf-pkix-bks; Wed, 9 Jun 1999 14:01:19 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA01233 for <[e-mail]>; Wed, 9 Jun 1999 14:01:18 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id RAA26297 for <[e-mail]>; Wed, 9 Jun 1999 17:03:11 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id RAA26293 for <[e-mail]>; Wed, 9 Jun 1999 17:03:11 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id RAA14466 for <[e-mail]>; Wed, 9 Jun 1999 17:03:14 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id RAA15078 for <[e-mail]>; Wed, 9 Jun 1999 17:00:37 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 9 Jun 1999 17:00:37 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Possible clarification to RFC 2459
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: D5QuNHATWwUmV6/fGo3kVw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> [Dave]
>>   "A CRL containing an issuingDistributionPoint extension with the
>>   distributionPoint field present MUST be authoritative for all
>>   certificates* that do not contain a CRLDistributionPoints extension."
>> 
>>  *user certs, CA certs, or both, as specified in the IDP.


> [Tom Gindin]   Should that really be "with the distributionPoint field present"
> or "without the distributionPoint field present"?  It would seem to be true when
> the distributionPoint field is absent.

I meant "with the distributionPoint field present or absent", but intended to
emphasise that the case where it is present should be interpreted no differently
with respect to certs without CRLdp than the case where it is absent.


> I would say that "A CRL containing an
> issuingDistributionPoint extension with the   distributionPoint field containing
> a DN MUST be authoritative for all certificates that contain that value of the
> field in their  CRLDistributionPoints extension", and also that "A CRL
> containing an issuingDistributionPoint extension without the distributionPoint
> field present MUST be authoritative for all certificates* that do not contain a
> CRLDistributionPoints extension."  What isn't obvious, I suppose, is whether
> CRL's at named distribution points (with a DN name, as there are specifics about
> DP's with URI names) cover certificates without distribution points.


Tom,
That is an excellent statement of the problem!

Assume that a CA issues three certs with:
  Cert1[no CRLdp]  Cert2[CRLdp 2]    Cert3[CRLdp 3]

And assume that the CA may publish three CRLs, with the following
distributionPoint fields:
  CRL1[no DP]      CRL2[DP 2]        CRL3[DP 3]

Then the CRLs are authoritative for the following certs:

  CRL1             CRL2              CRL3
  -----            -----             -----
  Cert1            Cert1?            Cert1?
  Cert2            Cert2               -
  Cert3              -               Cert3

As you say, it may not be obvious that CRLs at named distribution
points cover certs without distribution points (the ones marked
with a ? in the table).

I believe that RFC 2459 should be clarified, if necessary, to ensure
that CRL2 and CRL3 MUST be authoritative for Cert1.  That way, CRL2 can
be regarded as a "full CRL", so can CRL3, and the CA has maximum
flexibility in deciding whether to populate the CRLdp extension in its
certs.  A CA taking maximum advantage of dynamic partitioning would
never have to issue a bulky CRL1 but could still meet the requirement
of publishing a "full CRL".

That's why I disagree with Ambarish's proposal that only CRL1 (the one
with no DP field) be defined as a "full CRL".




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01089 for ietf-pkix-bks; Wed, 9 Jun 1999 13:41:13 -0700 (PDT)
Received: from wodc7-1.relay.mail.uu.net (wodc7-1.relay.mail.uu.net [199.171.54.114]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01085 for <[e-mail]>; Wed, 9 Jun 1999 13:41:12 -0700 (PDT)
Received: from xedia.com by wodc7mr0.ffx.ops.us.uu.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgsxe06637; Wed, 9 Jun 1999 20:42:57 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA06279; Wed, 9 Jun 99 16:42:03 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id QAA02753; Wed, 9 Jun 1999 16:42:55 -0400
Date: Wed, 9 Jun 1999 16:42:55 -0400
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: Certificate requests for encryption keys
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I may be missing something here...

If the issue is that you need a PKI that includes support for
self-signed EE certificates, that it also standardized and supported
by IKE, how about using PGP keys?  It seems that these have the
required properties.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA00861 for ietf-pkix-bks; Wed, 9 Jun 1999 13:00:22 -0700 (PDT)
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 NAA00856; Wed, 9 Jun 1999 13:00:18 -0700 (PDT)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <MSBD8WB3>; Wed, 9 Jun 1999 16:02:11 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'Hoffman, Paul'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Certificate requests for encryption keys
Date: Wed, 9 Jun 1999 16:05:07 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[e-mail]]
> Sent: 	Wednesday, June 09, 1999 11:59 AM
> To: 	Stephen Kent; [e-mail]
> Cc: 	[e-mail]
> Subject: 	Re: Certificate requests for encryption keys
> 
[snip]

> The fact that one gets X.509 self-signed root certs from a 
> directory and then does out-of-band verification says to me that there is 
> no good reason not to get self-signed EE certs from a directory if they
> are 
> then followed by out-of-band verification. If we can set up a different 
> profile of X.509 to allow the latter case, we should do so, given the 
> obvious business desire for such a system.
> 
Since the EE issuing a self-signed cert is a de facto "do-it-yourself-root
CA," and since the objective is to get self-signed EE certs from the
directory of another self-signing root CA, are we not just talking here
about root-CA cross certification?  If we are, are you suggesting a
cross-certification profile of X.509?  And if we are, is there really an
"obvious business desire for such a system"?

Bill Flanigan



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA00832 for ietf-pkix-bks; Wed, 9 Jun 1999 12:58:27 -0700 (PDT)
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 MAA00828 for <[e-mail]>; Wed, 9 Jun 1999 12:58:24 -0700 (PDT)
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 HAA19394; Thu, 10 Jun 1999 07:59:47 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92895838709114>; Thu, 10 Jun 1999 07:59:47 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Certificate requests for encryption keys
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 10 Jun 1999 07:59:47 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al Arsenault <[e-mail]> writes:

>It's actually very straightforward.  In fact, we implemented it several years
>ago.

And so, I suspect, has half the rest of the planet :-).  All in incompatible
ways.

>(2) change the rules so that

That's one way to do it, but pretty much any way is fine as long as you choose
a consistent interpretation and stick with it.

>But, after doing all of this, the question that arises is the one already
>posed by Dave Kemp:  why do you want to do this?  Certainly, I can understand
>financially-based desires - for security reasons, you want a new key
>management certificate every month, or every day, and you don't want to pay
>$24.95 or $159.95 everytime you get one. But that doesn't strike me as being
>a good reason to change a technical system so dramatically.

I'm not asking for any great change, merely the opportunity to store and/or
exchange a key without requiring all the usual CA baggage which X.509 currently
requires.  Define a format and let the market decide - if there's really no
demand then, as the style guide says, "It will founder upon the rocks of
iniquity and sink headfirst to vanish without trace into the seas of oblivion".

I mentioned earlier that I've seen a number of organisations who are using
self-signed certificates, this process works roughly as follows:

Management, stage 1:

  "We need to use certificates" (they generally don't know why, but they know
   they need to use them for something).

Management, stage 2:

  "Look at these prices!  And we have to pay this each year for all 50,000
   users... we should have the expertise to do this in-house".

Overworked sysadmin who didn't run fast enough when he heard the key phrase "we
    should have the in-house expertise":

  [Playing with whatever that certificate program is which MS ships free with
   MSDN, or whatever mechanism it is they use to get it into every Windows shop
   on the planet]
  "We can issue our own certificates, and it'll cost us nothing.  It took me
   awhile to find, but if you set it up like this (self-signed certs) it works"

Management:

  "Very good.  Have a scooby snack".

I realise that this is probably great news for Microsoft and less great news
for people pushing CA's and CA software, but that's the situation I've found
God knows how many times when talking to smaller companies who are playing with
the use of certs.  I'm sure that if MS added some standard option to create
self-issued EE certs with one or two mouse clicks, half the Windows shops on
the planet would be using nothing but these certs (free and self-issued) within
a few service packs time.

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA00488 for ietf-pkix-bks; Wed, 9 Jun 1999 12:12:55 -0700 (PDT)
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 MAA00484 for <[e-mail]>; Wed, 9 Jun 1999 12:12:51 -0700 (PDT)
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 HAA17731; Thu, 10 Jun 1999 07:14:31 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92895567009551>; Thu, 10 Jun 1999 07:14:30 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 10 Jun 1999 07:14:30 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> writes:

>Your characterization of what you are trying to do is somewhat ncomplete, 
>I suspect.  You don't want to just transfer a public key; you want to
>transfer it with some set of assurances, e.g., so that the recipient knows
>whose public key it is.

I already have those assurances:

- If it's a raw key, it'll be transferred via a trusted channel (eg I hand you
  a disk with my key on it, or send it via a sealed courier bag which in many
  jurisdictions meets the legal requirements for secure, authenticated
  transport[0]).
- If it's an encryption key signed with my signature key, you can trace
  the trust via my signature key.

>Along those lines, maybe you should make use of some other syntax if your
>goals for public key representation for transfer are not congurent with
>those stated here.  We can't be everything to everyone.  One size rarely
>fits all.

X.509, appropriately profiled, can do this.  The problem with the DIY
approach is that there are already dozens of incompatible and underdocumented
attempts at this, none of which are useful if you want to use software from
more than one vendor.  By profiling it properly, you have a standard,
recognised, interoperable way of doing what people are currently doing via
all sorts of hacks and kludges (I think I've mentioned before the number of
self-signed EE/sort-of-CA certs I've run across which are being used because 
there's no other way to do this).  People are doing it anyway (regardless of 
what X.509 theology has to say about it), so we may as well define a way to do
it in a standised manner.

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

>I'll disagree with your characterization of what Peter has asked for. There
>are many good reasons to want to use the *format* described in PKIX for
>transporting public keys without being forced to use the systems associated
>with PKIX to process the certificates. Peter is (I believe) saying "I'll do
>the assurances out of band, just let me use your format".

That's exactly it.

Peter.

[0] In NZ, which along with many other countries currently has no digital 
    signature legislation, if you want the use of digitally signed documents 
    to stand up in court, this is the safest way to handle public key 
    distribution - sealed courier envelopes have legal recognition whereas 
    CA's are just a cute academic exercise for which noone, including the 
    government (thus the lack of legislation) wants to be the test case.  It'd
    be nice to use a CA and there are pilot projects which are actually doing 
    this, but the last time I talked to corporate lawyers their advice, after 
    much analysis of the situation, was to go with the more traditional way of 
    doing things until someone passed the appropriate legislation.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00281 for ietf-pkix-bks; Wed, 9 Jun 1999 11:49:10 -0700 (PDT)
Received: from magenta.omnisig.com (magenta.omnisig.com [207.107.11.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00277 for <[e-mail]>; Wed, 9 Jun 1999 11:49:09 -0700 (PDT)
Received: from omnisig.com ([172.16.7.66]) by magenta.omnisig.com (8.8.7/8.8.5) with ESMTP id PAA20026; Wed, 9 Jun 1999 15:50:48 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 09 Jun 1999 14:52:26 -0400
From: Al Arsenault <[e-mail]>
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Certificate requests for encryption keys
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It's actually very straightforward.  In fact, we implemented it several years
ago.  You just do the following:

(1) start with an X.509 profile, such as RFC 2459;

(2) change the rules so that a certificate containing a key-management key only
(i.e., a key with the digitalsignature, non-repudiation, keyCertSign, and
CRLSign bits all OFF) is valid if:
    - the issuer is a CA (basicConstraints = TRUE and keyUsage = at least
keyCertSign);
or
    - the issuer is an end-entity (basicConstraints = FALSE) and the issuer's
name and subject's name are identical.  This case holds regardless of the fact
that the issuer's key has keyCertSign OFF.  (There may be some other conditions
here; I'm doing this off the top of my head.)

(3) then, you do a lot of software modifications. You provide the users the
software to generate and sign their own certificates.  You change the
application software so that it accepts these self-signed key management certs
under the rules given in (2).  You also change the application software to
handle revocation in one of three ways:

    (a) you don't revoke these certs, you just wait until they expire;
    (b) you revoke the key-management cert indirectly, by revoking the signature
cert containing the key used to sign it;
    (c) you deal with lots of very small CRLs or widely-scattered OCSP
responders

None of these is very pleasing to application developers, except maybe (a), but
that's not really pleasing to system designers who want a "secure" system.
Sure, you could have the certificates expire every hour, but now you've
introduced a load on your system with all of the certificate generation.

All of this assumes that the new self-generated key management certificate is
signed using a key from a certificate that is itself traceable back to a CA you
trust.  Otherwise, you're completely out of the PKIX realm.  (If I don't have to
provide a cert path back to a CA you trust, then if you don't know either of us
personally,  I suspect I wouldn't have much difficulty convincing you that I'm
Russ Housley and this is my key management certificate.)

But, after doing all of this, the question that arises is the one already posed
by Dave Kemp:  why do you want to do this?  Certainly, I can understand
financially-based desires - for security reasons, you want a new key management
certificate every month, or every day, and you don't want to pay $24.95 or
$159.95 everytime you get one. But that doesn't strike me as being a good reason
to change a technical system so dramatically.  (And, no, I have no personal
financial interest in selling certificates.  I'm not even allowed to own stock
in most of those companies. :-)

I guess my bottom line is this:  PKIX was designed for a specific set of
purposes.  It fulfills most of those purposes pretty well (IMNSHO).  However,
PKIX was never designed AND CAN NEVER BE a be-all and end-all of public-key
based security in the Internet.  Things like IKE without certificates, and
SSL/TLS without certificates will always have a place in Internet security.

                Al Arsenault

-- As usual, speaking for myself.  My opinions do not necessarily reflect those
of my employer or of any other organization with which I have a relationship.




Peter Gutmann wrote:

> Bill Burr <[e-mail]> writes:
>
> >Your line of reasoning has always made sense to me.  If you can validate my
> >signature, why wouldn't you trust me to sign my own encryption key?
> >
> >Nevertheless, when I have mentioned the idea that end entities could
> >self-sign encryption certificates, I don't think I've ever received a
> >sympathetic response.
>
> Given that there seem to be several people in this situation out there, is
> there any interest in doing a profile for these certs?  It's pretty trivial
> to implement given any existing toolkit, all we'd need is to achieve
> consensus on how the certs should be denoted.  Since there's no backwards-
> compatibility issue, all you really need to do is convince enough people to
> adopt the scheme.
>
> Peter.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00129 for ietf-pkix-bks; Wed, 9 Jun 1999 11:28:27 -0700 (PDT)
Received: from magenta.omnisig.com (magenta.omnisig.com [207.107.11.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00125 for <[e-mail]>; Wed, 9 Jun 1999 11:28:26 -0700 (PDT)
Received: from omnisig.com ([172.16.7.66]) by magenta.omnisig.com (8.8.7/8.8.5) with ESMTP id PAA19817; Wed, 9 Jun 1999 15:28:53 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 09 Jun 1999 14:30:30 -0400
From: Al Arsenault <[e-mail]>
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: Terry Hayes <[e-mail]>
CC: Bob Jueneman <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Certificate requests for encryption keys
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here we go 'round the mulberry bush, the mulberry bush, the mulberry bush;
here we go 'round the mulberry bush, so early in the morning....

Since this discussion has taken place at least 5 times now on this mailing list, I
will once again suggest that all parties interested in Proof of Possession theology
review Section 5.2 of the PKIX Roadmap I-D.  Comments are appreciated.

You might also want to take a look at the PKIX Archive (found at www.imc.org) for the
last discussion of this, which occurred in January and February of this year.

                Al Arsenault

-- Speaking only for myself.  My opinions do not necessarily reflect those 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 LAA29896 for ietf-pkix-bks; Wed, 9 Jun 1999 11:14:07 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA29892 for <[e-mail]>; Wed, 9 Jun 1999 11:14:06 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 09 Jun 1999 12:15:28 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 09 Jun 1999 12:15:25 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Certificate requests for encryption keys
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 LAA29893
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Fallacy, perhaps, but not intentional.  :-)

I was neither agreeing nor disagreeing with what Anne said, 
merely urging caution, having been around this particular maypole 
a number of times over the last N years.

But Steve said it better. Security is hard -- be very careful.

Or as Einstein said "For every problem there is a simple solution.
Unfortunately, most of the time the simple solution is wrong."

Bob

>>> Michael Sierchio <[e-mail]> 06/09/99 10:37AM >>>
Bob Jueneman wrote:

> In the case of a digital signature, not requiring proof of possession would
> allow me to get of copy of Thomas Edison's public key (small time wrap
> problem omitted for brevity) and claim all of his digitally signed patents
> as my own.  (Assuming he didn't actually include his name
> in the patent itself, of course.)
> 
> What kind of mischief could someone carry out with an encryption key
> without POP?

I think you're engaging in intentional fallacy --

Anne's scenario includes:

	1)	an EE signing cert,  with identity attested to by appropriate
		RA, CA and the Pope, perhaps restricted in use to signing 
		encyption-only certs with half-life in seconds;

	2)	a signature over a (possibly ephemeral EE encryption cert),
		attesting to its validity, by the EE;

	3)	ability to perform encryption after (2) is proof of possession of the
		private key;

	4)	ability to sign this cert with (1) is proof of identity.

If I were to sign a message stating "for the next two hours,  I will use
the following DH parameters for communication with Anne..." it would be
equivalent.  The difference is the ability to cook an X.509 cert which
would permit key discovery through "normal" means,  quite convenient.

A self-signed cert contained in a message signed by my signing key is also
somewhat equivalent.  I like Anne's approach better.


Cheers,

Michael Sierchio



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29852 for ietf-pkix-bks; Wed, 9 Jun 1999 11:09:38 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29848 for <[e-mail]>; Wed, 9 Jun 1999 11:09:36 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id NAA13647; Wed, 9 Jun 1999 13:09:18 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id NAA16922; Wed, 9 Jun 1999 13:09:18 -0500 (CDT)
Message-ID: <003201beb2a3$9768e540$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: <[e-mail]>, "Stephen Kent" <[e-mail]>
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
Date: Wed, 9 Jun 1999 13:12:09 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_002E_01BEB279.AE620940"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_002E_01BEB279.AE620940
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_002F_01BEB279.AE620940"


------=_NextPart_001_002F_01BEB279.AE620940
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All,

>This really has gotten out of hand. I admire the dedication of folks =
who have been applying serious intellectual effort to creating a general =
>formula for cert lifetime as a function of the number of attributes, =
but ...=20
>
>As the creator of "Steve's Rule of Revocation" I have to admit that I =
generated the simple inverse square formula just to make a point, i.e., =
that, >in general, adding attributes to a cert will shorten it's =
effective lifetime and thus is generally a bad idea.


I agree with Steve here.  I think this horse is dead now, and I resolve =
to stop arguing these points.

>As some have pointed out, a general formula is hard, since one can cite =
examples whwre added attributes are so closely linked to existing =
>attributes that the addition has no real effect on expected lifetime. =
Also, contributors to this thread pointed out early on that it is the =
attribute >with the shortest expected lifetime that governs the lifetime =
of the cert. So, trying to express the lifetime in terms of a pure =
attribute count >seems futile.
>
>Now, if I had to justify my original formula, I might try the following =
analogy:
>
>1. Adding attributes to a cert is a generally bad idea. In vernacular =
terms, it "sucks."
>
>2. Looking to physics for an analogy, we note that, in the vernacular, =
gravity "sucks."
>
>3. The inverse square law applies to gravitational attraction between =
bodies.
>
>4. Therefore, the effective lifetime of a certificate is inversely =
propotional to the inverse square of the number of attributes :-)

She's a witch!  She turned me into a newt!  (I got better)

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom

------=_NextPart_001_002F_01BEB279.AE620940
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 face=3D"Goudy Old Style"=20
size=3D2></FONT>All,<BR><BR>&gt;This really has gotten out of hand. I =
admire the=20
dedication of folks who have been applying serious intellectual effort =
to=20
creating a general &gt;formula for cert lifetime as a function of the =
number of=20
attributes, but ... <BR>&gt;<BR>&gt;As the creator of &quot;Steve's Rule =
of=20
Revocation&quot; I have to admit that I generated the simple inverse =
square=20
formula just to make a point, i.e., that, &gt;in <B>general</B>, adding=20
attributes to a cert will shorten it's effective lifetime and thus is=20
<B>generally</B> a bad idea.<BR></DIV>
<DIV><FONT color=3D#000000 face=3D"Goudy Old Style" =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D""><FONT face=3DArial><FONT size=3D3>I =
agree with=20
Steve here.&nbsp; I think this horse is dead now, and I resolve to stop =
arguing=20
these points.</FONT></FONT></FONT><FONT size=3D3><FONT=20
face=3DArial></FONT></FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Goudy Old Style" =
size=3D2></FONT>&nbsp;</DIV>
<DIV>&gt;As some have pointed out, a general formula is hard, since one =
can cite=20
examples whwre added attributes are so closely linked to existing =
&gt;attributes=20
that the addition has no real effect on expected lifetime. Also, =
contributors to=20
this thread pointed out early on that it is the attribute &gt;with the =
shortest=20
expected lifetime that governs the lifetime of the cert. So, trying to =
express=20
the lifetime in terms of a pure attribute count &gt;seems=20
futile.<BR>&gt;<BR>&gt;Now, if I had to justify my original formula, I =
might try=20
the following analogy:<BR>&gt;<BR>&gt;1. Adding attributes to a cert is =
a=20
generally bad idea. In vernacular terms, it =
&quot;sucks.&quot;<BR>&gt;<BR>&gt;2.=20
Looking to physics for an analogy, we note that, in the vernacular, =
gravity=20
&quot;sucks.&quot;<BR>&gt;<BR>&gt;3. The inverse square law applies to=20
gravitational attraction between bodies.<BR>&gt;<BR>&gt;4. Therefore, =
the=20
effective lifetime of a certificate is inversely propotional to the =
inverse=20
square of the number of attributes :-)</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D3>She's a witch!&nbsp; She turned =
me into a=20
newt!&nbsp; (I got better)</FONT></FONT><FONT size=3D3><FONT=20
face=3DArial></FONT></FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Goudy Old Style" size=3D2><BR><FONT=20
size=3D3>--bob</FONT></FONT><FONT size=3D3></FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Goudy Old Style"><FONT =
size=3D3></FONT></FONT><FONT=20
size=3D3></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Goudy Old Style" size=3D3>Bob Blakley =
(<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>)<BR>Chief =
Scientist,=20
Dascom</FONT></DIV></BODY></HTML>

------=_NextPart_001_002F_01BEB279.AE620940--

------=_NextPart_000_002E_01BEB279.AE620940
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990609T181209Z
END:VCARD

------=_NextPart_000_002E_01BEB279.AE620940--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29837 for ietf-pkix-bks; Wed, 9 Jun 1999 11:09:16 -0700 (PDT)
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 LAA29833 for <[e-mail]>; Wed, 9 Jun 1999 11:09:15 -0700 (PDT)
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 OAA18253; Wed, 9 Jun 1999 14:11:11 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 09 Jun 1999 14:12:55 -0400
To: [e-mail], [e-mail], [e-mail]
From: Bill Burr <[e-mail]>
Subject: Re: Certificate requests for encryption keys
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 03:02 AM 6/10/99, Peter Gutmann wrote:
>Bill Burr <[e-mail]> writes:
>
>>Your line of reasoning has always made sense to me.  If you can validate my
>>signature, why wouldn't you trust me to sign my own encryption key?
>>
>>Nevertheless, when I have mentioned the idea that end entities could
>>self-sign encryption certificates, I don't think I've ever received a
>>sympathetic response.
>
>Given that there seem to be several people in this situation out there, is
>there any interest in doing a profile for these certs?  It's pretty trivial
>to implement given any existing toolkit, all we'd need is to achieve 
>consensus on how the certs should be denoted.  Since there's no backwards-
>compatibility issue, all you really need to do is convince enough people to
>adopt the scheme.
>
>Peter.
>
>

Peter,

As attractive as I find the idea of issuing my own encryption certificates,
I'm not sure that there is really a demand for self-issued encryption
certificates.  CA issued encryption certificates work well enough, and
folks are already set up to do that.  If I were able to start over and
build a PKI "right" I think I'd do a lot of things differently, but a lot
of water has passed under the dam already, and there probably is not much
desire for structural changes at this point.

I originally thought about self-signed encryption certificates in the
context of thinking about the old UK White paper that proposed to make CAs
that didn't escrow encryption or key management keys, more or less illegal.
 I decided that, if that were done, it would be, as you point out, pretty
easy to write some code that worked from self-signed encryption
certificates.  Once I had a signature certificate from an official licensed
CA, I could use that to prove my identity and sign my own encryption
certificate, getting the benefit of the licensed CA, but easily avoiding
any kind of key escrow. It would require a profoundly heavy handed and
oppressive police state to suppress such an approach.

But such mandatory schemes have largely disappeared.  Even the French seem
to have given up on them.    
Regards,

Bill Burr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29704 for ietf-pkix-bks; Wed, 9 Jun 1999 10:58:00 -0700 (PDT)
Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29700 for <[e-mail]>; Wed, 9 Jun 1999 10:57:57 -0700 (PDT)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id RAA27592; Wed, 9 Jun 1999 17:59:17 GMT
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id SAA05475; Wed, 9 Jun 1999 18:59:38 +0100
Message-ID: <[e-mail]>
Date: Wed, 09 Jun 1999 18:59:17 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Delegation of rights -- end-entity issued certs.
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob Jueneman wrote:
> (I'm primarily thinking about authentication, not encryption at this time,
> although I suppose this might be applicable to an encrypted file system
> somehow.)
> 
> At least in concept, I am willing to entertain the notion of a delegation
> certificate, perhaps in the form of an attribute cert, which says that
> "I, RRJ, hereby delegate to XYZ the ability to access so and so files
> to which I have discretionary rights."
> 
> I'm NOT acting as a CA in that case -- I'm not certifying that individual's identity
> at all.  I'm merely granting that person, presumably identified by someone
> else, whatever rights I choose to delegate to that person.

Isn't this exactly what KeyNote (which I recently extended to cover X509
certs as entities) is for?

Cheers,

Ben.

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

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28930 for ietf-pkix-bks; Wed, 9 Jun 1999 09:37:22 -0700 (PDT)
Received: from lux.tenebras.com (dnai-207-181-255-85.dialup.dnai.com [207.181.255.85]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28926 for <[e-mail]>; Wed, 9 Jun 1999 09:37:21 -0700 (PDT)
Received: from dnai.com (windoze [192.168.100.122]) by lux.tenebras.com (8.8.8/8.8.8) with ESMTP id JAA11256; Wed, 9 Jun 1999 09:37:54 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 09 Jun 1999 09:37:44 -0700
From: Michael Sierchio <[e-mail]>
Reply-To: [e-mail]
Organization: Oversized Metaphysics
X-Mailer: Mozilla 4.51 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Certificate requests for encryption keys
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob Jueneman wrote:

> In the case of a digital signature, not requiring proof of possession would
> allow me to get of copy of Thomas Edison's public key (small time wrap
> problem omitted for brevity) and claim all of his digitally signed patents
> as my own.  (Assuming he didn't actually include his name
> in the patent itself, of course.)
> 
> What kind of mischief could someone carry out with an encryption key
> without POP?

I think you're engaging in intentional fallacy --

Anne's scenario includes:

	1)	an EE signing cert,  with identity attested to by appropriate
		RA, CA and the Pope, perhaps restricted in use to signing 
		encyption-only certs with half-life in seconds;

	2)	a signature over a (possibly ephemeral EE encryption cert),
		attesting to its validity, by the EE;

	3)	ability to perform encryption after (2) is proof of possession of the
		private key;

	4)	ability to sign this cert with (1) is proof of identity.

If I were to sign a message stating "for the next two hours,  I will use
the following DH parameters for communication with Anne..." it would be
equivalent.  The difference is the ability to cook an X.509 cert which
would permit key discovery through "normal" means,  quite convenient.

A self-signed cert contained in a message signed by my signing key is also
somewhat equivalent.  I like Anne's approach better.


Cheers,

Michael Sierchio


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28915 for ietf-pkix-bks; Wed, 9 Jun 1999 09:36:31 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28911 for <[e-mail]>; Wed, 9 Jun 1999 09:36:28 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA27428 for <[e-mail]>; Wed, 9 Jun 1999 12:38:20 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA27422 for <[e-mail]>; Wed, 9 Jun 1999 12:38:20 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id MAA11068 for <[e-mail]>; Wed, 9 Jun 1999 12:38:24 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id MAA14949 for <[e-mail]>; Wed, 9 Jun 1999 12:35:46 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 9 Jun 1999 12:35:46 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Certificate requests for encryption keys
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 6O5C0HeNpl5vqhxT5TnW8g==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: [e-mail] (Peter Gutmann)
> 
> This is a general response to several messages which have pointed out that
> self-signed EE certs don't fit into the X.509 theology[0]... this is a valid
> point, however what people are trying to achieve with these certs is a means
> of sharing keys without external certification and authentication and fuzzy
> dice and chrome tailfins.  The X.509 format makes it impossible to just store
> or communicate a key without carrying a vast mountain of other (often
> unnecessary) baggage around with you.

Of course it does, and that's precisely the point of the messages you
refer to.  The difference between a car and a ship is not a theological
distinction, nor is the difference between an X.509 certificate (as
used in a PKI with external authorities) and a bare key (authenticated
by its owner).

If you want to send a key from A to B, why would you even consider packing
it up with X.509 baggage (DN, validity, serial#, issuer, blah blah blah)?
You might store the key and its parameters using a structure borrowed
from X.509 (call it PublicKeyInfo instead of SubjectPublicKeyInfo), but
don't try to use the cruise ship to travel to the local grocery store.

If the goal is to send a signed key without using the IETF standard for
signed objects (CMS), then here's a free piece of ASN.1 that might
do the trick:

  signedKey ::= SEQUENCE {
     tbsKey              PublicKeyInfo,
     signatureAlgorithm  AlgorithmIdentifier,
     signatureValue      BIT STRING }
     
  PublicKeyInfo ::= SEQUENCE {
     algorithm           AlgorithmIdentifier,
     publicKey           BIT STRING }

Please use CMS, or IKE, or TLS, or whack on this structure until it does
what you want.  But DON'T try to use X.509 and then complain that
it wasn't designed for the purpose.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28744 for ietf-pkix-bks; Wed, 9 Jun 1999 09:21:15 -0700 (PDT)
Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28740 for <[e-mail]>; Wed, 9 Jun 1999 09:21:14 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id MAA25319 for <[e-mail]>; Wed, 9 Jun 1999 12:23:07 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id MAA06691 for <[e-mail]>; Wed, 9 Jun 1999 12:23:06 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525678B.00593A76 ; Wed, 9 Jun 1999 12:14:36 -0400
X-Lotus-FromDomain: FDC
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 9 Jun 1999 09:07:48 -0700
Subject: Re: Re[2]: Summary, was Re: Every time ..., was Re: General form
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

oops ... sorry ... as pointed out .... the words around the forumla

0.5+.2+.1 = .8

should say the avg. number of independent events in a year that changes at least
one
certificate attribute value

while the

1/.8 = 1.25

avg lifetime of certificate stays the same.

the calculation is still that the lifetime is a derived value ... from the
independent events that might change one or more attribute values




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28689 for ietf-pkix-bks; Wed, 9 Jun 1999 09:17:06 -0700 (PDT)
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 JAA28684; Wed, 9 Jun 1999 09:17:05 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA02511; Wed, 9 Jun 1999 12:18:55 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a04b38442c1cad4@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a01b38437f941e6@[128.89.0.110]> <[e-mail]>
Date: Wed, 9 Jun 1999 12:19:46 -0400
To: Paul Hoffman / IMC <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

I disagree strongly with almosty everything you said, even though you're a
nice guy :-).

We're not in the synatx-only business here.  Certificates are a powerful
tool for enabling secure applications.  However, security is a VERY HARD
problem and part of our task in this WG is to provide a context for
certificate use to minimize the risks attendant with the technology. There
are limits on how much of this we can do, since differentr contexts have
different security requirements.  However, in the same sense that the IESG
and the IAB have adopted a position that mandate strong encryption
algorithms as defaults for crypto protocols, I think it consistent to adopt
a posture that tries to establish secure management frameworks for use of
X.509 certificates. If one elects to employ some unspecified, out-of-band
management to validate certs, to revoke them, etc. then we have no idea
what security is provided by the resulting system, and that is not
consistent with the higher level goals cited above.

I certainly can't prevent anyone from using the X.509 format for any
purpose they wish, but I will resist the notion that this WG add work items
that facilitate such activities.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28481 for ietf-pkix-bks; Wed, 9 Jun 1999 08:59:21 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28471; Wed, 9 Jun 1999 08:59:14 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta)
Date: Wed, 09 Jun 1999 08:59:02 -0700
To: Stephen Kent <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail]
In-Reply-To: <v04020a01b38437f941e6@[128.89.0.110]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:32 AM 6/9/1999 -0400, Stephen Kent wrote:
>Your characterization of what you are trying to do is somewhat ncomplete, I
>suspect.  You don't want to just transfer a public key; you want to
>transfer it with some set of assurances, e.g., so that the recipient knows
>whose public key it is.

I'll disagree with your characterization of what Peter has asked for. There 
are many good reasons to want to use the *format* described in PKIX for 
transporting public keys without being forced to use the systems associated 
with PKIX to process the certificates. Peter is (I believe) saying "I'll do 
the assurances out of band, just let me use your format".

>X.509 defines a format and processing for representing a key within a
>management infrastructure.

The format can be used outside of the management infrastructure.

>   That infrastructure does not have to be global,
>using formally approved CAs, etc.  It can be a closed PKI with small
>extent. However, the goal of this WG is to facilitate Internet use of X.509
>and that does argue for syntax and processing that does scale to large
>groups, representative of the growth of the Internet.

I believe that it also argues for other Internet-related uses of X.509 
certs that may not have been envisioned by the directory-centric views of 
the X.509 folks.

>Along those lines, maybe you should make use of some other syntax if your
>goals for public key representation for transfer are not congurent with
>those stated here.  We can't be everything to everyone.  One size rarely
>fits all.

I don't think this WG should be that dismissive of a significant 
constituency. The fact that one gets X.509 self-signed root certs from a 
directory and then does out-of-band verification says to me that there is 
no good reason not to get self-signed EE certs from a directory if they are 
then followed by out-of-band verification. If we can set up a different 
profile of X.509 to allow the latter case, we should do so, given the 
obvious business desire for such a system.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28455 for ietf-pkix-bks; Wed, 9 Jun 1999 08:58:02 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA28451 for <[e-mail]>; Wed, 9 Jun 1999 08:58:01 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 09 Jun 1999 09:59:23 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 09 Jun 1999 09:59:15 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Certificate requests for encryption keys
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 IAA28452
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think the subject is well worth exploring, but I am uneasy with relying 
on someone signing an unrelated encryption key without Proof of 
Possession.

I can't find a smoking gun, but that doesn't mean there isn't one--it may 
mean that I haven't thought about it hard enough.  Unless someone 
can somehow prove the negative (admittedly very difficult), I would
proceed very cautiously.

But proceed, nonetheless!

Bob

>>> Peter Gutmann <[e-mail]> 06/10/99 03:02AM >>>
Bill Burr <[e-mail]> writes:

>Your line of reasoning has always made sense to me.  If you can validate my
>signature, why wouldn't you trust me to sign my own encryption key?
>
>Nevertheless, when I have mentioned the idea that end entities could
>self-sign encryption certificates, I don't think I've ever received a
>sympathetic response.

Given that there seem to be several people in this situation out there, is
there any interest in doing a profile for these certs?  It's pretty trivial
to implement given any existing toolkit, all we'd need is to achieve 
consensus on how the certs should be denoted.  Since there's no backwards-
compatibility issue, all you really need to do is convince enough people to
adopt the scheme.

Peter.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28428 for ietf-pkix-bks; Wed, 9 Jun 1999 08:57:17 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28424 for <[e-mail]>; Wed, 9 Jun 1999 08:57:17 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA28717 for <[e-mail]>; Wed, 9 Jun 1999 08:58:38 -0700 (PDT)
Received: from netscape.com ([205.217.229.52]) by dredd.mcom.com (Netscape Messaging Server 4.01) with ESMTP id FD2HPQ01.FPR; Wed, 9 Jun 1999 08:58:38 -0700 
Message-ID: <[e-mail]>
Date: Wed, 09 Jun 1999 08:58:12 -0700
From: Terry Hayes <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Certificate requests for encryption keys
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'll have to disagree with most of this - I haven't seen a compelling argument
for Proof of Possession yet.  To my mind it is a large amount of added complexity
(for PKI protocols) without any real benefit.  I've responded to Bob's examples
below (I thank him for the examples, if anyone has better ones I'd like to see
them)

Bob Jueneman wrote:

> This thread has engendered several interesting subthreads, but let's dispatch
> the first one, first.
>
> As Steve says, the fundamental principle behind requiring Proof of Possession
> with respect to the private key of a key pair is to assure that the user
> who is identified in the certificate containing that the public key does
> in fact possess the private key, and isn't trying to spoof someone somehow.

And how does the user "spoof" someone when they don't have the private key that
corresponds to the public key in the certificate?  To my way of thinking this
certificate is worthless, since the user can't exercise any of the privileges (if
any) that it would allow the key holder.

>
> In the case of a digital signature, not requiring proof of possession would
> allow me to get of copy of Thomas Edison's public key (small time wrap
> problem omitted for brevity) and claim all of his digitally signed patents
> as my own.  (Assuming he didn't actually include his name
> in the patent itself, of course.)

This example relies on the assumption that simply signing a piece of data somehow
transfers ownership of it to the signer.  It's my understanding that signing
simply indicates that the signer saw the data, and sometimes has agreed to the
meaning of its contents.  It is also important to get some kind of time stamp on
data (such as a patent submission) to prove its existence prior to a certain
time.  In other words, simply signing is not very interesting in this case.

Even if the CA is doing POP, I can simply request my own certificate from the CA
and sign the same message as Thomas did with my own key.  Now it belongs to me,
right?  Of course not.  There are two ways to prevent this: 1) time stamp the
resulting signature and 2) put your name in the document.

In general, I think most requests for POP are the result of protocols that aren't
designed properly.  If you leave your name out of the patent document, then some
user could attempt to steal it.  I'm in favor of fixing the protocol, not adding
a POP mechanism to the PKI structure.

Protocols that use signatures should "sign what they mean" - in this example the
name of the inventor of the new technology is an very important part of the
document.  It should not be inferred simply from the signature on the document.


>
> What kind of mischief could someone carry out with an encryption key
> without POP?
>
> Well, maybe I somehow intercept Steve's encryption certificate request
> and substitute my own public key in it.  Steve's identity is valid --- he's
> a good guy -- so the certificate would be issued.  Now people
> blurt out their innermost secrets to him, and he can't read them but I
> can.

This is a failing in the certificate request protocol, not an argument for POP.
If the CA that you deal with issues certificates with public keys that are not
properly authenticated, then either the certificate request protocol is broken or
the CA isn't doing its job and shouldn't be trusted.

> Not very convincing, as I suspect was Brian's point, but my inability
> to find a rally zinger of a threat probably means that I'm not thinking hard
> enough, rather than indicating there is no threat.

I don't agree.  I think this is a technology looking for a threat - and having a
hard time finding it.

> The obvious was to do POP for encryption keys is for the CA to encrypt a
> challenge, send it to the Subscriber, and have him send back the decrypted
> result.  The problem is that is rather awkward from the standpoint of most
> certificate request protocols.
>

Yes, this is the most straight-forward way, and is awkward.  The currently
proposed POP protocols (that tie in to requested identity) are fine, but I still
argue that they are not needed.  Fix the operational level protocols instead.

Terry



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28248 for ietf-pkix-bks; Wed, 9 Jun 1999 08:42:23 -0700 (PDT)
Received: from ny.us.ibm.com. (e4.ny.us.ibm.com [32.97.182.104]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28244 for <[e-mail]>; Wed, 9 Jun 1999 08:42:19 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id LAA232616; Wed, 9 Jun 1999 11:44:07 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.0) with SMTP id LAA23510; Wed, 9 Jun 1999 11:44:09 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525678B.00566959 ; Wed, 9 Jun 1999 11:43:50 -0400
X-Lotus-FromDomain: IBMUS
To: "David P. Kemp" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 9 Jun 1999 11:43:20 -0400
Subject: RE: Possible clarification to RFC 2459
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"David P. Kemp" <[e-mail]> on 06/09/99 10:31:27 AM

Please respond to "David P. Kemp" <[e-mail]>

To:   [e-mail]
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Possible clarification to RFC 2459






> From: Tom Biskupic <[e-mail]>
>
> Dave,
>
> I was thinking of the case where you have a certificate without a CDP
> extension and you have a cached CRL containing an IDP. Do I need to get
> another CRL or should this certificate be contained in the one I have?

I believe Russ' analysis answered the question.  If the cached CRL is not
an ICRL, and it is not partitioned by user/CA/reasons, then the cert without
a CRLdp MUST be contained in the cached CRL.

In other words, the *only* way to do partitioning other than by
user/CA/reasons is by using CRLdp extensions in certificates.

I think it is already obvious, but would not disagree with the following
clarification:

  "A CRL containing an issuingDistributionPoint extension with the
  distributionPoint field present MUST be authoritative for all
  certificates* that do not contain a CRLDistributionPoints extension."

  *user certs, CA certs, or both, as specified in the IDP.

[Tom Gindin]   Should that really be "with the distributionPoint field present"
or "without the distributionPoint field present"?  It would seem to be true when
the distributionPoint field is absent.  I would say that "A CRL containing an
issuingDistributionPoint extension with the   distributionPoint field containing
a DN MUST be authoritative for all   certificates that contain that value of the
field in their  CRLDistributionPoints extension", and also that "A CRL
containing an issuingDistributionPoint extension without the distributionPoint
field present MUST be authoritative for all certificates* that do not contain a
CRLDistributionPoints extension."  What isn't obvious, I suppose, is whether
CRL's at named distribution points (with a DN name, as there are specifics about
DP's with URI names) cover certificates without distribution points.



> I think the bottom line is you can only use the CRL if its DP matches your
> certificate's (either explicitly through a CDP extension or implicitly).
> Presence/absence of an IDP is not enough to determine this.
>
> I'm really arguing against Ambarish's statement (and not som much the other
> Tom's [TomG's] original comments) so I guess we are off-topic a bit:-
>
> "A full CRL from/for a CA MUST NOT contain the
> issuingDistributionPoint extension, unless it is an indirect CRL,
> in which case, it MAY contain the issuingDistributionPoint
> extension with only the indirectCRL field set to true."


I disagree with this restriction, because it prevents the cached CRL
(which may have been pushed or manually configured) from containing
a pointer enabling its successor to be pulled.






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28208 for ietf-pkix-bks; Wed, 9 Jun 1999 08:37:20 -0700 (PDT)
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 IAA28203 for <[e-mail]>; Wed, 9 Jun 1999 08:37:19 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA23631; Wed, 9 Jun 1999 11:39:03 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a01b38437f941e6@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Wed, 9 Jun 1999 11:32:06 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Your characterization of what you are trying to do is somewhat ncomplete, I
suspect.  You don't want to just transfer a public key; you want to
transfer it with some set of assurances, e.g., so that the recipient knows
whose public key it is.

X.509 defines a format and processing for representing a key within a
management infrastructure.  That infrastructure does not have to be global,
using formally approved CAs, etc.  It can be a closed PKI with small
extent. However, the goal of this WG is to facilitate Internet use of X.509
and that does argue for syntax and processing that does scale to large
groups, representative of the growth of the Internet.

Along those lines, maybe you should make use of some other syntax if your
goals for public key representation for transfer are not congurent with
those stated here.  We can't be everything to everyone.  One size rarely
fits all.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA27844 for ietf-pkix-bks; Wed, 9 Jun 1999 08:02:11 -0700 (PDT)
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 IAA27840 for <[e-mail]>; Wed, 9 Jun 1999 08:02:09 -0700 (PDT)
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 DAA13786 for <[e-mail]>; Thu, 10 Jun 1999 03:03:57 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92894063708066>; Thu, 10 Jun 1999 03:03:57 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Certificate requests for encryption keys
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 10 Jun 1999 03:03:57 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a general response to several messages which have pointed out that
self-signed EE certs don't fit into the X.509 theology[0]... this is a valid
point, however what people are trying to achieve with these certs is a means
of sharing keys without external certification and authentication and fuzzy
dice and chrome tailfins.  The X.509 format makes it impossible to just store
or communicate a key without carrying a vast mountain of other (often
unnecessary) baggage around with you.  I can't speak for others who have 
posted an opinion on this, but all I'm trying to do is get a key from A to B
without requiring a huge (and currently mostly nonexistant) infrastructure to
do it, the same thing which PGP has been doing very successfully for nearly a
decade.  All I want to do is store a key in a non-proprietary format, but 
X.509 (currently) doesn't let me do that unless I get a CA to sign it first.
What I'm proposing is a key bit-bagging scheme which isn't entirely dependent 
on the presence of a CA in order to function.

Peter.

[0] Whether X.509 is systematic or speculative theology is left for the reader
    to decide :-).



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA27811 for ietf-pkix-bks; Wed, 9 Jun 1999 08:00:41 -0700 (PDT)
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 IAA27807 for <[e-mail]>; Wed, 9 Jun 1999 08:00:38 -0700 (PDT)
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 DAA13965; Thu, 10 Jun 1999 03:02:13 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92894053308126>; Thu, 10 Jun 1999 03:02:13 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Certificate requests for encryption keys
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 10 Jun 1999 03:02:13 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bill Burr <[e-mail]> writes:

>Your line of reasoning has always made sense to me.  If you can validate my
>signature, why wouldn't you trust me to sign my own encryption key?
>
>Nevertheless, when I have mentioned the idea that end entities could
>self-sign encryption certificates, I don't think I've ever received a
>sympathetic response.

Given that there seem to be several people in this situation out there, is
there any interest in doing a profile for these certs?  It's pretty trivial
to implement given any existing toolkit, all we'd need is to achieve 
consensus on how the certs should be denoted.  Since there's no backwards-
compatibility issue, all you really need to do is convince enough people to
adopt the scheme.

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27634 for ietf-pkix-bks; Wed, 9 Jun 1999 07:35:33 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA27630 for <[e-mail]>; Wed, 9 Jun 1999 07:35:32 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 09 Jun 1999 08:36:54 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 09 Jun 1999 08:36:45 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Delegation of rights -- end-entity issued certs.
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 HAA27631
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I wouldn't be so hasty to reject some of Anne's and Peter's ideas 
out of hand -- they may have merit, and are at least worth some
discussion.

Internally, we've gotten some requests to use end-entity certificates 
to enable delegation of access rights to NDS, and to 
NDS access-controlled objects (partitions, attributes, and 
NetWare file system volumes), for example.

Obviously (I assume) this user-controlled delegation can't be used to
delegate Mandatory Access Control rights -- that would be a contradiction 
in terms.

But if a user has the right to delegate some or all of his Discretionary 
Access Control rights, then a certificate based system could certainly 
be used for such a purpose, and would presumably be stronger than 
yet another ID and password system, much less the more common 
approach to such problems of simply sharing passwords.

(I'm primarily thinking about authentication, not encryption at this time, 
although I suppose this might be applicable to an encrypted file system
somehow.)

At least in concept, I am willing to entertain the notion of a delegation 
certificate, perhaps in the form of an attribute cert, which says that 
"I, RRJ, hereby delegate to XYZ the ability to access so and so files
to which I have discretionary rights."

I'm NOT acting as a CA in that case -- I'm not certifying that individual's identity
at all.  I'm merely granting that person, presumably identified by someone 
else, whatever rights I choose to delegate to that person.

Bob



Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27607 for ietf-pkix-bks; Wed, 9 Jun 1999 07:32:11 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA27603 for <[e-mail]>; Wed, 9 Jun 1999 07:32:10 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA10524 for <[e-mail]>; Wed, 9 Jun 1999 10:34:01 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA10516 for <[e-mail]>; Wed, 9 Jun 1999 10:34:01 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA09462 for <[e-mail]>; Wed, 9 Jun 1999 10:34:04 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA14915 for <[e-mail]>; Wed, 9 Jun 1999 10:31:27 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 9 Jun 1999 10:31:27 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Possible clarification to RFC 2459
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: JIXL9JiKKt5qbYQRHroAww==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: Tom Biskupic <[e-mail]>
> 
> Dave,
> 
> I was thinking of the case where you have a certificate without a CDP 
> extension and you have a cached CRL containing an IDP. Do I need to get 
> another CRL or should this certificate be contained in the one I have?

I believe Russ' analysis answered the question.  If the cached CRL is not
an ICRL, and it is not partitioned by user/CA/reasons, then the cert without
a CRLdp MUST be contained in the cached CRL.

In other words, the *only* way to do partitioning other than by
user/CA/reasons is by using CRLdp extensions in certificates.

I think it is already obvious, but would not disagree with the following
clarification:

  "A CRL containing an issuingDistributionPoint extension with the
  distributionPoint field present MUST be authoritative for all
  certificates* that do not contain a CRLDistributionPoints extension."
  
  *user certs, CA certs, or both, as specified in the IDP.



> I think the bottom line is you can only use the CRL if its DP matches your 
> certificate's (either explicitly through a CDP extension or implicitly). 
> Presence/absence of an IDP is not enough to determine this.
> 
> I'm really arguing against Ambarish's statement (and not som much the other 
> Tom's [TomG's] original comments) so I guess we are off-topic a bit:-
> 
> "A full CRL from/for a CA MUST NOT contain the
> issuingDistributionPoint extension, unless it is an indirect CRL,
> in which case, it MAY contain the issuingDistributionPoint
> extension with only the indirectCRL field set to true."


I disagree with this restriction, because it prevents the cached CRL
(which may have been pushed or manually configured) from containing
a pointer enabling its successor to be pulled.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27366 for ietf-pkix-bks; Wed, 9 Jun 1999 07:08:57 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA27360 for <[e-mail]>; Wed, 9 Jun 1999 07:08:56 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 09 Jun 1999 08:10:26 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 09 Jun 1999 08:10:17 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Certificate requests for encryption keys
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 HAA27361
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This thread has engendered several interesting subthreads, but let's dispatch
the first one, first.

As Steve says, the fundamental principle behind requiring Proof of Possession
with respect to the private key of a key pair is to assure that the user
who is identified in the certificate containing that the public key does
in fact possess the private key, and isn't trying to spoof someone somehow.

In the case of a digital signature, not requiring proof of possession would
allow me to get of copy of Thomas Edison's public key (small time wrap
problem omitted for brevity) and claim all of his digitally signed patents
as my own.  (Assuming he didn't actually include his name
in the patent itself, of course.)

What kind of mischief could someone carry out with an encryption key
without POP? 

Well, maybe I somehow intercept Steve's encryption certificate request
and substitute my own public key in it.  Steve's identity is valid --- he's 
a good guy -- so the certificate would be issued.  Now people 
blurt out their innermost secrets to him, and he can't read them but I
can.

Not very convincing, as I suspect was Brian's point, but my inability
to find a rally zinger of a threat probably means that I'm not thinking hard 
enough, rather than indicating there is no threat.

The obvious was to do POP for encryption keys is for the CA to encrypt a 
challenge, send it to the Subscriber, and have him send back the decrypted
result.  The problem is that is rather awkward from the standpoint of most
certificate request protocols.

Bob

>>> Stephen Kent <[e-mail]> 06/08/99 01:47PM >>>
Anne,

Certs with keys used only for encryption, vs. signing, are still bound to
an identity in the X.509 world.  For exmaple, in S/MIME, one uses such a
key to encrypt a message (more precisely the CEK for the message) for a
specified recipient.  Thus, the sender relies on a CA to have verified the
subject name in that encryption-only cert.  So, I don't think your
characterization of when identity verification is important in signature
vs. encryption certs is a good one.

Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA27165 for ietf-pkix-bks; Wed, 9 Jun 1999 06:49:17 -0700 (PDT)
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 GAA27161 for <[e-mail]>; Wed, 9 Jun 1999 06:49:16 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA28820 for <[e-mail]>; Wed, 9 Jun 1999 09:51:04 -0400 (EDT)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1283186132==_ma============"
X-Sender: [e-mail]
Message-Id: <v04020a01b38420109f2c@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> from "Tony Bartoletti" at Jun 8, 99 12:01:18 pm
Date: Wed, 9 Jun 1999 09:51:30 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1283186132==_ma============
Content-Type: text/plain; charset="us-ascii"

Folks,

This really has gotten out of hand.  I admire the dedication of folks who
have been applying serious intellectual effort to creating a general
formula for cert lifetime as a function of the number of attributes, but
...

As the creator of "Steve's Rule of Revocation" I have to admit that I
generated the simple inverse square formula just to make a point, i.e.,
that, in general, adding attributes to a cert will shorten it's effective
lifetime and thus is generally a bad idea.

As some have pointed out, a general formula is hard, since one can cite
examples whwre added attributes are so closely linked to existing
attributes that the addition has no real effect on expected lifetime.
Also, contributors to this thread pointed out early on that it is the
attribute with the shortest expected lifetime that governs the lifetime of
the cert.  So, trying to express the lifetime in terms of a pure attribute
count seems futile.

Now, if I had to justify my original formula, I might try the following
analogy:

1. Adding attributes to a cert is a generally bad idea.  In vernacular
terms, it "sucks."

2. Looking to physics for an analogy, we note that, in the vernacular,
gravity "sucks."

3. The inverse square law applies to gravitational attraction between bodies.

4. Therefore, the effective lifetime of a certificate is inversely
propotional to the inverse square of the number of attributes :-)


Steve
--============_-1283186132==_ma============
Content-Type: text/enriched; charset="us-ascii"

Folks,


This really has gotten out of hand.  I admire the dedication of folks
who have been applying serious intellectual effort to creating a
general formula for cert lifetime as a function of the number of
attributes, but ... 


As the creator of "Steve's Rule of Revocation" I have to admit that I
generated the simple inverse square formula just to make a point, i.e.,
that, in <bold>general</bold>, adding attributes to a cert will shorten
it's effective lifetime and thus is <bold>generally</bold> a bad idea.


As some have pointed out, a general formula is hard, since one can cite
examples whwre added attributes are so closely linked to existing
attributes that the addition has no real effect on expected lifetime. 
Also, contributors to this thread pointed out early on that it is the
attribute with the shortest expected lifetime that governs the lifetime
of the cert.  So, trying to express the lifetime in terms of a pure
attribute count seems futile.


Now, if I had to justify my original formula, I might try the following
analogy:


1. Adding attributes to a cert is a generally bad idea.  In vernacular
terms, it "sucks."


2. Looking to physics for an analogy, we note that, in the vernacular,
gravity "sucks."


3. The inverse square law applies to gravitational attraction between
bodies.


4. Therefore, the effective lifetime of a certificate is inversely
propotional to the inverse square of the number of attributes :-)



Steve

--============_-1283186132==_ma============--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA24488 for ietf-pkix-bks; Wed, 9 Jun 1999 04:33:42 -0700 (PDT)
Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA24484 for <[e-mail]>; Wed, 9 Jun 1999 04:33:41 -0700 (PDT)
Received: from GK-Portable (unverified [62.188.144.65]) by pegasus.group5.co.uk (Rockliffe SMTPRA 2.1.5) with SMTP id <[e-mail]>; Wed, 09 Jun 1999 12:26:31 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 09 Jun 1999 12:34:57 +0100
To: Stephen Kent <[e-mail]>
From: Graham Klyne <[e-mail]>
Subject: On the need for external assurance
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 19:36 08/06/99 -0400, Stephen Kent wrote:

>In working on various aspects of "the PKI problem" for the last decade,
>many of us have found that it is very hard to create self-contained systems
>that operate independent of external assurances, and it may have just been
>a bad idea from the start.

I find this an intriguing statement, not because I disagree but I can't see
why anyone might think otherwise.

I may be missing something, but it seems to me that a self contained system
operating independently of external assurances is like a perfect
mathemtical model that bears no relationship to the real world -- i.e. it
has no practical value.

It seems to me that the external assurance must, by definition, come from
outside the system.  The challenge that I see, then, is to devise the
system to maximizes application of the external assurance while minimizing
any degradation of its strength (or reliability).

#g


------------
Graham Klyne
([e-mail])



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA24343 for ietf-pkix-bks; Wed, 9 Jun 1999 04:05:32 -0700 (PDT)
Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA24339 for <[e-mail]>; Wed, 9 Jun 1999 04:05:30 -0700 (PDT)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id LAA09078; Wed, 9 Jun 1999 11:07:06 GMT
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id MAA03072; Wed, 9 Jun 1999 12:07:19 +0100
Message-ID: <[e-mail]>
Date: Wed, 09 Jun 1999 12:07:04 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate requests for encryption keys
References: <[e-mail]> <v04020a0db38325216509@[128.89.0.110]> <v04020a03b38342d21a49@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:
> 
> Ben,
> >Stephen Kent wrote:
> >>
> >> Ben,
> >>
> >> >
> >> >??? If I HMAC then DH the result, isn't that a signature?
> >>
> >> No, encrypting a hash (I assumed you meant a hash, not HMAC)
> >
> >Sorry, yes, I do, of course.
> >
> >> for
> >> verification by a specified entity (the entity whose public key was an
> >> input to the DH computation you performed) isn't a signature.
> >
> >I encrypt the hash with my private key, of course, not someone else's
> >public key.
> 
> NYou don't encrypt anything with a D-H private key or public key.  Use use
> your private key and someone else's public key to generate a shared secret
> value, which can then be used as a symmetric key for encryption) or as an
> input to a symmetric authentication algorithm (e.g., HMAC).

Duh. Sorry, I've been thinking too much about blinded DH signatures (a
la Wagner) lately. Of course, the point there is that I check _my own_
"signature" (which I signed blind at some point), not someone else's.

Cheers,

Ben.

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

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA20704 for ietf-pkix-bks; Wed, 9 Jun 1999 02:29:59 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA20699 for <[e-mail]>; Wed, 9 Jun 1999 02:29:56 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id TAA01626; Wed, 9 Jun 1999 19:33:47 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: "'Manger, James'" <[e-mail]>, <[e-mail]>
Subject: RE: Timestamp: confidential content
Date: Wed, 9 Jun 1999 19:29:09 +1000
Message-ID: <003001beb25a$8cb38a90$[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 V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James,
The draft says that the "hashedMessage field SHOULD contain the hash of the
datum to be time stamped". That definition (SHOULD, not MUST) leaves room
for having any type of data as the hashedMessage. So the client can pass a
hash, a salted hash, or even a message in the clear, or whatever else with
the messageImprint.

I do not see how optional 'salting' the hash eliminates requirement for
having the nonce field. The nonce is used to verify that the received
response is indeed for the request that has been sent, to prevent a replay
attack. Please, explain.

By the way, sending clear data should be made possible, if the client wants
to. To do that, TSA should not assert the strength of the hashAlgorithm, and
accept mesageImprint with no hashAlgorithm at all. Which requires making the
field optional. But please (please) do not start another discussion on
this - we had enough of it already :).

I'm not sure that defining extra attributes is a good idea. Unless we make
using the attributes mandatory and the only possible option, it adds
unnecessary complexity to the client, which now has extra options where to
look for the time stamp data.

Regards
MichaelZ

-----Original Message-----
From:	[e-mail] [mailto:[e-mail]] On Behalf Of
Manger, James
Sent:	Wednesday, June 09, 1999 12:58 PM
To:	'[e-mail]'
Subject:	Timestamp: confidential content

You should be able to timestamp a message without compromising its
confidentiality.  Including a digest instead of the actual message in the
timestamp is not quite enough.  Revealing a digest allows anyone who can
guess the message (exhaustively search the potentially small message space)
to confirm that their guess is right.  A salt is needed.

Instead of submitting a digest of the message, the requestor submits a
digest of a combination of a salt and the message.  The requestor does not
submit the salt.  The following syntax could be used by the requestor to
store the returned timestamp:

TimestampedData ::= SEQUENCE {
	source		SEQUENCE {
				random	OCTET STRING,
				content	OCTET STRING  OPTIONAL
			},
	timestamp	TSTInfo -- "messageImprint" is the digest of the DER-encoded
"source" field with the "content" present
}

This makes the "nonce" field in TSTInfo unnecessary.  By chosing a fresh
value for the "random" field the requestor ensures the "messageImprint" is
fresh and, hence, that the timestamp is fresh.

Two attribute definitions might be useful.
The timestampedContent attribute is suitable as an authenticated or
unauthenticated attribute in a {PKCS #7|CMS} SignedData value.  The content
is the content of the SignedData value (i.e. the same octets that are used
to calculate the messageDigest authenticated attribute).  The
timestampedSignature is suitable as an unauthenticated attribute in a {PKCS
#7|CMS} SignedData value.  The content is the encryptedDigest value (i.e.
the signature).

timestampedContent	ATTRIBUTE ::= { WITH SYNTAX TimestampedData  ID id-at-???
1 }
timestampedSignature	ATTRIBUTE ::= { WITH SYNTAX TimestampedData  ID
id-at-??? 2 }



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA20375 for ietf-pkix-bks; Wed, 9 Jun 1999 02:11:49 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA20371 for <[e-mail]>; Wed, 9 Jun 1999 02:11:46 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id TAA01528; Wed, 9 Jun 1999 19:15:34 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: "'Manger, James'" <[e-mail]>, <[e-mail]>
Subject: RE: Timestamp: TDA in timestamp
Date: Wed, 9 Jun 1999 19:11:03 +1000
Message-ID: <002f01beb258$01575780$[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 V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well, I guess the reason for having TDA tokens INSIDE time stamp token and
OPTIONAL is explained by the draft as "...TDA... provides supplementary
evidence for the time...". The time stamp is the prime goal ("datum existed
before a particular time"), and anything else (i.e. "datum existed during a
particular event's life span") is supplementary and largely redundant
knowledge.
To me, the fact that TDA handling and associated structures are described in
the dark and gloomy corner of the draft, signifies that the authors have
reasonable amount of doubts in potential usefulness of TDA tokens. I feel
that as the time stamping infrastructure matures, the TDA will eventually
either 1) evolve into a separate service, used directly by the clients,
supplying time stamped data (exactly what you have proposed), or 2)
disappear from the PKI fields.

After all, why do we need any supplementary evidence of timing if you trust
TSA? If you do not trust TSA, then how can you trust TDA token obtained and
verified by [non-trusted] TSA? The complexity of dealing with TDAs does not
seem to justify the value of extra supplementary info in the time token.
Would like to hear any other opinions.

Regards
MichaelZ


>Why are TDA tokens included in timestamp tokens?  Why not the other way
around?  Why shouldn't clients go directly to a TDA?

>A TDA says a datum existed before a particular event.
>A TSA says a datum existed before a particular time.
>Their similarities should means similar syntaxes can be used for their
tokens & similar protocols for interacting with them.  Perhaps even common
syntaxes and >protocols with a small number CHOICE or OPTIONAL fields could
be used.

>Nesting TDAs within TSA tokens, however, does not make much sense.  This is
highlighted by the fact that the TemporalDataToken, as used for the
tdaTokens field of >TSTInfo, is not even defined in the main body of the
draft standard (it is in an appendix).  Appendix C.3. adds lots of onerous
requirements to a TSA that it is not >interested in: verifying TDA
signatures, checking TDA names, nonces, interacting with a TDA, etc.

>If nesting of TDA & TSA tokens is a useful feature
>Nesting can always be implemented "outside" the protocol by getting, say, a
TDA token then having this timestamped (i.e. send the hash of the TDA token
as a >messageImprint to a TSA).  Attribute syntaxes to hold all the
resulting tokens would then be useful.


>=> remove the tdaTokens field from TSTInfo
>=> perhaps replace tstTime with
>	value	CHOICE {
>			time		TSTTime, -- used by TSA
>			temporalData	TemporalData -- used by TDA
>		}



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA19946 for ietf-pkix-bks; Wed, 9 Jun 1999 01:36:50 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA19942 for <[e-mail]>; Wed, 9 Jun 1999 01:36:47 -0700 (PDT)
Received: by puma.baltimore.ie; id KAA22084; Wed, 9 Jun 1999 10:17:51 +0100 (GMT/IST)
Received: from ocelot.baltimore.ie(10.49.0.10) by puma.baltimore.ie via smap (4.1) id xma022052; Wed, 9 Jun 99 10:17:13 +0100
Received: from crown (crown.baltimore.ie [10.49.0.138]) by ocelot.baltimore.ie (8.8.7/8.8.5) with SMTP id JAA13098; Wed, 9 Jun 1999 09:37:57 +0100
Received: by localhost with Microsoft MAPI; Wed, 9 Jun 1999 09:39:03 +0100
Message-ID: <[e-mail]>
From: Tom Biskupic <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Possible clarification to RFC 2459
Date: Wed, 9 Jun 1999 09:39:02 +0100
Organization: Baltimore
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,

I was thinking of the case where you have a certificate without a CDP 
extension and you have a cached CRL containing an IDP. Do I need to get 
another CRL or should this certificate be contained in the one I have?

I think the bottom line is you can only use the CRL if its DP matches your 
certificate's (either explicitly through a CDP extension or implicitly). 
Presence/absence of an IDP is not enough to determine this.

I'm really arguing against Ambarish's statement (and not som much the other 
Tom's [TomG's] original comments) so I guess we are off-topic a bit:-

"A full CRL from/for a CA MUST NOT contain the
issuingDistributionPoint extension, unless it is an indirect CRL,
in which case, it MAY contain the issuingDistributionPoint
extension with only the indirectCRL field set to true."

Tom Biskupic

On Tuesday, June 08, 1999 8:30 PM, David P. Kemp 
[SMTP:[e-mail]] wrote:
>
> > From: Tom Biskupic <[e-mail]>
> > To: "'Ambarish Malpani'" <[e-mail]>
> > Cc: "[e-mail]" <[e-mail]>, "'Tom Biskupic'"
> <[e-mail]>, "'Ietf-Pkix (E-mail)'" <[e-mail]>, 
"'Alex
> Deacon'" <[e-mail]>
> Tom,
>   As you say, the presence of an IDP extension (with onlyUserCerts,
> onlyCACerts, and onlySomeReasons all absent) in the CRL does not indicate
> whether the CRL covers every cert issued by the CA or only some certs.
> A CA's CRLs could, for example, be partitioned by serial number, or by
> the phase of the moon at the start of the certificate's validity, or at
> random.
>
> But why is that a problem?  If you have a cert with CrlDP, then you can
> determine the revocation status of that cert unambiguously without
> needing to know whether the CRL is full or partial.  That is a feature,
> not a bug, because it allows CAs to do dynamic partitioning.
>
> If you have a set of certs without CrlDP, then the CA has chosen not to
> partition those certs in a manner that can't be described in the IDP,
> and the status of any particular cert is still unambiguous.
>
> Why do people feel it is necessary or desirable to know whether a given
> CRL is full or partial?  The only question that must be answered is
> whether a CRL or set of CRLs is complete with respect to a given
> certificate.  RFC 2459 already satisfies that requirement.  Any
> "clarification" to RFC 2459 that would prevent a CA from issuing new
> certs under a different CRL than existing certs is undesirable.
>
> Dave Kemp
>
>
>
> > Subject: RE: Possible clarification to RFC 2459
> > Date: Tue, 8 Jun 1999 19:06:44 +0100
> >
> > Ambarish,
> >
> > Yes I understand what you are saying. Yes as I said you could argue 
(and in
> > fact you did) that in the case where you have a CRL/ARL split the 
presence
> > of an IDP does indicate the CRL has been partitioned but I am saying 
there
> > is no way to tell if the CRL has been split in other ways.
> >
> > The issue is based on my assumption that there will be many systems 
that
> > split a CRL into a CRL and ARL but few that split further. If a CRL
> > containing a IDP is encountered which has the 'onlyContainsUserCerts'
> > optional flag (which we believe is a common occurence) there is no way 
to
> > tell if the set of revoked certificates has been partitioned further or 
if
> > this is the only split criteria. Ok strictly speaking the CRL is split 
but
> > in this case that's not very useful as what you really want to know is
> > where to go to check the validity of the (usually) end user certificate 
you
> > are holding.
> >
> > A more serious problem occurs in the second case I highlighted - an
> > organisation has no directory service (ie an LDAP server) so they
> > distribute their CRLs through a URI. Every issued certificate (maybe 
even
> > including CA certificates) contains a CDP extension pointing at this 
URI. A
> > complete CRL is posted to that location every day. In this case the
> > presence of an IDP extension in the CRL does not indicate a partial 
CRL.
> > Essentially the lack of an IDP implies a full CRL but the presence of 
an
> > IDP may not indicate a partial CRL.
> >
> > Where does that get us? Hmm I'm not sure.
> >
> > Tom Biskupic


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA19285 for ietf-pkix-bks; Wed, 9 Jun 1999 01:01:42 -0700 (PDT)
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA19281 for <[e-mail]>; Wed, 9 Jun 1999 01:01:40 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA06098 for <[e-mail]>; Wed, 9 Jun 1999 18:02:59 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdulsJS_; Wed Jun  9 18:02:53 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA05648 for <[e-mail]>; Wed, 9 Jun 1999 18:02:52 +1000 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0qYQj9; Wed Jun  9 18:02:37 1999
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [172.85.14.20]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id SAA29358 for <[e-mail]>; Wed, 9 Jun 1999 18:02:37 +1000 (EST)
Message-Id: <[e-mail]>
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <MH5BD2Y5>; Wed, 9 Jun 1999 18:02:24 +1000
From: "Manger, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Timestamp: CMS vs standalone
Date: Wed, 9 Jun 1999 15:26:17 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEB24E.6785569C"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BEB24E.6785569C
Content-Type: text/plain

The CMS SignedData structure is used for timestamp tokens.  This is a great
structure for signing arbitrary content along with auxiliary information
(authenticated attributes) and packaging all this together with extra info
(unauthenticated attributes) and certificates & CRLs to assist verification.

The timestamp draft says CMS SignedData is used but does not really exploit
its features.  Instead the TSTInfo syntax is basically designed to be
standalone (with its signature).  Others have already suggested using an
authenticated attribute for the TSA name (instead of the tsa field), but
this should apply to other fields as well.  Authenticated attributes seem
the logical place to put policies, nonce, TDA tokens and tsaFreeData.  There
is already a well understood & highly appropriate attribute for the time:
signingTime (PKCS #9).  This basically leaves the content as simply the
messageImprint.  There is even an authenticated attribute specifically for
the imprint: messageDigest!  (I have ignored the serialNumber as a TSA can
easily use extra decimal digits in the GeneralizedTime value to ensure
uniqueness, even beyond the TSA's clock resolution if necessary.)

I am unsure, however, that CMS is the best syntax for a specific security
token like a timestamp.  If you were redefining the Certificate or CRL
syntax today would you use CMS for each?  The following may be simpler:

	Timestamp ::= SIGNED { TSTInfo }
or equivalently
	Timestamp ::= SEQUENCE {
			toBeSigned	TSTInfo,
			algorithm	AlgorithmIdentifier,
			signature	BIT STRING }

The protocol for returning such a timestamp should also allow Certificates
and CRLs to be included (to help the requestor in verifying the timestamp).
HTTP & e-mail protocols are probably easy - return two MIME objects; the
timestamp and a SignedData value with no signers (just certs & CRLs).  The
socket protocol isn't hard but may require explicit fields to hold the certs
& CRLs (outside the timestamp), in a similar fashion to SignedData.

[A Timestamp value can always be repackaged as a CMS value without
re-signing.]


------_=_NextPart_000_01BEB24E.6785569C
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IhkIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAdAAAAVGltZXN0YW1wOiBDTVMgdnMgc3RhbmRhbG9uZQBD
CgEJgAEAIQAAAENCMkEwRDQ3RjcxREQzMTFCQ0QxMDAxMDRCMDhEQkYxADgHASCAAwAOAAAAzwcG
AAkAEgACABYAAwASAQEFgAMADgAAAM8HBgAJAA8AGgARAAMAIgEBDYAEAAIAAAACAAIAAQOQBgBk
CQAAHQAAAAMALgAAAAAAQAA5AGDwZZk4sr4BHgBwAAEAAAAmAAAAVGltZS1zdGFtcCBzZXJ2ZXIu
IFRpbWVQcmVjaXNpb24gaW5mbwAAAAIBcQABAAAAKgAAAAG+eZ8TcA8PvtnlkRHSrjAACMckrdIO
Gwl3HgABS6gCAATrmqoAAh8DDgAAAgEJEAEAAAAiBgAAHgYAADUKAABMWkZ1OzYiPgMACgByY3Bn
MTI1/jIA/wIGAqQD5AXrAoMAUBMDVAIAY2gKwHNldP4yBgAGwwKDDlAD1QcTAoMyMxPPZjQDxQIA
cHJCcRLic3RlbQKAfX8KgAjPCdkCgAqBDnELYG5QZzMwOABQaAWweqhkb2MAACoSVSACkT0bEGwb
RQr7FOIB0CBUEGhlIEMF4mlnbikJgERhAZAgFyBydZxjdAhwHdAEACB1ErBsZCACEAXAdAdyAZBt
EnAgMG9rCfBzLiD/HaEfgR+BHsAJwR6gHtkgAhcAkB5QC4BnIeByYmnzHvAKwHkgBaACMAnwBUBP
B0ACICOwA/B0aCHgdf54AxAHMCRBC4AgAQDAIED5AiAgKCWgJXAksQ3gHqBnH9EeoB7waWInIAeQ
KQ0h4G4f4AqwY2thZ70jk2wDICVwH4Eg4GcSwD8dwAXAJVMLRhOyHYFleOckESYzJvB1bicfKCsc
zbZjBJAgQGYtQwQgJh3gfFJMKgIh4AQQBAAFQHb3BnItQibBLgqFCoUdsiBI7mQkIAGAHtBhFxAd
7h+GyyhBNABvB5FubwVAIiFvKaAkUCvwC1BvJAAfcHTdBCBmIjEfQSEySQCAFzDOYR/gLPEdoFNU
OOAscaRzeQIwYXgfcmIxEL8tQTcyDnAjUh/RMOFiHdDvIIEowCTyHdAoJVM38iNS9ThTKSFBTypi
BCASgDGAiyThIiFkJFBzdWcqQP8XIR/gH7AjkwOgLN8oJB/0fTlzQTawIKA84QuAOQRvHmY5UzgA
HsAv8GVsZKwpLDYjKdNzGoB1ROD9IeBwC1AkUDDhNtAqckSzqyHRBCB3RNBsIUFBQP/3KDQe0Ang
bTlTF/ApQDsBryjgC2AvoDDScDZBcAbw2w3gCJBzRRA2wG4voEUQvFREQwAg5CijRHFGCdH/HpIh
QwSQH2M/Nh7AR8IfoD8owD6hIOAEcDBhIYBnaP83QUYxA2AWsAcwQjErDUHIdxzNQmYgQjojRgdi
JvBQ5EtDBfAjOT4yIXM6yP5sIjAxgCoBHcEkdz2CILDfRmIdwQeBNHAqQEkgsAUQewIwTlplMYBA
wUDPQddz/nAFkC/jNzJCZllBWoJVQC1Z5UQeQCBxISFQKEl/PtQeQQWwO8IdwRKwByJO/nUG0CqB
R5EewELiLVADoP8iMACQN0EfsSvlBYEHcEqh3mQeQDfyC4A5U0cJ8ASQ2QdAaXoJgFXTdgdAClDP
MNIhER9CLLBpcQpQHmBvBBBFEFuDPCB5AiA5RkG6JwQgYxfwKRA28XMG8H9cECbCBpA2sAWQWfIk
QC7+KTJcCvsrhWBwIKBP8Wdi/0UQGoBHwDGBRRAlcCJBHfL/KfIdwTwgMVE6JSACHsFdlXVJsWMI
cXRGciEBSkBpvyEAIeEgRziyRBBo4HVHsb8fURhhDoALgCOSOWJDL7h/Q/AFwDCROhYg4DyQJFB3
f0XjdEJjsh3yIAIiMBJwP/9OYx/xKaBuwCOSAMAkUDwie1lCBJA6a80BkR2gIFc6BDo9BgBJR05F
RPUDMHs5l1wZgmxiePJn4D5pZrEksTdAe9986EVR4FVFTkNFfdGAGoLYuSDgQmUeNICEObQsgm9b
gIMHQGcFsCVhbYCDQf2GpkkOcFxRRLFvEIU/gIMjPaeAg0JJVAYAVFL4SU5HfogyyVFhIOAX0f8f
8xhgHzEjgz+wEnBzKkW3/mxqUCmCbsB1uk1EMJY8IdsLgGnQdQ5wH+AoMOEdwP5sIMEdwRhgZ+FQ
UQXAZUEdMYN5dUYgRz4ySFRU8lAwYWUtAMADEYzmIdF/H1FRYTrAAmA3UTEQJFAtz42lIDB3wAXQ
SU2CIJgA9moFkDgAO5UMKKMewB45n2a0JVM2wCNDPqIoah+w/wVAL6IwVlakPDFp8RLAjNj5BABu
JwVAEoE2FHpyk6L+aR9RN3JL0QVARyWS4gbw3zlEniom8AhgOABpDnCVDb9FEGVBHsEHcAMQCsFm
MRDfIYAm0TDhHjgyTVtDAHyY92a0YwIHQHc0gjwhGGAo9L8tgiHSHfKcaKSxNvEtI1W8Ll1sNxzr
bDUXgQCwQAAAAwD9P1IDAAADACYAAAAAAAMANgAAAAAAHgAxQAEAAAAQAAAASk1BTkdFUjI5Mjg4
RUYzAAMAGkAAAAAAHgAwQAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAMAGUAAAAAAAgH5PwEAAABn
AAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAABgAAAC9PPVRFTFNUUkEvT1U9UUxEIEtJTkdTRk9S
RC1TTUlUSC9DTj1NUyBNQUlMIFJFQ0lQSUVOVFMvQ049Sk1BTkdFUjI5Mjg4RUYzAAAeAPg/AQAA
AA4AAABNYW5nZXIsIEphbWVzAAAAHgA4QAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAIB+z8BAAAA
ZwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAYAAAAvTz1URUxTVFJBL09VPVFMRCBLSU5HU0ZP
UkQtU01JVEgvQ049TVMgTUFJTCBSRUNJUElFTlRTL0NOPUpNQU5HRVIyOTI4OEVGMwAAHgD6PwEA
AAAOAAAATWFuZ2VyLCBKYW1lcwAAAB4AOUABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwBAAAcwYGZi
kiyyvgFAAAgwnFaFZ06yvgEeAD0AAQAAAAEAAAAAAAAAHgAdDgEAAAAdAAAAVGltZXN0YW1wOiBD
TVMgdnMgc3RhbmRhbG9uZQAAAAALACkAAAAAAAsAIwAAAAAAAwAGEOR+2w4DAAcQsAYAAAMAEBAA
AAAAAwAREAIAAAAeAAgQAQAAAGUAAABUSEVDTVNTSUdORUREQVRBU1RSVUNUVVJFSVNVU0VERk9S
VElNRVNUQU1QVE9LRU5TVEhJU0lTQUdSRUFUU1RSVUNUVVJFRk9SU0lHTklOR0FSQklUUkFSWUNP
TlRFTlRBTE9OAAAAAEjb

------_=_NextPart_000_01BEB24E.6785569C--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA14399 for ietf-pkix-bks; Wed, 9 Jun 1999 00:04:51 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA14394 for <[e-mail]>; Wed, 9 Jun 1999 00:04:50 -0700 (PDT)
Received: from mcg.org.br (pm09-14.sac.verio.net [209.162.65.127]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id AAA19332; Wed, 9 Jun 1999 00:06:29 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 08 Jun 1999 23:57:00 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: PKIX <[e-mail]>, "'Andrew Probert'" <[e-mail]>, [e-mail]
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
References: <D1A949D4508DD1119C8100400533BEDC1077BE@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan:

I see no useful content that I can reply to, as much as I read your
message below. Either all was said or all was again said.

Cheers,

Ed Gerck

Alan Lloyd wrote:

>         Oh dear
>         snip
>
> >  "Gerck's certificate lifetime equation requires the user to input
> > their
> >  assumptions on each presented attribute validity lifetime (an
> > average)
> >  of a *given* certificate, ..."
> >
> > So, you are the equation user, what should you do? Input your
> > assumptions
> > on each attribute lifetime -- even if you call your assumptions by a
> > long name
> > such as "doctrinal, operational, policy, procedural and human
> > factors".
> >
>         No - the point is that it is not just an attribute in
> acertficate that affects its lifetime - its the environment and context
> it lives in.
>
>         EG. people have heads, arms, legs..etc.. they have attributes
> like age, name, height etc..
>
>         Their lifetime may be affected by these - in that a part of this
> attribute dies..naturally eg if a person has 16 legs and 16 arms  (lots
> of attributes) its likely that they will trip over themselves and
> accidently strangle themselves in the fall.
>
>         It more likely that humans die from external issues such as
> disease, injury, poisoning, etc which is not of their own "attributes"
>         ie. some doctors deal with eyes, noses and feet - others deal
> with health systems and social well being.. the two are not at conflict-
> the later is just a broader view.
>
>         regards alan
>
> > Cheers,
> >
> > Ed Gerck
> >

--
Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA12548 for ietf-pkix-bks; Tue, 8 Jun 1999 23:25:08 -0700 (PDT)
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA12544 for <[e-mail]>; Tue, 8 Jun 1999 23:25:06 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA00830 for <[e-mail]>; Wed, 9 Jun 1999 16:26:25 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdMKkyS_; Wed Jun  9 16:26:03 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA09348 for <[e-mail]>; Wed, 9 Jun 1999 16:26:02 +1000 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0R29I5; Wed Jun  9 16:25:40 1999
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [172.85.14.20]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA05007 for <[e-mail]>; Wed, 9 Jun 1999 16:25:39 +1000 (EST)
Message-Id: <[e-mail]>
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <MH5BC9X8>; Wed, 9 Jun 1999 16:25:25 +1000
From: "Manger, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Timestamp: TDA in timestamp
Date: Wed, 9 Jun 1999 13:49:51 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEB240.DAB2BAF0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BEB240.DAB2BAF0
Content-Type: text/plain

Why are TDA tokens included in timestamp tokens?  Why not the other way
around?  Why shouldn't clients go directly to a TDA?

A TDA says a datum existed before a particular event.
A TSA says a datum existed before a particular time.
Their similarities should means similar syntaxes can be used for their
tokens & similar protocols for interacting with them.  Perhaps even common
syntaxes and protocols with a small number CHOICE or OPTIONAL fields could
be used.

Nesting TDAs within TSA tokens, however, does not make much sense.  This is
highlighted by the fact that the TemporalDataToken, as used for the
tdaTokens field of TSTInfo, is not even defined in the main body of the
draft standard (it is in an appendix).  Appendix C.3. adds lots of onerous
requirements to a TSA that it is not interested in: verifying TDA
signatures, checking TDA names, nonces, interacting with a TDA, etc.

If nesting of TDA & TSA tokens is a useful feature
Nesting can always be implemented "outside" the protocol by getting, say, a
TDA token then having this timestamped (i.e. send the hash of the TDA token
as a messageImprint to a TSA).  Attribute syntaxes to hold all the resulting
tokens would then be useful.


=> remove the tdaTokens field from TSTInfo
=> perhaps replace tstTime with
	value	CHOICE {
			time		TSTTime, -- used by TSA
			temporalData	TemporalData -- used by TDA
		}


------_=_NextPart_000_01BEB240.DAB2BAF0
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IhoGAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAcAAAAVGltZXN0YW1wOiBUREEgaW4gdGltZXN0YW1wANIJ
AQmAAQAhAAAAQzMyQTBENDdGNzFERDMxMUJDRDEwMDEwNEIwOERCRjEAKQcBIIADAA4AAADPBwYA
CQAQABkAFgADACcBAQWAAwAOAAAAzwcGAAkADQAxADMAAwBZAQENgAQAAgAAAAIAAgABA5AGAKQH
AAAdAAAAAwAuAAAAAABAADkAkM7YICuyvgEeAHAAAQAAACYAAABUaW1lLXN0YW1wIHNlcnZlci4g
VGltZVByZWNpc2lvbiBpbmZvAAAAAgFxAAEAAAAlAAAAAb55nxNwDw++2eWREdKuMAAIxySt0g4b
CXceAAFLqAIABOuaqgAAAAIBCRABAAAAawQAAGcEAABOBwAATFpGdR4DjNMDAAoAcmNwZzEyNf4y
AP8CBgKkA+QF6wKDAFATA1QCAGNoCsBzZXT+MgYABsMCgw5QA9UHEwKDMjMTz2Y0A8UCAHByQnES
4nN0ZW0CgH1/CoAIzwnZAoAKgQ5xC2BuUGczMDgAUGgFsHqoZG9jAAAqElUgApE9GxBsG0UK+xOy
AdAgVwhoeSAKwGUgVETgQSB0b2sJ8AQgC4D2YwpADnBkHtEeYAdyAZAkbXAeZT8gHaNub3kFQHRo
HhAhICFgBcB3pmEd0ghgbmQgpXMagOB1bGRuJwVAHwAIkIMCMAQgZ28gZGkYYHhjdGwd0B5wHeAe
Ij/vCoUKhR5QHjJzIgAEICUQAGRhdHVtIGV49wQAFzAfUGIOgAWwHhAlEJsKsR+gYyMwCsFldiPR
7i4Kjx0YJlFTJpULRhTivx2BJw8oHwXAH6IpllQhYN8kYCLwB3ADEArAaR+gB5G9IwQgB4AGIjBV
IvB5AjA0YXgHkWMDkS3wIHW/ErAfUC4RIUIwIR51JjHn/xawISAa0AbwBCAzwguAFzC+cgDQH6Aa
ECHgMMBoIUK0bS4gsFAEkBKAcAQg/ylCI5ADcARgA6AydwBwH1BXNXg3EyUQcwDAbAMgbgctQC3w
BcBDSE9JQwZFIYAFwE9QVElP+E5BTDOwCJAjQDLhMUP/M0UplimlB8AXIDbSHjE6ZKcfcStyHnQs
IBqAdylB/nJBABrAB5EhEgDAHpAxgP51EnAi8B6hL2AgsC/wBADnHtAEIEAgZ2gjsEQALbN7JMEh
YWY2oSFBLSAhQ1QtF0BwBbAHQEQtIGFU+x6CQQBhBCAzeh5gLRBGs7c18T0CIYBmK2E8gG4CEP9B
AEOBIRI4Uw5xC4AfRSFhdwDAH3EG4GQd0EkhIVJkPzaQAYAi8AGQInALESAo3zDAQ6IfcQOROBBw
CfAkUDR4KTehQU51O7AuM/k3oGFkPTEX8CPxSSECIM8EkAhgBCAYYHF1JGEHgP8j4iTkQHJFck2k
IRI2Ux/R2R9DOiBBYQaQeT9lMEF8Z24tIVPhQQAScAWQa/9U9lWgB4FBACEQHvBV8jZfdyUTQQAS
wGMpnx0JWbVJ/0kwSuA/REkiHkE00EBoQ6L7JRAzcWYjMDOwMaBVwj69/zMCB0Ah8QQgM0EHcAtQ
UbOtH0EiCGAj8GkOcCIhQ/s1dkSSZxLANsJBACaxRwHvHighQgOgEoB2NtJAEVIB9x+2H0FNkC5D
IULhH1AhUv8SgCMATCZkKEchJRAHgSaw/WMgSSAQBRACMFIXTuMCQP0FEGJhoB4QMnck4RqAMWG/
OxIhUlPhIzA2wx51dzFDn2TDM0ReQT49WbU9PlFB/wRgKVBH30jiA1JJRnBYToD/N/QYYAtRV6Ae
YBcgB2I3A39ZtgGRVIAHQApQdjM7xVz+e3XKeCgfongoSVEHYkEA/C0tM2REoStxd794xEYJ33mk
Rgl6ex5Ae29cGYIlqQUXgQCB0AADAP0/UgMAAAMAJgAAAAAAAwA2AAAAAAAeADFAAQAAABAAAABK
TUFOR0VSMjkyODhFRjMAAwAaQAAAAAAeADBAAQAAABAAAABKTUFOR0VSMjkyODhFRjMAAwAZQAAA
AAACAfk/AQAAAGcAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAGAAAAL089VEVMU1RSQS9PVT1R
TEQgS0lOR1NGT1JELVNNSVRIL0NOPU1TIE1BSUwgUkVDSVBJRU5UUy9DTj1KTUFOR0VSMjkyODhF
RjMAAB4A+D8BAAAADgAAAE1hbmdlciwgSmFtZXMAAAAeADhAAQAAABAAAABKTUFOR0VSMjkyODhF
RjMAAgH7PwEAAABnAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAABgAAAC9PPVRFTFNUUkEvT1U9
UUxEIEtJTkdTRk9SRC1TTUlUSC9DTj1NUyBNQUlMIFJFQ0lQSUVOVFMvQ049Sk1BTkdFUjI5Mjg4
RUYzAAAeAPo/AQAAAA4AAABNYW5nZXIsIEphbWVzAAAAHgA5QAEAAAAQAAAASk1BTkdFUjI5Mjg4
RUYzAEAABzBg61cWJLK+AUAACDDwurLaQLK+AR4APQABAAAAAQAAAAAAAAAeAB0OAQAAABwAAABU
aW1lc3RhbXA6IFREQSBpbiB0aW1lc3RhbXAACwApAAAAAAALACMAAAAAAAMABhBQD2fEAwAHEE0E
AAADABAQAAAAAAMAERABAAAAHgAIEAEAAABlAAAAV0hZQVJFVERBVE9LRU5TSU5DTFVERURJTlRJ
TUVTVEFNUFRPS0VOUz9XSFlOT1RUSEVPVEhFUldBWUFST1VORD9XSFlTSE9VTEROVENMSUVOVFNH
T0RJUkVDVExZVE9BVERBPwAAAADSHw==

------_=_NextPart_000_01BEB240.DAB2BAF0--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA12534 for ietf-pkix-bks; Tue, 8 Jun 1999 23:24:48 -0700 (PDT)
Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA12530 for <[e-mail]>; Tue, 8 Jun 1999 23:24:45 -0700 (PDT)
Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA24424 for <[e-mail]>; Wed, 9 Jun 1999 16:26:04 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpddYGlH_; Wed Jun  9 16:26:00 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA09277 for <[e-mail]>; Wed, 9 Jun 1999 16:26:00 +1000 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0mx4TQ; Wed Jun  9 16:25:38 1999
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [172.85.14.20]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA04962 for <[e-mail]>; Wed, 9 Jun 1999 16:25:38 +1000 (EST)
Message-Id: <[e-mail]>
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <MH5BC9XZ>; Wed, 9 Jun 1999 16:25:25 +1000
From: "Manger, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Timestamp: confidential content
Date: Wed, 9 Jun 1999 12:58:15 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEB240.DA8EF7AA"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BEB240.DA8EF7AA
Content-Type: text/plain

You should be able to timestamp a message without compromising its
confidentiality.  Including a digest instead of the actual message in the
timestamp is not quite enough.  Revealing a digest allows anyone who can
guess the message (exhaustively search the potentially small message space)
to confirm that their guess is right.  A salt is needed.

Instead of submitting a digest of the message, the requestor submits a
digest of a combination of a salt and the message.  The requestor does not
submit the salt.  The following syntax could be used by the requestor to
store the returned timestamp:

TimestampedData ::= SEQUENCE {
	source		SEQUENCE {
				random	OCTET STRING,
				content	OCTET STRING  OPTIONAL
			},
	timestamp	TSTInfo -- "messageImprint" is the digest of the
DER-encoded "source" field with the "content" present
}

This makes the "nonce" field in TSTInfo unnecessary.  By chosing a fresh
value for the "random" field the requestor ensures the "messageImprint" is
fresh and, hence, that the timestamp is fresh.

Two attribute definitions might be useful.
The timestampedContent attribute is suitable as an authenticated or
unauthenticated attribute in a {PKCS #7|CMS} SignedData value.  The content
is the content of the SignedData value (i.e. the same octets that are used
to calculate the messageDigest authenticated attribute).  The
timestampedSignature is suitable as an unauthenticated attribute in a {PKCS
#7|CMS} SignedData value.  The content is the encryptedDigest value (i.e.
the signature).

timestampedContent	ATTRIBUTE ::= { WITH SYNTAX TimestampedData  ID
id-at-??? 1 }
timestampedSignature	ATTRIBUTE ::= { WITH SYNTAX TimestampedData  ID
id-at-??? 2 }


------_=_NextPart_000_01BEB240.DA8EF7AA
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IhoGAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAgAAAAVGltZXN0YW1wOiBjb25maWRlbnRpYWwgY29udGVu
dAAZDAEJgAEAIQAAAEJFMkEwRDQ3RjcxREQzMTFCQ0QxMDAxMDRCMDhEQkYxADoHASCAAwAOAAAA
zwcGAAkAEAAZABYAAwAnAQEFgAMADgAAAM8HBgAJAAwAOgAPAAMAPQEBDYAEAAIAAAACAAIAAQOQ
BgDgBwAAHQAAAAMALgAAAAAAQAA5AFDDdOsjsr4BHgBwAAEAAAAmAAAAVGltZS1zdGFtcCBzZXJ2
ZXIuIFRpbWVQcmVjaXNpb24gaW5mbwAAAAIBcQABAAAAJQAAAAG+eZ8TcA8PvtnlkRHSrjAACMck
rdIOGwl3HgABS6gCAALicnkAAAACAQkQAQAAAKQEAACgBAAAQgkAAExaRnXzy0htAwAKAHJjcGcx
MjX+MgD/AgYCpAPkBesCgwBQEwNUAgBjaArAc2V0fjIGAAbDAoMOUAPUAgBwhHJxEuJzdGVtAoOu
MwPGBxMCgzQVbX0KgNsIzwnZOxhfDjA1AoAKgYMOcQtgbmczMDgAUEJoBbB6ZG9jAAAq7RJVIAKR
HGBsHJUK+xVSJQwBYwBAIFkIYCBzARvQdWxkIGJlIOUBoGwgAHRvIGAHcgGQFG1wIBAgB4FzYWf7
IAAD8HQfkQVABaAhEANhcwQAC4BnICHwBCAFoG48ZmkOcAIwBzEh8HkuoCAgSW5jCkBkIvJ/IUAk
4CGwFMAjIACAFNBhKR/Qb2YgYGggAWN0fnUHQCFXC4AmYyCoBAAg5G5vBUBxdSHwIAAJ8IkIYGdo
JGFSZXYmAG8kICUKB0AX8HcEIABwed8CICHBG9AiUAORZwpQBBJ/C1UWgh7VJnIhZh4fHyAoVGV4
EoB1FMBpKjBstnkfcCYAchJwJmNwKPBfI9Qw0gDAK1AhV3MKsGNMZSkgYiNzcm0mYWF/BUAmcTQw
LJUosQUQKcB0/SRhQR9wB0AloSjBCeAOcDxkLgqFCoUkkCXnc3W+YiLAAkAk+yZFIWUsJmP/GGAp
ICDRBbE41CuROZkhQO0iYWILgDSQaQIgPPQ2U+8AcB/QLjkkYVQ7KxwQB5H/KOI41CZjNlI/pQIQ
K1Ii8uRzeQIwYXgiUR+1MHD/CYAf4DDgOxwgcTuiIFE7I+8m0ASgRGEgpzo3TAdjIPKNCYBENJAh
QDo6PQYAgEVRVUVOQ0UDMP57CoYBkR9wCGEzgErjSuN3Sc9K1E1dcj6xA3BK408QQ1RFVAYAVFJJ
+E5HLEzvS5gjcTHSTv8BJHBPUFRJT05BdkxQH0uUfVALIKdK41QHT6AkkAIQIC0tICLNIWVJIoEL
gHQiKKImcuE5rERFUi0J8AWgNwH/V7BLNFiwI6AwwB/QIeImY/4iUcVYsBRQB5Aj0QqGGtL/Cr8e
lDemLv8fID/QKLEAwP5rB5FcIyjgJKBbRyehVxZcdW4r8DOAIYFyJFJC+zDgEnBvIuMhQANQB5Ax
UP52B0AKUEKRRYFcMk6UW1b/OxwJ8DjQXRFcFFffBCBlhP8+sTrwJoBicTryNJQoDGWDWTc9VHcg
gDSQdAUQYv8iMFkhDoALgCHwPdFhgTXC/UQFZh+wNzY/0iCnCYAIUL9R426JKLE40CHwICNhK5L/
IBAiMGtBIKAsYBTQJiEFwB9j0HScctl0cUpBUEtD4QXwIzd8QwXgVUAGAP8lYEbBSTNl4z+lUcVY
xnoG5yZFeJ4wEGkuP5FBtAeA/yYwJsASwFjiNJEKwEQlM8LdB0BjH7B1IS4qRCrldd/9btMpP6Vx
qXiSNJBowXNv/wOgda92vS0fd494n3mvJnL/WmFkYAUwSRElZHyfg9aCkH9gLx8gN0xefy3Gcb9K
40FyVE+xQlVPYElzSlAgEFdJVEgGAFlOVLxBWIdvYSJInSSARCMgpGQtNJAtP5hQIIiB/132gx9o
wZNvlH+Wv5fLEuAvXemRP5BVF4EAoRADAP0/UgMAAAMAJgAAAAAAAwA2AAAAAAAeADFAAQAAABAA
AABKTUFOR0VSMjkyODhFRjMAAwAaQAAAAAAeADBAAQAAABAAAABKTUFOR0VSMjkyODhFRjMAAwAZ
QAAAAAACAfk/AQAAAGcAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAGAAAAL089VEVMU1RSQS9P
VT1RTEQgS0lOR1NGT1JELVNNSVRIL0NOPU1TIE1BSUwgUkVDSVBJRU5UUy9DTj1KTUFOR0VSMjky
ODhFRjMAAB4A+D8BAAAADgAAAE1hbmdlciwgSmFtZXMAAAAeADhAAQAAABAAAABKTUFOR0VSMjky
ODhFRjMAAgH7PwEAAABnAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAABgAAAC9PPVRFTFNUUkEv
T1U9UUxEIEtJTkdTRk9SRC1TTUlUSC9DTj1NUyBNQUlMIFJFQ0lQSUVOVFMvQ049Sk1BTkdFUjI5
Mjg4RUYzAAAeAPo/AQAAAA4AAABNYW5nZXIsIEphbWVzAAAAHgA5QAEAAAAQAAAASk1BTkdFUjI5
Mjg4RUYzAEAABzCQgLDxG7K+AUAACDCq947aQLK+AR4APQABAAAAAQAAAAAAAAAeAB0OAQAAACAA
AABUaW1lc3RhbXA6IGNvbmZpZGVudGlhbCBjb250ZW50AAsAKQAAAAAACwAjAAAAAAADAAYQH0WZ
jQMABxBaBQAAAwAQEAAAAAADABEQAQAAAB4ACBABAAAAZQAAAFlPVVNIT1VMREJFQUJMRVRPVElN
RVNUQU1QQU1FU1NBR0VXSVRIT1VUQ09NUFJPTUlTSU5HSVRTQ09ORklERU5USUFMSVRZSU5DTFVE
SU5HQURJR0VTVElOU1RFQURPRlRIRUEAAAAAa1Y=

------_=_NextPart_000_01BEB240.DA8EF7AA--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA20830 for ietf-pkix-bks; Tue, 8 Jun 1999 20:05:47 -0700 (PDT)
Received: from lux.tenebras.com (dnai-207-181-255-76.dialup.dnai.com [207.181.255.76]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA20825 for <[e-mail]>; Tue, 8 Jun 1999 20:05:46 -0700 (PDT)
Received: from dnai.com (windoze [192.168.100.122]) by lux.tenebras.com (8.8.8/8.8.8) with ESMTP id UAA10406; Tue, 8 Jun 1999 20:06:45 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 08 Jun 1999 20:06:40 -0700
From: Michael Sierchio <[e-mail]>
Reply-To: [e-mail]
Organization: Oversized Metaphysics
X-Mailer: Mozilla 4.51 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anne Anderson - Sun Microsystems <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate requests for encryption keys
References: <[e-mail]> <14173.22785.901159.86568@saguaro>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anne Anderson - Sun Microsystems wrote:

> 2. End-Entities may need to change encryption keys frequently.  Many
>    CAs are not designed for frequent updates.

> 5. It is generally simpler for an End-Entity to manage the
>    certificates used for purposes other than identity.

> So REQUIRING non-identity keys to be certified by a CA seems to rule
> out reasonable and useful models for the use of certificates.

Anne -

All very lucid and cogent.  Unfortunately,  most of the discussion here
has been analogous to the thinking articulated by Michelin when he
declared the automobile to be an accessory of the tire.  Here it is
that PKI is an accessory of the certificate.

I'm in complete agreement with your argument.

Michael Sierchio


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA19788 for ietf-pkix-bks; Tue, 8 Jun 1999 20:00:22 -0700 (PDT)
Received: from urgento.gse.rmit.EDU.AU (urgento.gse.rmit.edu.au [131.170.69.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA19776 for <[e-mail]>; Tue, 8 Jun 1999 20:00:19 -0700 (PDT)
Received: (from rsedc@localhost) by urgento.gse.rmit.EDU.AU (8.9.1a/8.9.1) id NAA24492; Wed, 9 Jun 1999 13:02:37 +1000 (EST)
From: David Chia <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
To: [e-mail]
Date: Wed, 9 Jun 1999 13:02:37 +1000 (EST)
In-Reply-To: <[e-mail]> from "David Chia" at Jun 9, 99 12:41:31 pm
X-Mailer: ELM [version 2.4 PL25+3 PGP6+4]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry, forgot the constant term. Should be
 
     1/T = SUM a(i)/T(i) + SUM SUM b(i,j)/T(i)/T(j) + c
            i               i   j
 
where j>=i, a(i), b(i,j) and c are determined through statistical regression.
If environmental factors other than cert hold attributes are important,
they can also be included in the life equation.


David Chia


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA15845 for ietf-pkix-bks; Tue, 8 Jun 1999 19:39:17 -0700 (PDT)
Received: from urgento.gse.rmit.EDU.AU (urgento.gse.rmit.edu.au [131.170.69.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA15833 for <[e-mail]>; Tue, 8 Jun 1999 19:39:14 -0700 (PDT)
Received: (from rsedc@localhost) by urgento.gse.rmit.EDU.AU (8.9.1a/8.9.1) id MAA24362; Wed, 9 Jun 1999 12:41:32 +1000 (EST)
From: David Chia <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
To: [e-mail]
Date: Wed, 9 Jun 1999 12:41:31 +1000 (EST)
In-Reply-To: <[e-mail]> from "Tony Bartoletti" at Jun 8, 99 12:01:18 pm
X-Mailer: ELM [version 2.4 PL25+3 PGP6+4]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Unless A and B reveal their structure to us, so that we may identify
> and eliminate duplicated components, we cannot apply such a formula.
> And if the duplicated components [ai,bi] for some of the i, all exhibit
> different expected lifetimes, there is no opportunity for the "grouping"
> you mentioned, which says nothing more than SUM[C] to n terms = n*C for
> a constant C.  They will be "groups of 1", and we are reduced to the
> equation I gave:
> 
>   1/TC  =  1/TA + 1/TB - ( SUM[1/TCi] for ci in INTERSECT(A,B) )
> 
> The problem is in identifying this intersection, and not simply treating
> attributes A and B as atoms.

In practice the relationship between A and B might not be simple nor
deterministic. The first order life equation for totally independent
attributes looks simple and straight forward. However, if there are
observable correlations among the attributes, second (or higher) order
life equations might be required and there is also the question of
which type of higher order life equation to be used. Furthermore, since
the relationship (if any) between the attributes most probably will not
be known deterministic, the coeffs of the first order term in the
higher order life equations most probably will not be ones.

If historical data (from the environment and in the context where the
cert is to be used) is available and the distributions of the attribute
lifetimes are roughly statistically normal, the expected cert life
equation might be able to be determined through stepwise regression
which will only include significant first or higher order terms.
Example of a simple second order life equation

   1/T = SUM a(i)/T(i) + SUM SUM b(i,j)/T(i)/T(j)
          i               i   j

where a(i) and b(i,j) are coeffs determined from the statistical regression.
b(i,j) is a measure of the 'intersection' you mentioned.

If historical data is not available, life equation determined from other
'similar' situation could be used for rough approximation but due care
should be taken for possible errors.


David Chia


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04372 for ietf-pkix-bks; Tue, 8 Jun 1999 17:52:33 -0700 (PDT)
Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04367 for <[e-mail]>; Tue, 8 Jun 1999 17:52:31 -0700 (PDT)
Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA07269 for <[e-mail]>; Wed, 9 Jun 1999 10:53:49 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpdAvXqx_; Wed Jun  9 10:53:21 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA18287 for <[e-mail]>; Wed, 9 Jun 1999 10:53:20 +1000 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0hCnL9; Wed Jun  9 10:52:50 1999
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [172.85.14.20]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA24085 for <[e-mail]>; Wed, 9 Jun 1999 10:52:49 +1000 (EST)
Message-Id: <[e-mail]>
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <MH5BBX80>; Wed, 9 Jun 1999 10:52:36 +1000
From: "Manger, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Timestamp: precision - use REAL
Date: Wed, 9 Jun 1999 10:50:47 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEB212.5BFEC4F2"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BEB212.5BFEC4F2
Content-Type: text/plain

The "precision  INTEGER -- 8 bits" field of TSTime is weird, and
unnecessarily so.  We want to express the +/- uncertainty in a time value so
the appropriate syntax is REAL.
P.S. why bother with a TSTTime structure, 2 fields in TSTInfo would do.


TSTinfo ::= SEQUENCE {
	...
	time		GeneralizedTime,
	uncertainty	REAL  OPTIONAL, -- UTC = time +/- uncertainty (in
seconds)
	...
}


------_=_NextPart_000_01BEB212.5BFEC4F2
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IiUAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAgAAAAVGltZXN0YW1wOiBwcmVjaXNpb24gLSB1c2UgUkVB
TADYCgEJgAEAIQAAAEFEMkEwRDQ3RjcxREQzMTFCQ0QxMDAxMDRCMDhEQkYxADgHASCAAwAOAAAA
zwcGAAkACgA0ACEAAwBHAQEFgAMADgAAAM8HBgAJAAoAMgAvAAMAUwEBDYAEAAIAAAACAAIAAQOQ
BgAUBQAAHQAAAAMALgAAAAAAQAA5AJAPlxwSsr4BHgBwAAEAAAAmAAAAVGltZS1zdGFtcCBzZXJ2
ZXIuIFRpbWVQcmVjaXNpb24gaW5mbwAAAAIBcQABAAAAIAAAAAG+eZ8TcA8PvtnlkRHSrjAACMck
rdIOGwl3HgABS6gCAgEJEAEAAADfAQAA2wEAAL8CAABMWkZ1ovcqugMACgByY3BnMTI1/jIA/wIG
AqQD5AXrAoMAUBMDVAIAY2gKwHNldP4yBgAGwwKDDlAD1QcTAoD+fQqACM8J2QKACoEOcQtgoG5n
MzA4AFBoBbBQemRvYwAAKhJVIHsCkRhAbBh1CvsTsgHQIEBUaGUgInAVkGMFBABpAiAgIElOVABF
R0VSIC0tIAA4IGJpdHMiIIJmCJBsZCBvZhrQClMHYiAEACB3ZWkZCyAsIABwHVB1bm4bBZAHkHMK
wAMQeSBz1G8uG8BXGwB3AHAFQGB0byBleBsxBBF0+RrxKy8ccB7wHzAAIAtxvnQfsAuAHqAgkB3S
dgdApwpQH8EhQ2FwGzBvGzCVBzB0I3F5AjBheB4CIFJFQUwuCoVQLvJTH/B3aB+wBuAhUQXAHwPw
IVAisR2hHcNzdHLodWN0CHBlHpAS4B0T5wQgIpEdoUluAhAeMAhgPx1BF/AlpiqcHaIpwjo6Aj0G
AEVRVUVOQ5pFAzB7CoYBkSAuLhDvLVoi4i3DLcNHCfAEkAdA7Gl6CYAHYiwtWiHZLcOTJWIbwE9Q
KaBPTiWAwx6QHGFVVEMgLIAi4z0hnigikRKwBaAewHMpXy1fCqQWsirJFLEAOOAAAwD9P1IDAAAD
ACYAAAAAAAMANgAAAAAAHgAxQAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAMAGkAAAAAAHgAwQAEA
AAAQAAAASk1BTkdFUjI5Mjg4RUYzAAMAGUAAAAAAAgH5PwEAAABnAAAAAAAAANynQMjAQhAatLkI
ACsv4YIBAAAABgAAAC9PPVRFTFNUUkEvT1U9UUxEIEtJTkdTRk9SRC1TTUlUSC9DTj1NUyBNQUlM
IFJFQ0lQSUVOVFMvQ049Sk1BTkdFUjI5Mjg4RUYzAAAeAPg/AQAAAA4AAABNYW5nZXIsIEphbWVz
AAAAHgA4QAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAIB+z8BAAAAZwAAAAAAAADcp0DIwEIQGrS5
CAArL+GCAQAAAAYAAAAvTz1URUxTVFJBL09VPVFMRCBLSU5HU0ZPUkQtU01JVEgvQ049TVMgTUFJ
TCBSRUNJUElFTlRTL0NOPUpNQU5HRVIyOTI4OEVGMwAAHgD6PwEAAAAOAAAATWFuZ2VyLCBKYW1l
cwAAAB4AOUABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwBAAAcw4LbsZxCyvgFAAAgw8sT+WxKyvgEe
AD0AAQAAAAEAAAAAAAAAHgAdDgEAAAAgAAAAVGltZXN0YW1wOiBwcmVjaXNpb24gLSB1c2UgUkVB
TAALACkAAAAAAAsAIwAAAAAAAwAGELGj2qsDAAcQJAEAAAMAEBAAAAAAAwAREAQAAAAeAAgQAQAA
AGUAAABUSEUiUFJFQ0lTSU9OSU5URUdFUi0tOEJJVFMiRklFTERPRlRTVElNRUlTV0VJUkQsQU5E
VU5ORUNFU1NBUklMWVNPV0VXQU5UVE9FWFBSRVNTVEhFKy8tVU5DRVJUQUlOVFlJAAAAANhE

------_=_NextPart_000_01BEB212.5BFEC4F2--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA03945 for ietf-pkix-bks; Tue, 8 Jun 1999 17:40:10 -0700 (PDT)
Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA03939 for <[e-mail]>; Tue, 8 Jun 1999 17:40:08 -0700 (PDT)
Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA05527 for <[e-mail]>; Wed, 9 Jun 1999 10:41:25 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpdjet_M_; Wed Jun  9 10:41:16 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA13677 for <[e-mail]>; Wed, 9 Jun 1999 10:41:15 +1000 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd02D.xr; Wed Jun  9 10:40:43 1999
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [172.85.14.20]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA20068 for <[e-mail]>; Wed, 9 Jun 1999 10:40:42 +1000 (EST)
Message-Id: <[e-mail]>
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <MH5BBWMS>; Wed, 9 Jun 1999 10:40:30 +1000
From: "Manger, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Timestamp: GeneralizedTime
Date: Wed, 9 Jun 1999 10:37:49 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEB210.ABB8C92C"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BEB210.ABB8C92C
Content-Type: text/plain

The ASN.1 GeneralizedTime syntax can include fraction-of-second details.
The syntax is:
	YYYYMMDDhhmm[ss[.s...]]{Z|+hhmm|-hhmm}
Example:
	19990609001326.34352Z

X.690 | ISO/IEC 8825-1 gives the extra restrictions for a DER-encoding, but
these still allow the fractional-seconds elements.

11.7 GeneralizedTime
11.7.1 The encoding shall terminate with a "Z"
11.7.2 The fractional-seconds elements, if present, shall omit all trailing
0's; if the elements correspond to 0, they shall be wholly omitted, and the
decimal point element also shall be omitted.
11.7.3 The decimal point element, if present, shall be the point option ".".
11.7.4 Midnight (GMT) shall be represented in the form: "YYYYMMDD000000Z"
where "YYYYMMDD" represents the day following the midnight in question.
11.7.5 Examples of valid representations
	"19920521000000Z"
	"19920622123421Z"
	"19920722132100.3Z"

RFC 2459 says Certificates and CRLs should use second resolution but there
is no good reason to apply this restriction to a timestamp standard.


=> Get rid of the "fractionOfSecond" field in TSTTime, the "genTime" field
already supports it (and to an arbitary number of decimal places).

------_=_NextPart_000_01BEB210.ABB8C92C
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+Ih8AAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAbAAAAVGltZXN0YW1wOiBHZW5lcmFsaXplZFRpbWUABwoB
CYABACEAAABBNjJBMEQ0N0Y3MUREMzExQkNEMTAwMTA0QjA4REJGMQAqBwEggAMADgAAAM8HBgAJ
AAoAKAAcAAMANgEBBYADAA4AAADPBwYACQAKACUAMQADAEgBAQ2ABAACAAAAAgACAAEDkAYAWAcA
AB4AAAADAC4AAAAAAEAAOQAAGtBMELK+AR4AcAABAAAAJgAAAFRpbWUtc3RhbXAgc2VydmVyLiBU
aW1lUHJlY2lzaW9uIGluZm8AAAACAXEAAQAAABsAAAABvnmfE3APD77Z5ZER0q4wAAjHJK3SDhsJ
dx4AAgEJEAEAAADtAwAA6QMAACAGAABMWkZ1X+mWbAMACgByY3BnMTI1/jIA/wIGAqQD5AXrAoMA
UBMDVAIAY2gKwHNldP4yBgAGwwKDDlAD1QcTAoNGMwPFAgBwcnES4nPodGVtAoB9CoAIzwnZDwKA
CoEOcQtgbmczMAo4AFBoBbB6ZG9jtQAAKhJVIAKRGeBsGhWHCvsTsgHQIFRoZRQwwFNOLjEgRwnw
BJAZB0BpegmAB2Igc3lhAjBheCBjA5ELgGObCkAOcCADUADQdGkCIDAtb2YtErAFoG5kjiAOcAGQ
AxBzLiAcc5seJQQAOgqGAZEgWSLBAE1NRERoaG1tMlsEEFsuIOAj4F1dIFx7WnwrI0J8LQ0jQlwY
UgqyRXhhbSULUGUh+zE5JwAwNgIwJyAwMTMyNi5oMzQzDkBaCoUKhVgELjYnICB8IElTAE8vSUVD
IDg4RQ4wLR0AZ2l2B5F00RyRZXh0HWAgFzAV8D8FEB+DBCACEAXAK3BERSxSLQnwBaBkC4BnLPgg
YnUFQCrxErAeEB+Q/mwDIAdAFsAH4CryH1YHQPsgBQQgZSYAB4ACMCDgKEzwMTEuNx0eMXkc8RyC
ny0GHhASgC5xFgBybQuAOmEWACAD8CrwLJEiWv4iMyoS4ByCL08wWC2ABpD+IBWALgECMC2ANNQD
cDXgHy6SKuAdYAMQNJIwJ3N+OzlSKvMwhR6ABbArkXC5IEJ0bzuQLYAq8Xk0xX5iNbEZUC5wPjA6
ghYAZP8tgABwPYEckQWBB3AHQDmA3m8LgAVAMHUukXM9sD5X9z9VMPYzkzMcc0BvMKI5T3c+hCry
QORvBTAfoTYwLktIEDMqNAXQaWQDAGeCaAVAKEdNVCk+SD8XMDmVCYAewS70BbBtOv82MCLGJ3BM
0jZQPtEEkBygz0xHTUBKtyrUZGE+MAIQvy6yNJIq8jVgSVVLcXEKUHcuQQIgQxs1JaYEIB/gIH52
HXEgYEq3NZAsEiIKIncm8QHQDkAxTNZUzycwMv1V8DIn4FXwVn9VsQHAVfCfJ6BWASfQNlcKhVJG
KgBwMjQ1OR4QT3AEIEN7BJAfkGYN4DWRBCA/4kNcUkwEIDTQCGBsIGB1/y4SICQrkQbwLbBH0i2l
TZHJBAAgbj2wZ28EcCuBzmFB4EuBPbBhcAtQPjD/KvBf4SuZYPMq4AdyAZAl4J8uMT/hCxEw/QqF
PT4dEV8FQAUQIGBTQSryIh9WTz8GoCAjTUBcYDBwS1NUU+5UB2I94zYwZwnwB2JnpusHQGCRZD4x
dWFAFtEEIL06oSg/42ERA6AKwGI14PMKwD4wbnUG0ASQUzJER7ULYGMHkCkw9hZRAG7wAAAAAwD9
P1IDAAAeAEIQAQAAADAAAAA8MDFCRTc5RTAuMEU3QkM0NjAubXpvbG90YXJldkBiYWx0aW1vcmUu
Y29tLmF1PgADACYAAAAAAAMANgAAAAAAHgAxQAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAMAGkAA
AAAAHgAwQAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAMAGUAAAAAAAgH5PwEAAABnAAAAAAAAANyn
QMjAQhAatLkIACsv4YIBAAAABgAAAC9PPVRFTFNUUkEvT1U9UUxEIEtJTkdTRk9SRC1TTUlUSC9D
Tj1NUyBNQUlMIFJFQ0lQSUVOVFMvQ049Sk1BTkdFUjI5Mjg4RUYzAAAeAPg/AQAAAA4AAABNYW5n
ZXIsIEphbWVzAAAAHgA4QAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAIB+z8BAAAAZwAAAAAAAADc
p0DIwEIQGrS5CAArL+GCAQAAAAYAAAAvTz1URUxTVFJBL09VPVFMRCBLSU5HU0ZPUkQtU01JVEgv
Q049TVMgTUFJTCBSRUNJUElFTlRTL0NOPUpNQU5HRVIyOTI4OEVGMwAAHgD6PwEAAAAOAAAATWFu
Z2VyLCBKYW1lcwAAAB4AOUABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwBAAAcwkLFNOQuyvgFAAAgw
LMm4qxCyvgEeAD0AAQAAAAEAAAAAAAAAHgAdDgEAAAAbAAAAVGltZXN0YW1wOiBHZW5lcmFsaXpl
ZFRpbWUAAAsAKQAAAAAACwAjAAAAAAADAAYQS7nFkQMABxC9AwAAAwAQEAAAAAADABEQAQAAAB4A
CBABAAAAZQAAAFRIRUFTTjFHRU5FUkFMSVpFRFRJTUVTWU5UQVhDQU5JTkNMVURFRlJBQ1RJT04t
T0YtU0VDT05EREVUQUlMU1RIRVNZTlRBWElTOllZWVlNTURESEhNTVNTU1orSEhNTS1ISE0AAAAA
6v4=

------_=_NextPart_000_01BEB210.ABB8C92C--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA02783 for ietf-pkix-bks; Tue, 8 Jun 1999 17:19:52 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA02778 for <[e-mail]>; Tue, 8 Jun 1999 17:19:48 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <MM4FLP4L>; Wed, 9 Jun 1999 10:21:34 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC1077BE@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>
Cc: PKIX <[e-mail]>, "'Andrew Probert'" <[e-mail]>, [e-mail]
Subject: RE: Summary, was Re: Every time ..., was Re: General formula
Date: Wed, 9 Jun 1999 10:21:33 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

	Oh dear
	snip 

>  "Gerck's certificate lifetime equation requires the user to input
> their
>  assumptions on each presented attribute validity lifetime (an
> average)
>  of a *given* certificate, ..."
> 
> So, you are the equation user, what should you do? Input your
> assumptions
> on each attribute lifetime -- even if you call your assumptions by a
> long name
> such as "doctrinal, operational, policy, procedural and human
> factors".
> 
	No - the point is that it is not just an attribute in
acertficate that affects its lifetime - its the environment and context
it lives in.

	EG. people have heads, arms, legs..etc.. they have attributes
like age, name, height etc..

	Their lifetime may be affected by these - in that a part of this
attribute dies..naturally eg if a person has 16 legs and 16 arms  (lots
of attributes) its likely that they will trip over themselves and
accidently strangle themselves in the fall.

	It more likely that humans die from external issues such as
disease, injury, poisoning, etc which is not of their own "attributes" 
	ie. some doctors deal with eyes, noses and feet - others deal
with health systems and social well being.. the two are not at conflict-
the later is just a broader view.

	regards alan 


> Cheers,
> 
> Ed Gerck
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA00711 for ietf-pkix-bks; Tue, 8 Jun 1999 16:33:51 -0700 (PDT)
Received: from ny.us.ibm.com. (e3.ny.us.ibm.com [32.97.182.103]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA00706 for <[e-mail]>; Tue, 8 Jun 1999 16:33:50 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id TAA83398; Tue, 8 Jun 1999 19:35:34 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.0) with SMTP id TAA247764; Tue, 8 Jun 1999 19:35:31 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525678A.00819387 ; Tue, 8 Jun 1999 19:35:19 -0400
X-Lotus-FromDomain: IBMUS
To: Russ Housley <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 8 Jun 1999 19:34:15 -0400
Subject: Re: Possible clarification to RFC 2459
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley <[e-mail]> on 06/08/99 08:11:53 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   [e-mail]
Subject:  Re: Possible clarification to RFC 2459





Tom:

Your proposed text is too simple.  Consider the Indirect CRL case.  CA1
uses a CRL Distribution Point (CDP) extension to specifify that CA2 will
issue CRLs for reason CA compromise.  Also, CA3 uses a CRL Distribution
Point (CDP) extension to specifify that CA2 will issue CRLs for reason key
compromise.  So, CA3's CRL must include at least reason codes for CA
compromise and key compromise.

Russ

[Tom Gindin]   The proposed amendment is not intended to restrict the use of the
other four fields in Issuing DP.  It merely states that all those certificates
included under a DP whose Issuing DP extension contains a directory name should
be ones issued with that name in the CRL DP extension.  In the Indirect CRL
case, don't the certificate-issuing CA's include the name of the distribution
point to be used?

At 11:25 AM 6/7/99 -0400, [e-mail] wrote:
>     The current definition of Issuing Distribution Point leaves it relatively
>unclear whether the presence of the "DistributionPoint" field within this
>extension indicates that the CRL at that distribution point is a partial
>CRL.  I
>would like to suggest that the following text be added to RFC 2459 section
>5.2.5:
>
>     Where the issuingDistributionPoint extension contains either a DN or an
>RDN, the distribution point SHOULD contain only certificates which contain a
>CRL
>Distribution Point extension one of whose DistributionPoint's contains the
same
>value in the "distributionPoint" field.
>
>     To make it clear that CRL Distribution Point's support partitioning even
>for URL's, the following existing text in section 4.2.1.14 could be
modified as
>follows:
>[Old]     the URI is a pointer to the current CRL for the associated reasons
>and
>will be issued by the associated cRLIssuer.
>[New]     the URI is a pointer to a current CRL for the associated reasons for
>those certificates and will be issued by the associated cRLIssuer.  The CRL so
>referenced SHOULD contain only certificates whose CRL Distribution Point
>extension contains this URI and certificates not containing any CRL
>Distribution
>Point extension.
>
>          Tom Gindin
>
>






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA00680 for ietf-pkix-bks; Tue, 8 Jun 1999 16:33:11 -0700 (PDT)
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 QAA00675 for <[e-mail]>; Tue, 8 Jun 1999 16:33:08 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA22614; Tue, 8 Jun 1999 19:34:54 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a02b38352ea66b7@[128.89.0.110]>
In-Reply-To: <03d501bea898$dd96b750$930aff0c@brick>
References:  <[e-mail]><374D30C8.42 [e-mail]> <v04020a0fb37336bc9254@[128.89.0.110]>
Date: Tue, 8 Jun 1999 19:36:07 -0400
To: "Todd S. Glassey - ELN" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Comments on time-stamp-01: Identification of TSA
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

It's been a couple of weeks since you sent this message, but it still
deserves a response:

>I respect and appreciate your accomplishments but I think you dead wrong
>here and everything I have had to live through for the last two years tells
>me I am right.  My issue in saying this publicly is that "Stephen Kent" is a
>name that carries a lot of weight when it is attached to an opinion, which
>is why I am so baffled as to your resistance to building in these proofing
>facilities into the timestamping process.

I always try to avoid ceating standards that rely on a particular
technology for which there may be intellectual property issues, or which
seem to define a problem to solve, irrespective of real needs.

>It seems to me that what we are focusing on here is an elaborate mechanism
>to pass relative time through a distributed infrastructure, rather than the
>real goal - that being to have a system for representing events in time that
>is accurate, believable, and commercially viable.  Mark the phrase
>"Commercially Viable", because it is the key to any market success we will
>have unless someone puts a law in place to mandate our products.

Commercially viable timestamping takes place today in a variety of forms,
most of which have no need for high precision or high accuracy.  In the
physical world we time stampt with rubber stamps to the granularity of a
day, and with electrical time spamts with a minute granularity, both with
questionable accuracy.  What I sense in many of your postings is a belief
that "commercial viable" requires much different assurances and
accuracy/precsion guarantees.  What I asked for in a previous message was a
coherent discussion of the requirements, without any marketing fluff.  I
have yet to see such a discussion.

>Personally, I am starting to want to call this timestamping protocol the
>Bradley Fighting Vehicle of the PKIX group - ever see Kelsey Grammer in
>"Pentagon Wars" - and although I know that is not true, it's sorta how I
>feel about all the abuse I have taken for questioning the use and
>architecture of this effort's end goals.  The ultimate reason for my
>responses here is driven in the simple economic fact that if I have to shell
>out money for this technology, it better pay me back somehow.

I eon't claim that we can't do better, and maybe we will make a clean start
on this if there is a concensus on that.  Howeverm you should know that
IETF WG development of standards is often an arduous process that sometimes
reuqires compromises, while we do strive to achieve technical elegance.

>As to your commentary particular that "it's not there" below, that is to
>say, the ability in the protocol to prove the chain of custody against the
>time source - I know it's not there and I am trying to figure out why.

Maybe because the WG does not believe that we need it.  Again, I'm waiting
for the technical rationale that justifies such added complexity.

>What I think we have built here today is a system that requires the user or
>operator to jump through external hoops to prove the process and model of
>operations at the sites are OK, otherwise the timestamps issued are of
>questionable veracity and as such there use and reception are likely to be
>limited.

In working on various aspects of "the PKI problem" for the last decade,
many of us have found that it is very hard to create self-contained systems
that operate independent of external assurances, and it may have just been
a bad idea from the start.  Businesses usually engage in bilaterial
agreements with one another or with clients prior to doing business in the
physical world and tryign to create PKIs that avoid the need for such
argreements has probably caused us to have less PKI deployment over the
last 5-10 years.  I would not like to see a similar assumption about time
stamping cause similar problems in this arena.  I think we differ in our
perception of what is needed to make this "work."  I am willing to be
persuaded by suitable arguments, but I've yet to see them, hence my
resistance to efforts to steer this work in the direction you suggest.

>As to the existing draft's specification, my problem is that I have still
>not figured out a legally binding model for a large enough segment of the co
>mmercial world to use this timestamping technology, that this makes
>commercial sense.

This is exactly the sort of argument that I find frighteningly parallel to
the PKI work we've been doing.  Folks have insisted that if we must create
PKIs that will stand up in court when a party tries to repudiate a
signature for a zillion dollar transaction.  Experience has shown that this
is just wrong, and we have seen many examples that support the notion of
limited scope PKIs that provide sufficinet benefit to warrant their
deployment.  I believe that the same will prove true here, and I've yet to
see cogent arguments otherwise.

>DONT GET ME WRONG - I AM NOT TRYING TO TELL YOU THAT THE ZUCCERATTO, et al.
>DRAFT IS BROKEN, just that I want to understand the use models driving all
>this effort in detail.

How about a use model in which a company internally timestamps documents in
an analogous to the wahy in which they used to manually time stamp them.
Workstations throughout the company send hashes of documents to the TSA and
get back appropriate tokens. The TSA could be local to the company, which
would be analogous to what was done manually before.  The assurances that
the TSA does not have it's time changed inappropriately will vary,
depending on the TSA implementation, just as controls for physical time
sources vary considerably in different application environments today.
Even if there is a need here for the company to be able to establish the
source of the time used by the TSA, there is no rerason, a priori, that
this "proof" be available except to an auditor.

Your call for a standard based on a "chain of custody" model sound like
what we would have if we required all PKIs to be very high assurance, e.g.,
users may employ only smart cards, CAs may use only FIPS 140-1 level 3/4
crypto modules, CA software will execute only on a suitable trusted
computing base, ...  We don't require this sort of environment for a
PKIX-compliant PKI, nor have we skewed the standards in any way to better
support such high assurance PKIs.  We do provide for a policy OID in a cert
that allows a CA to state the context in which it issues certs.  Thus it
seems consistent that we support the same sort of infrastructure assurance
labelling here.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27999 for ietf-pkix-bks; Tue, 8 Jun 1999 15:53:50 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27992 for <[e-mail]>; Tue, 8 Jun 1999 15:53:41 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <MM4FLPTQ>; Wed, 9 Jun 1999 08:55:26 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC1077B6@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: Certificate requests for encryption keys
Date: Wed, 9 Jun 1999 08:55:24 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some comments - Generally because the logic of this one seems wrong.
> -----Original Message-----
> From:	[e-mail] 
> Sent:	Wednesday, June 09, 1999 6:23 PM
> To:	[e-mail]
> Subject:	Re: Certificate requests for encryption keys
> 
> Anne Anderson - Sun Microsystems <[e-mail]> writes:
> 
> >I would like to see any Subject, including an End-Entity, be able to
> issue
> >certificates for encryption keys (and possibly other types as well).
> 
> I proposed this some time ago, but there didn't seem to be any
> interest in it.
> Here's the message from last time...
> 
> Peter.
> 
> -- Snip --
> 
> Current X.509 profiles all require the presence of an arbitrarily
> large and
> all-encompassing PKI to function properly.  Unfortunately this doesn't
> take
> into account two very common cases:
	This is because - X.509 is part of a directory authentication
framework that by defintion relies on and is defined by X.500 directory
based information objects and attributes -  that must exist  in a named
hierarchy - ie 509 relates to the authentication framework of an X.500
distributed directory information model that contains attributes (and
objects) that add security and trust mechanisms (CAs PKIs and Certs) etc
to this. 

	 
> 1. Two parties who have an established trust relationship and want to
> share
>    keys.  This is a very common case for businesses who would
> typically have
>    existing bilateral trading arrangements and neither require, nor
> care for,
>    an external (or internal) CA.  Keys for the other party would be
> held as
>    part of the standard account records maintained by both sides,
> which would
>    also contain information such as account balance information
> required for
>    standard business practices).  Simply registering the other parties
> public
>    key in the account record represents the easiest and most reliable
> way of
>    managing the public key, whereas using a third-party certificate
> requires
>    complex certificate handling, reliance on a third-party CRL, and
> the
>    creation of an unnecessary parallel trust infrastructure which adds
> nothing
>    (apart from complexity) to the existing trust mechanism.
> 
>    A typical example of this would be users who are submitting
> electronic tax
>    returns: The tax department knows who its "customers" are, and
> *everyone*
>    knows who the tax department is.  A CA doesn't even fit into this
> model.
> 
	So this is bi lateral - mutual out of band trust relationship  -
it is not directory based - PKI trust model.

	This is like arguing that a ship is not a car !

	However, most tax departments have done it this old way for the
last 2000 years - but now they are adopting PKI...

> 2. An end entity who has a CA-certified authentication cert and wants
> to use it
>    to issue their own confidentiality keys.  If an end entity has an
>    authentication cert then there's no real need for CA-issued
> confidentiality
>    certs, especially since this grants the end entity a far greater
> degree of
>    control over their keys.  For example the end entity might wish to
> roll over
>    their confidentiality keys once a month, a prudent security
> precaution which
>    could end up bankrupting them if it were attempted with
> CA-certified keys.
> 
	Again this does not reflect a natural hierachy of trust - or the
logic of what a CA or EE is.. ie an EE is just that and End Entity and
its certificate by definition cannot be used to verify issue or
certificates..
	Why debate that something which is identified at the end of the
line cannot do something which can only be done by something within the
line!

	 All one needs to make this work is make the entity that wants
to manage its own confidentiality keys NOT and end entity - ie a CA
function because it generates its own certs - it is by definition a CA
function..

	A CA is represented by additional attributes of a directory
object...


> Unfortunately both of these items, while perfectly sensible, represent
> a
> paradox for X.509, since a certificate is incapable of representing
> them:
> There's no way to create a standalone end-entity certificate
> containing a
> public key, and there's no way for an end entity to create/certify
> their own
> confidentiality keys.
> 
	There is no paradox for X.509 - there are just flaws in the
logic presented.

	snip

	If one wnats to build a PKI system as represented by an X.509
model in the context of a distributed directory service - everything
works
	If one throws away the directory information model and the
hierarchical rules of trust and CA functions identification that are
assigned to that directory model , etc  and create unrealistic
situations outside that - and then say these are flaws - IMHO the debate
is strange..

	I use my boat on the sea and my car on the roads - I understand
the modelling and engineering of these items to the extent that if  I
reverse their usage - nothing works - and costs me heaps :-)

	regards alan


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27985 for ietf-pkix-bks; Tue, 8 Jun 1999 15:53:24 -0700 (PDT)
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 PAA27981 for <[e-mail]>; Tue, 8 Jun 1999 15:53:22 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA20185; Tue, 8 Jun 1999 18:55:07 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a03b38342d21a49@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <v04020a0db38325216509@[128.89.0.110]>
Date: Tue, 8 Jun 1999 18:01:33 -0400
To: Ben Laurie <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ben,
>Stephen Kent wrote:
>>
>> Ben,
>>
>> >
>> >??? If I HMAC then DH the result, isn't that a signature?
>>
>> No, encrypting a hash (I assumed you meant a hash, not HMAC)
>
>Sorry, yes, I do, of course.
>
>> for
>> verification by a specified entity (the entity whose public key was an
>> input to the DH computation you performed) isn't a signature.
>
>I encrypt the hash with my private key, of course, not someone else's
>public key.

NYou don't encrypt anything with a D-H private key or public key.  Use use
your private key and someone else's public key to generate a shared secret
value, which can then be used as a symmetric key for encryption) or as an
input to a symmetric authentication algorithm (e.g., HMAC).

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA25943 for ietf-pkix-bks; Tue, 8 Jun 1999 15:13:15 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA25939 for <[e-mail]>; Tue, 8 Jun 1999 15:13:14 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id PAA16205; Tue, 8 Jun 1999 15:13:30 -0700 (PDT)
Received: from rhone (dhcp-3-128.engineering.valicert.com [192.168.3.128]) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id PAA29966; Tue, 8 Jun 1999 15:14:33 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, <[e-mail]>
Subject: RE: Possible clarification to RFC 2459
Date: Tue, 8 Jun 1999 15:17:06 -0700
Message-ID: <000001beb1fc$a5700710$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Dave,
    Here is the specific issue that I am facing. We have an OCSP
responder that can, among other methods, get information about what
certs are revoked from a CA using CRLs. I need to know if the CA
is sending me parts of a CRL or a full CRL. Want to be able to
distinguish between the two based on the CRL itself.

    Another problem is the case where a CA produces both full
and partial CRLs. If I as an application have the full CRL, I don't
need to look at the partial CRLs to validate a cert. In that
case, how can I know that I have the full CRL.

Hope this clarifies the reasons behind the question.

Regards,
Ambarish

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


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]On Behalf
> Of David P. Kemp
> Sent: Tuesday, June 08, 1999 12:30 PM
> To: [e-mail]
> Subject: RE: Possible clarification to RFC 2459
> 
> 
> 
> > From: Tom Biskupic <[e-mail]>
> > To: "'Ambarish Malpani'" <[e-mail]>
> > Cc: "[e-mail]" <[e-mail]>, "'Tom Biskupic'" 
> <[e-mail]>, "'Ietf-Pkix (E-mail)'" 
> <[e-mail]>, "'Alex 
> Deacon'" <[e-mail]>
> Tom,
>   As you say, the presence of an IDP extension (with onlyUserCerts,
> onlyCACerts, and onlySomeReasons all absent) in the CRL does 
> not indicate
> whether the CRL covers every cert issued by the CA or only some certs.
> A CA's CRLs could, for example, be partitioned by serial number, or by
> the phase of the moon at the start of the certificate's 
> validity, or at
> random.
> 
> But why is that a problem?  If you have a cert with CrlDP, 
> then you can
> determine the revocation status of that cert unambiguously without
> needing to know whether the CRL is full or partial.  That is 
> a feature,
> not a bug, because it allows CAs to do dynamic partitioning.
> 
> If you have a set of certs without CrlDP, then the CA has 
> chosen not to
> partition those certs in a manner that can't be described in the IDP,
> and the status of any particular cert is still unambiguous.
> 
> Why do people feel it is necessary or desirable to know 
> whether a given
> CRL is full or partial?  The only question that must be answered is
> whether a CRL or set of CRLs is complete with respect to a given
> certificate.  RFC 2459 already satisfies that requirement.  Any
> "clarification" to RFC 2459 that would prevent a CA from issuing new
> certs under a different CRL than existing certs is undesirable.
> 
> Dave Kemp
> 
> 
> 
> > Subject: RE: Possible clarification to RFC 2459
> > Date: Tue, 8 Jun 1999 19:06:44 +0100
> > 
> > Ambarish,
> > 
> > Yes I understand what you are saying. Yes as I said you 
> could argue (and in 
> > fact you did) that in the case where you have a CRL/ARL 
> split the presence 
> > of an IDP does indicate the CRL has been partitioned but I 
> am saying there 
> > is no way to tell if the CRL has been split in other ways.
> > 
> > The issue is based on my assumption that there will be many 
> systems that 
> > split a CRL into a CRL and ARL but few that split further. If a CRL 
> > containing a IDP is encountered which has the 
> 'onlyContainsUserCerts' 
> > optional flag (which we believe is a common occurence) 
> there is no way to 
> > tell if the set of revoked certificates has been 
> partitioned further or if 
> > this is the only split criteria. Ok strictly speaking the 
> CRL is split but 
> > in this case that's not very useful as what you really want 
> to know is 
> > where to go to check the validity of the (usually) end user 
> certificate you 
> > are holding.
> > 
> > A more serious problem occurs in the second case I highlighted - an 
> > organisation has no directory service (ie an LDAP server) so they 
> > distribute their CRLs through a URI. Every issued 
> certificate (maybe even 
> > including CA certificates) contains a CDP extension 
> pointing at this URI. A 
> > complete CRL is posted to that location every day. In this case the 
> > presence of an IDP extension in the CRL does not indicate a 
> partial CRL. 
> > Essentially the lack of an IDP implies a full CRL but the 
> presence of an 
> > IDP may not indicate a partial CRL.
> > 
> > Where does that get us? Hmm I'm not sure.
> > 
> > Tom Biskupic
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA24882 for ietf-pkix-bks; Tue, 8 Jun 1999 14:47:41 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA24878 for <[e-mail]>; Tue, 8 Jun 1999 14:47:40 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id RAA17087; Tue, 8 Jun 1999 17:49:27 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id RAA17083; Tue, 8 Jun 1999 17:49:27 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id RAA03264; Tue, 8 Jun 1999 17:49:30 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id RAA14630; Tue, 8 Jun 1999 17:46:54 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 8 Jun 1999 17:46:54 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Certificate requests for encryption keys
To: [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: RWtuNdrQrionx5PCV03saA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bill,

I believe your first sentence contains the answer:  what you want is
a "signed" encryption key, not a "certified" encryption key.

If there is a need for long-term encryption keys certified by a third
party, then an X.509 certificate is the appropriate structure to
represent them.  But if there is a need for rapidly updated public
key-establishment keys, or no need for a third party to be involved in
certifying a longer term key establishment key, then why would one
choose to use an X.509 certificate in the first place?

As Steve pointed out, IKE (the IPSEC Internet Key Exchange protocol)
supports PFS.  I would also point out that TLS defines an Ephemeral DH
exchange using (by definition) non-certified public keys.

CMS (S/MIME) requires X.509 certificates for encryption because there
is no requirement for an envelopedData structure to be wrapped within
a signedData structure, thus the certificates used with envelopedData
must support both encryption and authentication.  But a hypothetical
non-S/MIME protocol could profile a mandatory wrapping of CMS
envelopedData within a signedData, and define a publicKeyInfo attribute
to hold the naked encryption key, eliminating the need for
X.509 authenticated-encryption certificates.

I believe the lack of sympathetic response to the suggestion of
EE-issued X.509 encryption certificates is well deserved.  Using an
X.509 Certificate structure to represent a non-third-party-certified
EE-signed public key-establishment key is like driving a screw with a
hammer.  You could do it, but why would you want to?

Dave Kemp



> From: Bill Burr <[e-mail]>
> Subject: Re: Certificate requests for encryption keys
> 
> Anne,
> 
> Your line of reasoning has always made sense to me.  If you can validate my
> signature, why wouldn't you trust me to sign my own encryption key?
> 
> Nevertheless, when I have mentioned the idea that end entities could
> self-sign encryption certificates, I don't think I've ever received a
> sympathetic response.  I think I've heard 3 arguments against self-signed
> encryption certificates:
> 
> 1. How can I revoke my self-signed encryption certificate except by
> revoking my signature certificate?  Relatively short lifetime encryption
> certificates would be at least a partial answer.
> 
> 2. How can the relying party know I truly have the private key?   But why
> do we need POP in this case?  I at least have never understood what the
> danger is to a relying party if I claim to own an encryption key I don't have.
> 
> 3. Such a system would make it hard to enforce a systematic data recovery
> discipline.   
> 
> Of course a practical objection is that X.509 type systems today just
> aren't set up to do it. In particular, the validation software would have
> to ensure that an end entity could only sign an encryption certificate for
> the same name.  We're really talking about something that goes a bit beyond
> X.509, I suppose.  I think the model of a self-signed encryption
> certificate is a fairly good one, but it's not quite what X.509 apparently
> contemplates.
> 
> Bill Burr



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA24675 for ietf-pkix-bks; Tue, 8 Jun 1999 14:43:49 -0700 (PDT)
Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA24671 for <[e-mail]>; Tue, 8 Jun 1999 14:43:48 -0700 (PDT)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id VAA02692; Tue, 8 Jun 1999 21:30:20 GMT
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id WAA29309; Tue, 8 Jun 1999 22:29:15 +0100
Message-ID: <[e-mail]>
Date: Tue, 08 Jun 1999 22:28:50 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Keith Brady <[e-mail]>, [e-mail]
Subject: Re: Certificate requests for encryption keys
References: <[e-mail]> <v04020a0db38325216509@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:
> 
> Ben,
> 
> >
> >??? If I HMAC then DH the result, isn't that a signature?
> 
> No, encrypting a hash (I assumed you meant a hash, not HMAC)

Sorry, yes, I do, of course.

> for
> verification by a specified entity (the entity whose public key was an
> input to the DH computation you performed) isn't a signature.

I encrypt the hash with my private key, of course, not someone else's
public key.

Cheers,

Ben.

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

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA24470 for ietf-pkix-bks; Tue, 8 Jun 1999 14:32:34 -0700 (PDT)
Received: from xeti.com ([208.163.59.141]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA24465 for <[e-mail]>; Tue, 8 Jun 1999 14:32:33 -0700 (PDT)
Received: from pacific.xeti.com by xeti.com (SMI-8.6/SMI-SVR4) id OAA13373; Tue, 8 Jun 1999 14:32:18 -0700
Received: (from hemma@localhost) by pacific.xeti.com (8.8.8+Sun/8.8.8) id OAA12383; Tue, 8 Jun 1999 14:39:13 -0700 (PDT)
Date: Tue, 8 Jun 1999 14:39:13 -0700 (PDT)
From: Hemma Prafullchandra <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail], [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> One can do the same with PKCS#10 though you miss the option to use POP.

For pkcs#10 based DH public key certification please look at
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-00.txt

We'll be publishing an update soon with some examples.

Hemma


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA22562 for ietf-pkix-bks; Tue, 8 Jun 1999 13:25:21 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA22558 for <[e-mail]>; Tue, 8 Jun 1999 13:25:20 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 8 Jun 1999 20:25:13 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA01070; Tue, 8 Jun 1999 16:23:46 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2232.9) id <M307HJ9L>; Tue, 8 Jun 1999 16:28:14 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Bob Blakley'" <[e-mail]>, Denis Pinkas <[e-mail]>, Stephen Farrell <[e-mail]>
Cc: [e-mail]
Subject: RE: attribute encryption (was: Re: X.509 ACs vs. SPKI?)
Date: Tue, 8 Jun 1999 16:31:09 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Stephen's earlier comments supporting the inclusion of an
encrypted attribute facility, which is explicitly excluded from ac509prof's
basic conformance level.  While attribute encryption (like PKIs generally)
introduces infrastructure requirements, it also allows valuable functions
unavailable otherwise. Can we navigate this argument by retaining the
definition of encrypted attributes, but separating any conformance
requirements therefor from conformance to other aspects of the
"proxy-enabled tier"?  I can envision non-proxy cases where encrypted
attributes would be useful, and proxy cases where they wouldn't be
necessary. 

--jl

> -----Original Message-----
> From: Bob Blakley [mailto:[e-mail]]
> Sent: Tuesday, June 08, 1999 2:53 PM
> To: Denis Pinkas; Stephen Farrell
> Cc: [e-mail]
> Subject: Re: attribute encryption (was: Re: X.509 ACs vs. SPKI?)
> 
> 
> Denis Pinkas writes:
> 
> >The complexity lies in the fact that to encrypt a field the 
> public key of the
> target is
> >needed. This places an additional constraint in terms of key 
> management: this
> mandates
> >targets to possess public encryption keys while ACs may work 
> without the
> target to have
> >such keys and certificates. This "doubles" the complexity. I 
> would like AC to
> be
> >deployable without the need for targets to possess any 
> private key, which is
> possible as
> >long as attributes are in clear text.
> 
> I fear the added complexity much more than doubles....
> 
> >To be very precise, I would like a basic document NOT 
> supporting encrypted
> attributes.
> >If you think it is very important, then make a *separate* 
> document so that I
> can refer
> >to one (simple) RFC and so that I comply with it without any 
> need/requirement
> for
> >supporting encrypted attributes and the related infrastructure.
> 
> I agree with Denis here.
> 
> --bob
> 
> Bob Blakley ([e-mail])
> Chief Scientist, Dascom
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA22514 for ietf-pkix-bks; Tue, 8 Jun 1999 13:21:05 -0700 (PDT)
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 NAA22510 for <[e-mail]>; Tue, 8 Jun 1999 13:21:01 -0700 (PDT)
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 IAA30740 for <[e-mail]>; Wed, 9 Jun 1999 08:22:45 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92887336500345>; Wed, 9 Jun 1999 08:22:45 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Certificate requests for encryption keys
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 9 Jun 1999 08:22:45 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anne Anderson - Sun Microsystems <[e-mail]> writes:

>I would like to see any Subject, including an End-Entity, be able to issue
>certificates for encryption keys (and possibly other types as well).

I proposed this some time ago, but there didn't seem to be any interest in it.
Here's the message from last time...

Peter.

-- Snip --

Current X.509 profiles all require the presence of an arbitrarily large and
all-encompassing PKI to function properly.  Unfortunately this doesn't take
into account two very common cases:

1. Two parties who have an established trust relationship and want to share
   keys.  This is a very common case for businesses who would typically have
   existing bilateral trading arrangements and neither require, nor care for,
   an external (or internal) CA.  Keys for the other party would be held as
   part of the standard account records maintained by both sides, which would
   also contain information such as account balance information required for
   standard business practices).  Simply registering the other parties public
   key in the account record represents the easiest and most reliable way of
   managing the public key, whereas using a third-party certificate requires
   complex certificate handling, reliance on a third-party CRL, and the
   creation of an unnecessary parallel trust infrastructure which adds nothing
   (apart from complexity) to the existing trust mechanism.

   A typical example of this would be users who are submitting electronic tax
   returns: The tax department knows who its "customers" are, and *everyone*
   knows who the tax department is.  A CA doesn't even fit into this model.

2. An end entity who has a CA-certified authentication cert and wants to use it
   to issue their own confidentiality keys.  If an end entity has an
   authentication cert then there's no real need for CA-issued confidentiality
   certs, especially since this grants the end entity a far greater degree of
   control over their keys.  For example the end entity might wish to roll over
   their confidentiality keys once a month, a prudent security precaution which
   could end up bankrupting them if it were attempted with CA-certified keys.

Unfortunately both of these items, while perfectly sensible, represent a
paradox for X.509, since a certificate is incapable of representing them:
There's no way to create a standalone end-entity certificate containing a
public key, and there's no way for an end entity to create/certify their own
confidentiality keys.

The reason a standalone end-entity certificate can't exist is that it has to be
signed by a CA, but an end entity is by definition not a CA and therefore can't
do this.  A workaround is for the end entity to create a pseudo-CA certificate
whose only task is to sign other certificates, but all this does is add
unnecessary complexity.

The reason an end-entity certified confidentiality key can't exist is again
because an end entity isn't a CA, and again because there's no way to specify
this in a certificate.  It's possible to make the end entity a CA with a path
length of zero and a name constraint which only allows them to issue certs to
entities below them, but this isn't what's required, and it's unlikely that
current CA's will agree to turn each of their users into mini-CA's.

To solve the first problem, we require a means of specifying that the
certificate is a standalone self-signed end-entity certificate.  Unfortunately
this can't be done with X.509, the best we can do is add a special-purpose
extKeyUsage which notifies the relying party of this.  The certificate has the
usage-related attributes set as follows:

  basicConstraints.cA = FALSE
  keyUsage = as usual, cert/crlSign bits not set
  extKeyUsage = selfSignedEndEntity

A problem with this is that certificates with the issuerName = subjectName are
regarded by a lot of software as self-signed CA root certs, so in addition to
this the issuer CN must be set to 'Owner-issued certificate'.  This isn't used
for identification purposes but to ensure that the certificate can't be
mistaken for a conventional self-signed one, which would be treated as a CA
root cert.

To solve the second problem we require two things, a means of specifying that
the certificate is an end-entity confidentiality-key-issuing cert, and a means
of handling confidentiality key rollover.  The confidentiality-key-issuing cert
has the usage-related attributes set as follows:

  basicConstraints.cA = FALSE
  keyUsage = certSign set, others set as required
  extKeyUsage = endEntityIssuingCert

A cert with this key usage has an implicit name constraint which requires that
the subject/issuer DN of the confidentiality cert be the same as the subject DN
of the c-k-i cert.  This is required in order to avoid the c-k-i cert being
able to act as a general-purpose CA.  We can't use an explicit name constraint
because they're not allowed in end-entity certs, and in any case all we can
constrain with this is a subtree, not a fixed name.

The key rollover problem is solved by having a 'supersedes' extension in the
confidentiality cert which contains a unique identifier.  The sender takes the
most recent certificate containing this identifier and uses it to communicate
with the cert owner.  Note that the identifier can't be something like the
authorityKeyIdentifier, since (a) this could change over time, and (b) these
again aren't allowed to be present in end-entity certificates.

The intended application of confidentiality key rollover is as follows:

The cert owner communicates the c-k-i cert and confidentiality key cert to the
other party in the usual manner (eg as part of an S/MIME cert chain).  The
other parties softwware records the supersedes identifier and, when it wants to
communicate with the cert owner, takes the most recent cert with that identifer
and uses it for the confidentiality key.  The cert owner can roll over their
key by including a new confidentiality cert in their mail to the other party at
any time.

If the two parties don't communicate very often, it may occur that the other
party only has expired confidentiality certs.  In this case they can use a
long-term fallback cert for the first exchanged message to bootstrap
communications, after which they'll obtain the latest confidentiality cert in
the reply to their mail.

This use of end-entity certified confidentiality keys allows perfect forward
(and backward) secrecy (keys can be rolled over on a per-message basis if
required) which is completely transparent to the user, as well as doing away
with the need for the (unnecessary) reliance on a CA for certification of
confidentiality keys.  Note that this doesn't diminish the CA's business, since
they're still required to issue the authentication certificate, which will
expire after a set time and require renewal as usual.  It makes no difference
to their bottom line whether the CA issues a single long term cert or a
single-long term cert with the ability to issue many short-term certs, in both
cases they get paid for the one cert.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA22292 for ietf-pkix-bks; Tue, 8 Jun 1999 13:19:26 -0700 (PDT)
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 NAA22288 for <[e-mail]>; Tue, 8 Jun 1999 13:19:24 -0700 (PDT)
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 QAA08498; Tue, 8 Jun 1999 16:21:21 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 08 Jun 1999 16:23:02 -0400
To: Anne Anderson - Sun Microsystems <[e-mail]>, <[e-mail]>
From: Bill Burr <[e-mail]>
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail]
In-Reply-To: <14173.22785.901159.86568@saguaro>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anne,

Your line of reasoning has always made sense to me.  If you can validate my
signature, why wouldn't you trust me to sign my own encryption key?

Nevertheless, when I have mentioned the idea that end entities could
self-sign encryption certificates, I don't think I've ever received a
sympathetic response.  I think I've heard 3 arguments against self-signed
encryption certificates:

1. How can I revoke my self-signed encryption certificate except by
revoking my signature certificate?  Relatively short lifetime encryption
certificates would be at least a partial answer.

2. How can the relying party know I truly have the private key?   But why
do we need POP in this case?  I at least have never understood what the
danger is to a relying party if I claim to own an encryption key I don't have.

3. Such a system would make it hard to enforce a systematic data recovery
discipline.   

Of course a practical objection is that X.509 type systems today just
aren't set up to do it. In particular, the validation software would have
to ensure that an end entity could only sign an encryption certificate for
the same name.  We're really talking about something that goes a bit beyond
X.509, I suppose.  I think the model of a self-signed encryption
certificate is a fairly good one, but it's not quite what X.509 apparently
contemplates.

Bill Burr

At 02:23 PM 6/8/99 -0400, Anne Anderson - Sun Microsystems wrote:
>I would like to see any Subject, including an End-Entity, be able to 
>issue certificates for encryption keys (and possibly other types as
>well).
>
>Justification:
>
>1. CAs have the task of certifying identity.  There does not need to
>   be a new identity certification in certifying keys other than
>   those used for certifying or verifying identity.
>
>2. End-Entities may need to change encryption keys frequently.  Many 
>   CAs are not designed for frequent updates.
>
>3. A CA can still have a policy of not signing end-entity
>   certificates that allow certification of non-identity keys, if
>   that CA wants to certify all end-entity keys.
>
>4. A verifier can still have a policy of not accepting end-entity
>   certificates that are used to certify non-identity keys, if that
>   verifying wants a "CA" to verify all keys.
>
>5. It is generally simpler for an End-Entity to manage the
>   certificates used for purposes other than identity.
>
>So REQUIRING non-identity keys to be certified by a CA seems to rule 
>out reasonable and useful models for the use of certificates.
>
>Supporting this model will require agreement on what combination of
>BasicConstraints values and KeyUsage values are permitted in
>certification paths.
>
>One way to do this follows:
>
>End-Entities could be issued certificates by a CA for keys with
>KeyUsage of keyCertSign, but certification paths would accept these
>keys only when used to sign certificates for the same End-Entity
>where keyUsage is digitalSignature, nonRepudiation?,
>keyEncipherment, dataEncipherment, or keyAgreement.
>
>Example:
>
>Certificate 1:
>   Issuer:  X
>   Subject: Y
>   SubjectPublicKey: <Y's keyCertSign key>
>   BasicConstraints: CA
>   KeyUsage: keyCertSign
>   Signed by: <X's keyCertSign key>
>
>Certificate 2:
>   Issuer: Y
>   Subject: Z
>   SubjectPublicKey: <Z's keyCertSign key>
>   BasicConstraints: EE
>   KeyUsage: keyCertSign
>   Signed by: <Y's keyCertSign key>
>
>Certificate 3:
>   Issuer: Z
>   Subject: Z
>   SubjectPublicKey: <Z's keyEncipherment key>
>   KeyUsage: keyEncipherment
>   Signed by: <Z's keyCertSign key>
>
>Other solutions include a new KeyUsage type corresponding to
>"keyCertSign", but used only for End-Entities.
>
>Anne Anderson
>-- 
>Anne H. Anderson  ECI#712-KC Email: [e-mail]
>Sun Microsystems Laboratories   or: [e-mail]
>1 Network Drive,UBUR02-311     Tel: [phone]
>Burlington, MA 01803-0902 USA  Fax: [phone]
>
>
Regards,

Bill Burr


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21631 for ietf-pkix-bks; Tue, 8 Jun 1999 13:05:01 -0700 (PDT)
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 NAA21626 for <[e-mail]>; Tue, 8 Jun 1999 13:05:00 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA25678; Tue, 8 Jun 1999 16:06:37 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0db38325216509@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 8 Jun 1999 15:55:54 -0400
To: Ben Laurie <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate requests for encryption keys
Cc: Keith Brady <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ben,

>
>??? If I HMAC then DH the result, isn't that a signature?

No, encrypting a hash (I assumed you meant a hash, not HMAC) for
verification by a specified entity (the entity whose public key was an
input to the DH computation you performed) isn't a signature.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21627 for ietf-pkix-bks; Tue, 8 Jun 1999 13:05:00 -0700 (PDT)
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 NAA21621 for <[e-mail]>; Tue, 8 Jun 1999 13:04:58 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA25669; Tue, 8 Jun 1999 16:06:35 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0cb383242e2bf8@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Tue, 8 Jun 1999 15:52:48 -0400
To: "Brian M. Thomas" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Brian,

An EE's assertion about binding any key (encryption or signature) to
itself, in the form of a self-signed cert, says little from a security
perspective.  What we are discussing here is whether an EE with an existing
signature key should use it to issue certs for encryption keys.  Yes, one
can do that, but it adds more complexity to key management.  For some apps,
e.g., S/MIME, one wamnts a long term encryption key, for the purposes I
mentioned in my note to Anne.  If there are other Internet applications
that need shorter duration encryption, but not authentication, keys, then
the PKIX WG needs to hear a good description of them, to warrant
appropriate accommodation in our standards.  Note that in places where PFS
is a goal, one can avoid the need for certs entirely for encryption
purposes, e.g., IKE.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA21117 for ietf-pkix-bks; Tue, 8 Jun 1999 12:44:58 -0700 (PDT)
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 MAA21113 for <[e-mail]>; Tue, 8 Jun 1999 12:44:56 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA21645; Tue, 8 Jun 1999 15:46:41 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0bb3832332f0c9@[128.89.0.110]>
In-Reply-To: <14173.22785.901159.86568@saguaro>
References: <[e-mail]> <[e-mail]>
Date: Tue, 8 Jun 1999 15:47:53 -0400
To: Anne Anderson - Sun Microsystems <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate requests for encryption keys
Cc: <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anne,

Certs with keys used only for encryption, vs. signing, are still bound to
an identity in the X.509 world.  For exmaple, in S/MIME, one uses such a
key to encrypt a message (more precisely the CEK for the message) for a
specified recipient.  Thus, the sender relies on a CA to have verified the
subject name in that encryption-only cert.  So, I don't think your
characterization of when identity verification is important in signature
vs. encryption certs is a good one.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20908 for ietf-pkix-bks; Tue, 8 Jun 1999 12:31:16 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20904 for <[e-mail]>; Tue, 8 Jun 1999 12:31:14 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA03856 for <[e-mail]>; Tue, 8 Jun 1999 15:33:02 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA03849 for <[e-mail]>; Tue, 8 Jun 1999 15:33:02 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA01732 for <[e-mail]>; Tue, 8 Jun 1999 15:33:05 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id PAA14521 for <[e-mail]>; Tue, 8 Jun 1999 15:30:29 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 8 Jun 1999 15:30:29 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Possible clarification to RFC 2459
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: y74nESrS+PQzFJdTrIxSzg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: Tom Biskupic <[e-mail]>
> To: "'Ambarish Malpani'" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "'Tom Biskupic'" 
<[e-mail]>, "'Ietf-Pkix (E-mail)'" <[e-mail]>, "'Alex 
Deacon'" <[e-mail]>
Tom,
  As you say, the presence of an IDP extension (with onlyUserCerts,
onlyCACerts, and onlySomeReasons all absent) in the CRL does not indicate
whether the CRL covers every cert issued by the CA or only some certs.
A CA's CRLs could, for example, be partitioned by serial number, or by
the phase of the moon at the start of the certificate's validity, or at
random.

But why is that a problem?  If you have a cert with CrlDP, then you can
determine the revocation status of that cert unambiguously without
needing to know whether the CRL is full or partial.  That is a feature,
not a bug, because it allows CAs to do dynamic partitioning.

If you have a set of certs without CrlDP, then the CA has chosen not to
partition those certs in a manner that can't be described in the IDP,
and the status of any particular cert is still unambiguous.

Why do people feel it is necessary or desirable to know whether a given
CRL is full or partial?  The only question that must be answered is
whether a CRL or set of CRLs is complete with respect to a given
certificate.  RFC 2459 already satisfies that requirement.  Any
"clarification" to RFC 2459 that would prevent a CA from issuing new
certs under a different CRL than existing certs is undesirable.

Dave Kemp



> Subject: RE: Possible clarification to RFC 2459
> Date: Tue, 8 Jun 1999 19:06:44 +0100
> 
> Ambarish,
> 
> Yes I understand what you are saying. Yes as I said you could argue (and in 
> fact you did) that in the case where you have a CRL/ARL split the presence 
> of an IDP does indicate the CRL has been partitioned but I am saying there 
> is no way to tell if the CRL has been split in other ways.
> 
> The issue is based on my assumption that there will be many systems that 
> split a CRL into a CRL and ARL but few that split further. If a CRL 
> containing a IDP is encountered which has the 'onlyContainsUserCerts' 
> optional flag (which we believe is a common occurence) there is no way to 
> tell if the set of revoked certificates has been partitioned further or if 
> this is the only split criteria. Ok strictly speaking the CRL is split but 
> in this case that's not very useful as what you really want to know is 
> where to go to check the validity of the (usually) end user certificate you 
> are holding.
> 
> A more serious problem occurs in the second case I highlighted - an 
> organisation has no directory service (ie an LDAP server) so they 
> distribute their CRLs through a URI. Every issued certificate (maybe even 
> including CA certificates) contains a CDP extension pointing at this URI. A 
> complete CRL is posted to that location every day. In this case the 
> presence of an IDP extension in the CRL does not indicate a partial CRL. 
> Essentially the lack of an IDP implies a full CRL but the presence of an 
> IDP may not indicate a partial CRL.
> 
> Where does that get us? Hmm I'm not sure.
> 
> Tom Biskupic



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20368 for ietf-pkix-bks; Tue, 8 Jun 1999 12:13:50 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20364 for <[e-mail]>; Tue, 8 Jun 1999 12:13:48 -0700 (PDT)
Received: by puma.baltimore.ie; id UAA15713; Tue, 8 Jun 1999 20:54:40 +0100 (GMT/IST)
Received: from ocelot.baltimore.ie(10.49.0.10) by puma.baltimore.ie via smap (4.1) id xma015708; Tue, 8 Jun 99 20:54:36 +0100
Received: from sage.baltimore.ie ([e-mail] [10.49.0.139]) by ocelot.baltimore.ie (8.8.7/8.8.5) with ESMTP id UAA15682; Tue, 8 Jun 1999 20:15:30 +0100
Received: from sage.baltimore.ie (IDENT:keith@localhost [127.0.0.1]) by sage.baltimore.ie (8.9.3/8.9.3) with ESMTP id UAA06664; Tue, 8 Jun 1999 20:15:29 +0100
Message-Id: <[e-mail]>
To: Ben Laurie <[e-mail]>
cc: [e-mail]
Subject: Re: Certificate requests for encryption keys 
Date: Tue, 08 Jun 1999 20:15:29 +0100
From: Keith Brady <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> ??? If I HMAC then DH the result, isn't that a signature?

Um, not at all sure I understand you here. Don't we need a pre-agreed key
for the HMAC? I trust you mean hash. Not all encryption algorithms are
designed such that this is the ideal way to use them.

In any case I believe we are talking about El-Gamal rather than Key
Exchange D-H. In the general case, it is (I think) possible to construct
encryption algorithms where the hybrid approach (encrypted hash) doesn't
work. I did read something on this a good while ago but I can't remember
where.

cheers,

Keith


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20169 for ietf-pkix-bks; Tue, 8 Jun 1999 12:08:58 -0700 (PDT)
Received: from swbcs005.sbc.com (swbcs005.sbc.com [209.184.192.25]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20164 for <[e-mail]>; Tue, 8 Jun 1999 12:08:56 -0700 (PDT)
Received: from swgate1.sbc.com (swgate1.sbc.com [132.201.82.89]) by swbcs005.sbc.com (8.8.8/8.8.8) with SMTP id OAA13514 for <[e-mail]>; Tue, 8 Jun 1999 14:10:36 -0500 (CDT)
Received: by swgate1.sbc.com (Smail-3.2 1996-Jul-4 #6 built 1997-Dec-24) id <[e-mail]>; Tue, 8 Jun 1999 13:49:26 -0500 (CDT)
Received: from entropy.sbc.com(really [132.201.211.237]) by swgate1.sbc.com via sendmail with smtp id <[e-mail]> for <[e-mail]>; Tue, 8 Jun 1999 13:48:59 -0500 (CDT)
Received:  by entropy.sbc.com (8.7.1/25-eef) id NAA01657; Tue, 8 Jun 1999 13:48:58 -0500 (CDT)
Date: Tue, 8 Jun 1999 13:48:58 -0500 (CDT)
From: "Brian M. Thomas" <[e-mail]>
X-Full-Name: Brian M. Thomas
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Certificate requests for encryption keys
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

An EE's assertion is both necessary and sufficient to bind an
encryption key to itself.  There is therefore neither need nor
justification for a CA's involvement.  As to someone else's
authorization to use that key for encryption (as in key recovery
scenarios) that is another matter, and only meaningful if the CA is
also the authority (e.g.  employer) authorizing it to be used for that
purpose.

brian

Brian Thomas, CISSP - Distributed Systems Architect  [e-mail]
Southwestern Bell                                    [e-mail]
One Bell Center,  Room 34G3                          Tel: [phone]
St. Louis, MO 63101                                  Fax: [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA19940 for ietf-pkix-bks; Tue, 8 Jun 1999 12:00:49 -0700 (PDT)
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 MAA19933 for <[e-mail]>; Tue, 8 Jun 1999 12:00:48 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id MAA14068; Tue, 8 Jun 1999 12:01:49 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 08 Jun 1999 12:01:18 -0700
To: Ed Gerck <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
Cc: PKIX <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 01:17 AM 6/8/99 -0700, Ed Gerck wrote:
>
>
>Tony Bartoletti wrote:
>
>> The given formula "works" (assuming all component attributes have identical
>> lifetimes.)
>
>Tony:
>
>I can't understand the "works" -- do you find a mistake in the results?
>
>> I wanted to explore the more general case, where the component lifetimes
>> are unequal, and to help define "degrees of redundancy".
>>
>> A simple (?) example:
>>
>>   Consider a certificate C over two attributes A and B with lifetimes given
>>   by TA and TB, respectively.
>>
>>   Assuming no redundancy, we allow 1/TC = 1/TA + 1/TB.
>
>You mean, there is no 100% redundancy? Because redundancy is NOT
>a problem in the equation -- as I showed in my e-mail anterior and
>you recognized when you wrote above "works" ;-))))
>
>Of course, you cannot just *repeat* the *same* attribute two times
>and expect that you have two attributes, in fact you would just one
>attribute, no?

At this point, we cannot tell from inspection whether A and B have any
components which are themselves 100% redundant.  In any case, A and B
are not 100% redundant.

>>   Suppose, upon closer inspection, we agree that attributes A and B are
>>   themselves formed of components.  Specifically:
>>
>>         A = a1 and a2 and a3  (respective lifetimes Ta1, Ta2, Ta3)
>>         B = b1 and b2 and b3  (respective lifetimes Tb1, Tb2, Tb3)
>>
>>   Note:  Attribute A is valid IFF all of a1, a2, a3 are valid, etc.
>>
>>   Continuing under assumptions of no redundancy, we still find
>>
>>         1/TC = 1/TA + 1/TB
>>              = 1/Ta1 + 1/Ta2 + 1/Ta3 + 1/Tb1 + 1/Tb2 + 1/Tb3
>
>You "forgot" to impose the conditions, derived directly by your
>hypothesis:
>
>1/TA = 1/Ta1 + 1/Ta2 + 1/Ta3
>1/TB = 1/Tb1 + 1/Tb2 + 1/Tb3

If I did not impose these conditions, how could I have made the 
direct substitution in the equation for 1/TC above?

>>   Suppose a "final investigation" reveals that the components a1 and a2 of A
>>   are precisely the components b1 and b2 of B.  Thus the certificate C
>>   certifies exactly the components a1, a2, a3, b3.
>
>Your affirmation does not make mathematical sense, Tony. What do you mean by
>
>"the components a1 and a2 of A are precisely the components b1 and b2 of B."
>
>Do you mean they are equal? So what? You affirmed before that:
>
> "Assuming no redundancy, we allow 1/TC = 1/TA + 1/TB"

And I believe you maintain, in essense, that unless A and B are themselves
exactly redundant, "redundancy is not a problem in the equation."

Hence, I force A and B to be "partially redundant", and intentionally
drop the "Assuming no redundancy" to illustrate.
 
I mean that a1 is exactly redundant to b1, and a2 to b2.  They ARE the
same attributes, just repeated.  Although this does not make A and B
completely redundant, it DOES violate the original assumption, which
was exactly the point.  The formula 1/TC = 1/TA + 1/TB will not provide
the right answer, even though A and B are "different" attributes.

Unless A and B reveal their structure to us, so that we may identify
and eliminate duplicated components, we cannot apply such a formula.
And if the duplicated components [ai,bi] for some of the i, all exhibit
different expected lifetimes, there is no opportunity for the "grouping"
you mentioned, which says nothing more than SUM[C] to n terms = n*C for
a constant C.  They will be "groups of 1", and we are reduced to the
equation I gave:

  1/TC  =  1/TA + 1/TB - ( SUM[1/TCi] for ci in INTERSECT(A,B) )

The problem is in identifying this intersection, and not simply treating
attributes A and B as atoms.

___tony___
 



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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19710 for ietf-pkix-bks; Tue, 8 Jun 1999 11:50:44 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19706 for <[e-mail]>; Tue, 8 Jun 1999 11:50:43 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id NAA11286; Tue, 8 Jun 1999 13:50:30 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id NAA14710; Tue, 8 Jun 1999 13:50:29 -0500 (CDT)
Message-ID: <043101beb1e0$2d3b3c40$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stephen Farrell" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: attribute encryption (was: Re: X.509 ACs vs. SPKI?)
Date: Tue, 8 Jun 1999 13:53:19 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_042E_01BEB1B6.442B3880"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_042E_01BEB1B6.442B3880
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Denis Pinkas writes:

>The complexity lies in the fact that to encrypt a field the public key of the
target is
>needed. This places an additional constraint in terms of key management: this
mandates
>targets to possess public encryption keys while ACs may work without the
target to have
>such keys and certificates. This "doubles" the complexity. I would like AC to
be
>deployable without the need for targets to possess any private key, which is
possible as
>long as attributes are in clear text.

I fear the added complexity much more than doubles....

>To be very precise, I would like a basic document NOT supporting encrypted
attributes.
>If you think it is very important, then make a *separate* document so that I
can refer
>to one (simple) RFC and so that I comply with it without any need/requirement
for
>supporting encrypted attributes and the related infrastructure.

I agree with Denis here.

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom



------=_NextPart_000_042E_01BEB1B6.442B3880
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990608T185319Z
END:VCARD

------=_NextPart_000_042E_01BEB1B6.442B3880--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19635 for ietf-pkix-bks; Tue, 8 Jun 1999 11:48:33 -0700 (PDT)
Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19631 for <[e-mail]>; Tue, 8 Jun 1999 11:48:31 -0700 (PDT)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id SAA25719; Tue, 8 Jun 1999 18:50:04 GMT
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id TAA28659; Tue, 8 Jun 1999 19:50:26 +0100
Message-ID: <[e-mail]>
Date: Tue, 08 Jun 1999 19:50:03 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Keith Brady <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate requests for encryption keys
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Keith Brady wrote:
> 
> > I feel sure I'm going to regret asking, but why won't this work with a
> > DH key?
> 
> Because you can't sign with a D-H encryption key, it can only perform
> encryption operations.

??? If I HMAC then DH the result, isn't that a signature?

Cheers,

Ben.

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

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18964 for ietf-pkix-bks; Tue, 8 Jun 1999 11:30:50 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18959 for <[e-mail]>; Tue, 8 Jun 1999 11:30:49 -0700 (PDT)
Received: by puma.baltimore.ie; id UAA15203; Tue, 8 Jun 1999 20:11:40 +0100 (GMT/IST)
Received: from ocelot.baltimore.ie(10.49.0.10) by puma.baltimore.ie via smap (4.1) id xma015194; Tue, 8 Jun 99 20:11:11 +0100
Received: from sage.baltimore.ie ([e-mail] [10.49.0.139]) by ocelot.baltimore.ie (8.8.7/8.8.5) with ESMTP id TAA13886; Tue, 8 Jun 1999 19:32:05 +0100
Received: from sage.baltimore.ie (IDENT:keith@localhost [127.0.0.1]) by sage.baltimore.ie (8.9.3/8.9.3) with ESMTP id TAA06564; Tue, 8 Jun 1999 19:32:04 +0100
Message-Id: <[e-mail]>
To: Ben Laurie <[e-mail]>
cc: [e-mail]
Subject: Re: Certificate requests for encryption keys 
Date: Tue, 08 Jun 1999 19:32:04 +0100
From: Keith Brady <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I feel sure I'm going to regret asking, but why won't this work with a
> DH key?

Because you can't sign with a D-H encryption key, it can only perform
encryption operations.

Keith


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18731 for ietf-pkix-bks; Tue, 8 Jun 1999 11:25:54 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18726 for <[e-mail]>; Tue, 8 Jun 1999 11:25:50 -0700 (PDT)
Received: by puma.baltimore.ie; id UAA15153; Tue, 8 Jun 1999 20:06:39 +0100 (GMT/IST)
Received: from ocelot.baltimore.ie(10.49.0.10) by puma.baltimore.ie via smap (4.1) id xma015147; Tue, 8 Jun 99 20:06:27 +0100
Received: from sage.baltimore.ie ([e-mail] [10.49.0.139]) by ocelot.baltimore.ie (8.8.7/8.8.5) with ESMTP id TAA13699; Tue, 8 Jun 1999 19:27:21 +0100
Received: from sage.baltimore.ie (IDENT:keith@localhost [127.0.0.1]) by sage.baltimore.ie (8.9.3/8.9.3) with ESMTP id TAA06532; Tue, 8 Jun 1999 19:27:20 +0100
Message-Id: <[e-mail]>
To: "Bob Jueneman" <[e-mail]>
cc: [e-mail]
Subject: Re: Certificate requests for encryption keys 
Date: Tue, 08 Jun 1999 19:27:20 +0100
From: Keith Brady <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

One approach is to make a CMP IR/IP pair for a signature key certificate
which will have the effect of creating an authenticated identity
(presumably). This information should be maintained at the CA and we can
then make a CR request, signed (or POP'ed) by the signature key with the
encryption key as the payload.

We are, of course, not POP'ing the encryption key but this probably
doesn't matter. 

One can do the same with PKCS#10 though you miss the option to use POP.

cheers,

Keith


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18680 for ietf-pkix-bks; Tue, 8 Jun 1999 11:22:43 -0700 (PDT)
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 LAA18675 for <[e-mail]>; Tue, 8 Jun 1999 11:22:42 -0700 (PDT)
Received: 	id OAA28103; Tue, 8 Jun 1999 14:18:13 -0400
Received: by gateway id <LMMMA5WT>; Tue, 8 Jun 1999 14:20:41 -0400
Message-ID: <[e-mail]>
From: Jeff Brinskelle <[e-mail]>
To: "Ietf-Pkix (E-mail)" <[e-mail]>, "'Ilan Shacham'" <[e-mail]>
Subject: RE: Certificate requests for encryption keys
Date: Tue, 8 Jun 1999 14:20:38 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I assume you are talking about PKIX-CMP and RFC 2510.
In which case according to the interop profile in 
> Appendix B8 of RFC 2510,  to initialize a user with 
> a verification and an encryption certificate, the 
> client should send an 'ir' with two CertReqMsg's, 
> the first one (certReqId = 0) must be the verification 
> request, the second one (certReqId = 1) can be the 
> encryption certificate request.
> 
> The message is protected using MSG_MAC_ALG, so 
> the senderKID is used to identify the client to the CA.
> 
> POP is necessary if the client generates the enc key 
> pair and does not include the encryption private key 
in the encryption request, in which case there are 
> options - indirect or direct POP (both described 
> in section 2.3 of RFC 2510).
> 
> 
> Hope this helps.
> 
> 
> 
> ----------
> From: 	Ilan Shacham[SMTP:[e-mail]]
> Sent: 	Tuesday, June 08, 1999 12:39 PM
> To: 	Ietf-Pkix (E-mail)
> Subject: 	Certificate requests for encryption keys
> 
> There has been much talk lately of using dual key pairs - one key pair
> for encryption, and one for signing.
> The following question arises - how does one create a certificate request
> for an encryption key pair? after all, the certificate request is signed
> by
> the key inside it, but the key is an encryption key, so this is illegal.
> 
> I can think of two possible solutions to this problem -
> 1. For the purposes of certification requests, and for this purpose only,
> the
> encryption key could be used to sign.
> 2. First, a certificate is issued to the signing key, and then the signing
> key
> is used to sign the certification request for the encoding key. (But this
> way
> there is no Proof Of Posession of the encryption key).
> 
> It looks to me like the first option is better, but I couldn't find any
> reference
> to this problem in the PKIX drafts/RFC's. Is there such a reference? are
> there any applications out there that confronted this problem?
> 
> Ilan
> 
> ------------------------------------------------------------------------
> Ilan Shacham				mailto:[e-mail]
> Algorithmic Research Ltd.		http://www.arx.com
> 10 Nevatim St.,			phone:	972 - 3 - 9279540
> Petach-Tikva, Israel			Fax:	972 - 3 - 9230864
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18649 for ietf-pkix-bks; Tue, 8 Jun 1999 11:22:04 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18645 for <[e-mail]>; Tue, 8 Jun 1999 11:22:03 -0700 (PDT)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16067 for <[e-mail]>; Tue, 8 Jun 1999 11:23:49 -0700 (PDT)
Received: from saguaro.East.Sun.COM (saguaro.East.Sun.COM [129.148.75.130]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA00229; Tue, 8 Jun 1999 14:23:46 -0400 (EDT)
Received: (from aha@localhost) by saguaro.East.Sun.COM (8.9.1b+Sun/8.9.1) id OAA20831; Tue, 8 Jun 1999 14:23:45 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue,  8 Jun 1999 14:23:44 -0400 (EDT)
To: <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate requests for encryption keys
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14173.22785.901159.86568@saguaro>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to see any Subject, including an End-Entity, be able to 
issue certificates for encryption keys (and possibly other types as
well).

Justification:

1. CAs have the task of certifying identity.  There does not need to
   be a new identity certification in certifying keys other than
   those used for certifying or verifying identity.

2. End-Entities may need to change encryption keys frequently.  Many 
   CAs are not designed for frequent updates.

3. A CA can still have a policy of not signing end-entity
   certificates that allow certification of non-identity keys, if
   that CA wants to certify all end-entity keys.

4. A verifier can still have a policy of not accepting end-entity
   certificates that are used to certify non-identity keys, if that
   verifying wants a "CA" to verify all keys.

5. It is generally simpler for an End-Entity to manage the
   certificates used for purposes other than identity.

So REQUIRING non-identity keys to be certified by a CA seems to rule 
out reasonable and useful models for the use of certificates.

Supporting this model will require agreement on what combination of
BasicConstraints values and KeyUsage values are permitted in
certification paths.

One way to do this follows:

End-Entities could be issued certificates by a CA for keys with
KeyUsage of keyCertSign, but certification paths would accept these
keys only when used to sign certificates for the same End-Entity
where keyUsage is digitalSignature, nonRepudiation?,
keyEncipherment, dataEncipherment, or keyAgreement.

Example:

Certificate 1:
   Issuer:  X
   Subject: Y
   SubjectPublicKey: <Y's keyCertSign key>
   BasicConstraints: CA
   KeyUsage: keyCertSign
   Signed by: <X's keyCertSign key>

Certificate 2:
   Issuer: Y
   Subject: Z
   SubjectPublicKey: <Z's keyCertSign key>
   BasicConstraints: EE
   KeyUsage: keyCertSign
   Signed by: <Y's keyCertSign key>

Certificate 3:
   Issuer: Z
   Subject: Z
   SubjectPublicKey: <Z's keyEncipherment key>
   KeyUsage: keyEncipherment
   Signed by: <Z's keyCertSign key>

Other solutions include a new KeyUsage type corresponding to
"keyCertSign", but used only for End-Entities.

Anne Anderson
-- 
Anne H. Anderson  ECI#712-KC Email: [e-mail]
Sun Microsystems Laboratories   or: [e-mail]
1 Network Drive,UBUR02-311     Tel: [phone]
Burlington, MA 01803-0902 USA  Fax: [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18012 for ietf-pkix-bks; Tue, 8 Jun 1999 11:08:34 -0700 (PDT)
Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18006 for <[e-mail]>; Tue, 8 Jun 1999 11:08:32 -0700 (PDT)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id SAA23973; Tue, 8 Jun 1999 18:09:27 GMT
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id TAA28417; Tue, 8 Jun 1999 19:09:48 +0100
Message-ID: <[e-mail]>
Date: Tue, 08 Jun 1999 19:09:26 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Certificate requests for encryption keys
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob Jueneman wrote:
> 
> Excellent question, and one we have been pondering as well,
> since Novell's NICI strongly types keys and rigidly enforces the
> allowed operations.
> 
> Our working, temporary expedient, along the lines of your #1,
> is to type the private key for both encryption and signature, but to
> only turn on the encryption bit in the certificate.  But that's an
> admittedly ugly hack.  Worse yet, it won't work at all with a
> DH encryption key.

I feel sure I'm going to regret asking, but why won't this work with a
DH key?

BTW, it seems to me that the more appropriate thing to do is to make it
legal to sign certificate requests (and only certificate requests) with
encryption-only keys rather than mark the private key for signing (which
then means it can be used for signing despite the certificate). In terms
of APIs, this means constructing and signing a cert request in a single
step, I presume (or marking a cert request as "signable by an encryption
key" - hmm, that might be a cool approach, too).

Cheers,

Ben.

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

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA17959 for ietf-pkix-bks; Tue, 8 Jun 1999 11:04:57 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA17953 for <[e-mail]>; Tue, 8 Jun 1999 11:04:51 -0700 (PDT)
Received: by puma.baltimore.ie; id TAA14836; Tue, 8 Jun 1999 19:45:39 +0100 (GMT/IST)
Received: from ocelot.baltimore.ie(10.49.0.10) by puma.baltimore.ie via smap (4.1) id xma014828; Tue, 8 Jun 99 19:44:50 +0100
Received: from crown (crown.baltimore.ie [10.49.0.138]) by ocelot.baltimore.ie (8.8.7/8.8.5) with SMTP id TAA12956; Tue, 8 Jun 1999 19:05:44 +0100
Received: by localhost with Microsoft MAPI; Tue, 8 Jun 1999 19:06:45 +0100
Message-ID: <[e-mail]>
From: Tom Biskupic <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "'Tom Biskupic'" <[e-mail]>, "'Ietf-Pkix (E-mail)'" <[e-mail]>, "'Alex Deacon'" <[e-mail]>
Subject: RE: Possible clarification to RFC 2459
Date: Tue, 8 Jun 1999 19:06:44 +0100
Organization: Baltimore
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ambarish,

Yes I understand what you are saying. Yes as I said you could argue (and in 
fact you did) that in the case where you have a CRL/ARL split the presence 
of an IDP does indicate the CRL has been partitioned but I am saying there 
is no way to tell if the CRL has been split in other ways.

The issue is based on my assumption that there will be many systems that 
split a CRL into a CRL and ARL but few that split further. If a CRL 
containing a IDP is encountered which has the 'onlyContainsUserCerts' 
optional flag (which we believe is a common occurence) there is no way to 
tell if the set of revoked certificates has been partitioned further or if 
this is the only split criteria. Ok strictly speaking the CRL is split but 
in this case that's not very useful as what you really want to know is 
where to go to check the validity of the (usually) end user certificate you 
are holding.

A more serious problem occurs in the second case I highlighted - an 
organisation has no directory service (ie an LDAP server) so they 
distribute their CRLs through a URI. Every issued certificate (maybe even 
including CA certificates) contains a CDP extension pointing at this URI. A 
complete CRL is posted to that location every day. In this case the 
presence of an IDP extension in the CRL does not indicate a partial CRL. 
Essentially the lack of an IDP implies a full CRL but the presence of an 
IDP may not indicate a partial CRL.

Where does that get us? Hmm I'm not sure.

Tom Biskupic

On Tuesday, June 08, 1999 6:42 PM, Ambarish Malpani 
[SMTP:[e-mail]] wrote:
> I am not clear why what I proposed wouldn't work.
>
> Assumption: A full CRL contains *all* the revoked and unexpired
> certs issued by this CA. This would include both end user and
> CA certs.
>
> The full CRL doesn't need to contain the IDP extension unless it
> is an indirect CRL, in which case, it will contain the IDP
> extension, but with *only* the indirectCRL field set.
>
> You could still issue end user CRLs with IDP and
> onlyContainsUserCerts set or ARLs, with IDP and onlyContainsCACerts -
> neither of these are the full CRL.
>
> Am I missing something?
>
> Regards,
> Ambarish
>
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect					         650.567.5457
> ValiCert, Inc.				        [e-mail]
> 1215 Terra Bella Ave.		              http://www.valicert.com
> Mountain View, CA 94043-1833
>
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf
> > Of [e-mail]
> > Sent: Tuesday, June 08, 1999 5:23 AM
> > To: Tom Biskupic
> > Cc: 'Alex Deacon'; Ambarish Malpani [[e-mail]] (E-mail);
> > Ietf-Pkix (E-mail)
> > Subject: RE: Possible clarification to RFC 2459
> >
> >
> >
> >
> > That's precisely what Jonah does - we need to be able to determine by
> > inspection whether a given CRL is a user CRL or an ARL, and
> > the only way we
> > could find to do this was to use the "onlyContainsUserCerts" and
> > "onlyContainsCACerts" flags within the IDP extension.
> >
> > John
> >
> >
> >
> >
> >
> > Tom Biskupic <[e-mail]>@imc.org on 06/08/99 06:12:11 AM
> >
> > Sent by:  [e-mail]
> >
> >
> > To:   "'Alex Deacon'" <[e-mail]>, "Ambarish Malpani
> >       [[e-mail]] (E-mail)" <[e-mail]>
> > cc:   "Ietf-Pkix (E-mail)" <[e-mail]>
> >
> > Subject:  RE: Possible clarification to RFC 2459
> >
> >
> > Alex, Ambarish,Russ,
> >
> > Something to take into account here is that some CAs may use
> > the IDP for
> > full CRLs in order to distinguish them from a ARLs. I see this as a
> > requirement for CAs posting to directories in which case the
> > CRL and ARL go
> > into the same location and without this extension, are
> > indistinguishable.
> >
> > This makes the criteria somewhat more muddy as a partial CRL is then
> > defined as one which has an IDP containing a DP that is not
> > the same as the
> > default location for the issuing CA. That is, the only way to
> > tell if this
> > is a partial CRL is that it has something in the IDP to say
> > it was issued
> > to somewhere different to the default location.
> >
> > You could argue that splitting a CRL between a CRL/ARL is effectively
> > partitioning however in most cases the question you want answered is
> > 'Should this CRL contain this end user certificate if it is
> > revoked" and
> > this criteria won't help.
> >
> > Now if CDPs where being used just to allow full CRLs to be
> > published to a
> > URI or some other type of location (ie a full CRL published
> > to a URI) then
> > you have no way to tell at all.
> >
> > Tom Biskupic
> >
> > On Tuesday, June 08, 1999 4:07 AM, Alex Deacon
> > [SMTP:[e-mail]]
> > wrote:
> > >
> > > OK, on first though this sound like a reasonable way to
> > specify a full
> > CRL.
> > > Basically, what you are saying is that if a cert using
> > application gets a
> > > cert which contains a CDP pointing to a particular
> > partition, but for
> > some
> > > reason this application only has a CRL which does not
> > contain an IDP,
> > then
> > > they can be confident that they can verify the status of
> > the cert based
> > on
> > > this CRL.
> > >
> > > Right?
> > >
> > > Alex
> > >
> > > > -----Original Message-----
> > > > From: Ambarish Malpani [mailto:[e-mail]]
> > > > Sent: Monday, June 07, 1999 3:06 PM
> > > > To: [e-mail]; [e-mail]
> > > > Subject: RE: Possible clarification to RFC 2459
> > > >
> > > >
> > > >
> > > > I agree with what Tom wants - would like to be able to
> > > > distinguish whether a CRL is a full or a partial CRL. Can we
> > > > add the following paragraph to section 5.2.5:
> > > >
> > > > A full CRL from/for a CA MUST NOT contain the
> > > > issuingDistributionPoint extension, unless it is an indirect CRL,
> > > > in which case, it MAY contain the issuingDistributionPoint
> > > > extension with only the indirectCRL field set to true.
> > > >
> > > > Would this work for most people? Any objections?
> > > > Ambarish
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > Ambarish Malpani
> > > > Architect                               650.567.5457
> > > > ValiCert, Inc.
> > > > [e-mail]
> > > > 1215 Terra Bella Ave.
> > http://www.valicert.com
> > > > Mountain View, CA 94043-1833
> > > >
> >
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > > > [mailto:[e-mail]]On Behalf
> > > > > Of [e-mail]
> > > > > Sent: Monday, June 07, 1999 8:25 AM
> > > > > To: Ambarish Malpani; [e-mail]
> > > > > Subject: Possible clarification to RFC 2459
> > > > >
> > > > >
> > > > >      The current definition of Issuing Distribution Point
> > > > > leaves it relatively
> > > > > unclear whether the presence of the "DistributionPoint" field
> > > > > within this
> > > > > extension indicates that the CRL at that distribution point
> > > > > is a partial CRL.  I
> > > > > would like to suggest that the following text be added to RFC
> > > > > 2459 section
> > > > > 5.2.5:
> > > > >
> > > > >      Where the issuingDistributionPoint extension contains
> > > > > either a DN or an
> > > > > RDN, the distribution point SHOULD contain only certificates
> > > > > which contain a CRL
> > > > > Distribution Point extension one of whose DistributionPoint's
> > > > > contains the same
> > > > > value in the "distributionPoint" field.
> > > > >
> > > > >      To make it clear that CRL Distribution Point's support
> > > > > partitioning even
> > > > > for URL's, the following existing text in section 4.2.1.14
> > > > > could be modified as
> > > > > follows:
> > > > > [Old]     the URI is a pointer to the current CRL for the
> > > > > associated reasons and
> > > > > will be issued by the associated cRLIssuer.
> > > > > [New]     the URI is a pointer to a current CRL for the
> > > > > associated reasons for
> > > > > those certificates and will be issued by the associated
> > > > > cRLIssuer.  The CRL so
> > > > > referenced SHOULD contain only certificates whose CRL
> > > > > Distribution Point
> > > > > extension contains this URI and certificates not containing
> > > > > any CRL Distribution
> > > > > Point extension.
> > > > >
> > > > >           Tom Gindin
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> >
> >
> >
> >
> > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17526 for ietf-pkix-bks; Tue, 8 Jun 1999 10:56:24 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17522 for <[e-mail]>; Tue, 8 Jun 1999 10:56:23 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA16557 for <[e-mail]>; Tue, 8 Jun 1999 13:58:10 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA16551 for <[e-mail]>; Tue, 8 Jun 1999 13:58:09 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA29777 for <[e-mail]>; Tue, 8 Jun 1999 13:58:13 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id NAA14444 for <[e-mail]>; Tue, 8 Jun 1999 13:55:37 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 8 Jun 1999 13:55:37 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Certificate requests for encryption keys
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 8YtjZBtdAzZi0h2y/jiS+w==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: "Bob Jueneman" <[e-mail]>
>
>  [...]
> 
> Our working, temporary expedient, along the lines of your #1,
> is to type the private key for both encryption and signature, but to 
> only turn on the encryption bit in the certificate.  But that's an 
> admittedly ugly hack.  Worse yet, it won't work at all with a 
> DH encryption key.
> 
> The real question is what are existing CAs prepared to support
> with respect to more advanced POP protocols?



You mean "more advanced protocols" such as the one defined in
PKIX RFC 2510/2511?  I believe there is at least one CA which
supports POP for key transport (RSA) and key agreement (DH or KEA)
keys in the standard manner.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17026 for ietf-pkix-bks; Tue, 8 Jun 1999 10:37:18 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17022 for <[e-mail]>; Tue, 8 Jun 1999 10:37:18 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id KAA14392; Tue, 8 Jun 1999 10:37:42 -0700 (PDT)
Received: from rhone (dhcp-3-116.engineering.valicert.com [192.168.3.116] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id KAA24378; Tue, 8 Jun 1999 10:38:45 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>, "'Tom Biskupic'" <[e-mail]>
Cc: "'Alex Deacon'" <[e-mail]>, "'Ietf-Pkix (E-mail)'" <[e-mail]>
Subject: RE: Possible clarification to RFC 2459
Date: Tue, 8 Jun 1999 10:42:13 -0700
Message-ID: <001001beb1d6$3e7400a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am not clear why what I proposed wouldn't work.

Assumption: A full CRL contains *all* the revoked and unexpired
certs issued by this CA. This would include both end user and
CA certs.

The full CRL doesn't need to contain the IDP extension unless it
is an indirect CRL, in which case, it will contain the IDP
extension, but with *only* the indirectCRL field set.

You could still issue end user CRLs with IDP and
onlyContainsUserCerts set or ARLs, with IDP and onlyContainsCACerts -
neither of these are the full CRL.

Am I missing something?

Regards,
Ambarish


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


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]On Behalf
> Of [e-mail]
> Sent: Tuesday, June 08, 1999 5:23 AM
> To: Tom Biskupic
> Cc: 'Alex Deacon'; Ambarish Malpani [[e-mail]] (E-mail);
> Ietf-Pkix (E-mail)
> Subject: RE: Possible clarification to RFC 2459
> 
> 
> 
> 
> That's precisely what Jonah does - we need to be able to determine by
> inspection whether a given CRL is a user CRL or an ARL, and 
> the only way we
> could find to do this was to use the "onlyContainsUserCerts" and
> "onlyContainsCACerts" flags within the IDP extension.
> 
> John
> 
> 
> 
> 
> 
> Tom Biskupic <[e-mail]>@imc.org on 06/08/99 06:12:11 AM
> 
> Sent by:  [e-mail]
> 
> 
> To:   "'Alex Deacon'" <[e-mail]>, "Ambarish Malpani
>       [[e-mail]] (E-mail)" <[e-mail]>
> cc:   "Ietf-Pkix (E-mail)" <[e-mail]>
> 
> Subject:  RE: Possible clarification to RFC 2459
> 
> 
> Alex, Ambarish,Russ,
> 
> Something to take into account here is that some CAs may use 
> the IDP for
> full CRLs in order to distinguish them from a ARLs. I see this as a
> requirement for CAs posting to directories in which case the 
> CRL and ARL go
> into the same location and without this extension, are 
> indistinguishable.
> 
> This makes the criteria somewhat more muddy as a partial CRL is then
> defined as one which has an IDP containing a DP that is not 
> the same as the
> default location for the issuing CA. That is, the only way to 
> tell if this
> is a partial CRL is that it has something in the IDP to say 
> it was issued
> to somewhere different to the default location.
> 
> You could argue that splitting a CRL between a CRL/ARL is effectively
> partitioning however in most cases the question you want answered is
> 'Should this CRL contain this end user certificate if it is 
> revoked" and
> this criteria won't help.
> 
> Now if CDPs where being used just to allow full CRLs to be 
> published to a
> URI or some other type of location (ie a full CRL published 
> to a URI) then
> you have no way to tell at all.
> 
> Tom Biskupic
> 
> On Tuesday, June 08, 1999 4:07 AM, Alex Deacon 
> [SMTP:[e-mail]]
> wrote:
> >
> > OK, on first though this sound like a reasonable way to 
> specify a full
> CRL.
> > Basically, what you are saying is that if a cert using 
> application gets a
> > cert which contains a CDP pointing to a particular 
> partition, but for
> some
> > reason this application only has a CRL which does not 
> contain an IDP,
> then
> > they can be confident that they can verify the status of 
> the cert based
> on
> > this CRL.
> >
> > Right?
> >
> > Alex
> >
> > > -----Original Message-----
> > > From: Ambarish Malpani [mailto:[e-mail]]
> > > Sent: Monday, June 07, 1999 3:06 PM
> > > To: [e-mail]; [e-mail]
> > > Subject: RE: Possible clarification to RFC 2459
> > >
> > >
> > >
> > > I agree with what Tom wants - would like to be able to
> > > distinguish whether a CRL is a full or a partial CRL. Can we
> > > add the following paragraph to section 5.2.5:
> > >
> > > A full CRL from/for a CA MUST NOT contain the
> > > issuingDistributionPoint extension, unless it is an indirect CRL,
> > > in which case, it MAY contain the issuingDistributionPoint
> > > extension with only the indirectCRL field set to true.
> > >
> > > Would this work for most people? Any objections?
> > > Ambarish
> > >
> > >
> > > 
> ---------------------------------------------------------------------
> > > Ambarish Malpani
> > > Architect                               650.567.5457
> > > ValiCert, Inc.
> > > [e-mail]
> > > 1215 Terra Bella Ave.                        
> http://www.valicert.com
> > > Mountain View, CA 94043-1833
> > >
> 
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]On Behalf
> > > > Of [e-mail]
> > > > Sent: Monday, June 07, 1999 8:25 AM
> > > > To: Ambarish Malpani; [e-mail]
> > > > Subject: Possible clarification to RFC 2459
> > > >
> > > >
> > > >      The current definition of Issuing Distribution Point
> > > > leaves it relatively
> > > > unclear whether the presence of the "DistributionPoint" field
> > > > within this
> > > > extension indicates that the CRL at that distribution point
> > > > is a partial CRL.  I
> > > > would like to suggest that the following text be added to RFC
> > > > 2459 section
> > > > 5.2.5:
> > > >
> > > >      Where the issuingDistributionPoint extension contains
> > > > either a DN or an
> > > > RDN, the distribution point SHOULD contain only certificates
> > > > which contain a CRL
> > > > Distribution Point extension one of whose DistributionPoint's
> > > > contains the same
> > > > value in the "distributionPoint" field.
> > > >
> > > >      To make it clear that CRL Distribution Point's support
> > > > partitioning even
> > > > for URL's, the following existing text in section 4.2.1.14
> > > > could be modified as
> > > > follows:
> > > > [Old]     the URI is a pointer to the current CRL for the
> > > > associated reasons and
> > > > will be issued by the associated cRLIssuer.
> > > > [New]     the URI is a pointer to a current CRL for the
> > > > associated reasons for
> > > > those certificates and will be issued by the associated
> > > > cRLIssuer.  The CRL so
> > > > referenced SHOULD contain only certificates whose CRL
> > > > Distribution Point
> > > > extension contains this URI and certificates not containing
> > > > any CRL Distribution
> > > > Point extension.
> > > >
> > > >           Tom Gindin
> > > >
> > > >
> > > >
> > > >
> > >
> 
> 
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA16411 for ietf-pkix-bks; Tue, 8 Jun 1999 10:20:35 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA16407 for <[e-mail]>; Tue, 8 Jun 1999 10:20:34 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 08 Jun 1999 11:21:50 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 08 Jun 1999 11:21:30 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Certificate requests for encryption keys
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 KAA16408
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Excellent question, and one we have been pondering as well,
since Novell's NICI strongly types keys and rigidly enforces the 
allowed operations.

Our working, temporary expedient, along the lines of your #1,
is to type the private key for both encryption and signature, but to 
only turn on the encryption bit in the certificate.  But that's an 
admittedly ugly hack.  Worse yet, it won't work at all with a 
DH encryption key.

The real question is what are existing CAs prepared to support
with respect to more advanced POP protocols?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387

>>> Ilan Shacham <[e-mail]> 06/08/99 10:39AM >>>
There has been much talk lately of using dual key pairs - one key pair
for encryption, and one for signing.
The following question arises - how does one create a certificate request
for an encryption key pair? after all, the certificate request is signed by
the key inside it, but the key is an encryption key, so this is illegal.

I can think of two possible solutions to this problem -
1. For the purposes of certification requests, and for this purpose only,
the
encryption key could be used to sign.
2. First, a certificate is issued to the signing key, and then the signing
key
is used to sign the certification request for the encoding key. (But this
way
there is no Proof Of Posession of the encryption key).

It looks to me like the first option is better, but I couldn't find any
reference
to this problem in the PKIX drafts/RFC's. Is there such a reference? are
there any applications out there that confronted this problem?

Ilan

------------------------------------------------------------------------
Ilan Shacham				mailto:[e-mail] 
Algorithmic Research Ltd.		http://www.arx.com 
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA15914 for ietf-pkix-bks; Tue, 8 Jun 1999 10:10:13 -0700 (PDT)
Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA15910 for <[e-mail]>; Tue, 8 Jun 1999 10:10:12 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id NAA17999 for <[e-mail]>; Tue, 8 Jun 1999 13:11:59 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id NAA15334 for <[e-mail]>; Tue, 8 Jun 1999 13:11:54 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525678A.005DB3FA ; Tue, 8 Jun 1999 13:03:29 -0400
X-Lotus-FromDomain: FDC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 8 Jun 1999 10:07:14 -0700
Subject: Re: Re[2]: Summary, was Re: Every time ..., was Re: General form
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Looking at it from completely different view point ... large consumer service
organization (tens of millions of customers) several years was looking at its
information infrastructure. It determined

1) had something like 6000 unique databases around the corporation

2) there was possibly 95% commonality in the data across all the databases
(things like names, addresses, phone numbers, etc)

3) possibly 20% of the data was "dirty" ... i.e. not accurate for one reason or
another


"dirty" data could be because it was originally entered incorrectly and/or it
had been incorrectly updated (i.e. person moved and thier address was
consistently updated ... and/or the name of the person at a specific address
wasn't consistently updated ... i.e. large number of different databases some
indexed by address, others indexed by name).

This doesn't directly give the lifetime of the associated attributes ... but
some big piece of the (20%) "dirty data" is proportional to the lifetime of the
attributes (approximate frequency of change) and the window to consistently
propogate changes thru the internal corporate databases

Lets say for half the population ... the name attribute never changes in 95% of
the cases ... for the other half of the population ... the name attribute
changes one or more times in 90?% of the cases. For the population as a whole,
an address attribute changes 10-20 times. Name change probability can be
calculated for the population as a whole ... but since there is such a large
bimodel distribution for name changes ... it can be worthwhile to calculate the
values seperately for the two sets.

If there three independent variables with avg lifetimes of 2 years, 5 years, and
10 years ... then the probability that at least one of the variables changes in
the next year is:

.5+.2+.1 ... = .8

The avg. expected lifetime of the collection of the three variables
is approximately 1.25 years.

1/(1/t0+1/t1+1/t2)

dependent variables ... say 90% of the time that address changes ... the phone
number also changes ... can be treated seperately. If the avg. address lifetime
is 5 years and the avg. phone number lifetime is 10 years (for situations where
the phone number changes independently of the address) ... then the probability
that either will change next year is:

.2 + .1 = .3

Effectively only treating the probability of independent event changes (i.e.
dependent variable events don't increase the overall probability that there will
be a change in the collection of variables). The expected lifetime of a unique
collection of attribute values is proporational to the probability of something
changing. This is only identical to the individual attribute lifetime
calculations when they are totally indepedent attributes.  The lifetime of a
collection of unque attributes values is proportional to the probability that
there will be some change ... and is not (necessarily) porportional to the
lifetime of the individual attribute lifetimes. It is probability that there is
one or more changes to the values of the collection ... which is the collection
of the independent probabilities (calculation involving the number of variables
in a multi-variable change event ... i.e. dependent variables ... would only be
involved if the avg. number of attribute changed per change event was being
calculated ... but don't enter into the calculation of whether there is a change
event).

The lifetime of address/phone combination then is about 3.3years. If I have a
street address, a city address, a state address and a zipcode ... and they all
change dependently ... whether there are 2 dependent changes or four dependent
changes doesn't increase the overall probability that at lest one thing changes.

For detailed modeling ... in addition to strong bi-model & multi-model
distributions  .... there are likely 2nd order effects ... like if somebody has
changed jobs twice in the past five years increases the probability that they
will change jobs in the next five years (although if they have just changed jobs
in the last month, it reduces the probability that they will change jobs in the
next year).

The calculation is the probability of whether there will be any change (whether
for a single attribute or some collection of attributes) ... from which the avg.
expected lifetime can be derived. However, the avg. expected lifetime of a
collection of unique attribute values is only indirectly related to the expected
individual lifetimes of those attributes.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA15098 for ietf-pkix-bks; Tue, 8 Jun 1999 09:50:12 -0700 (PDT)
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 JAA15093 for <[e-mail]>; Tue, 8 Jun 1999 09:50:06 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id JAA12510; Tue, 8 Jun 1999 09:51:40 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 08 Jun 1999 09:51:09 -0700
To: [e-mail], <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Re[2]: Summary, was Re: Every time ..., was Re: General form
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
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:53 PM 6/8/99 GMT, [e-mail] wrote:
>I think we need a simple example to clarify the question:

Veikko,

Thank you for putting my question so succinctly!

___tony___

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA14946 for ietf-pkix-bks; Tue, 8 Jun 1999 09:45:50 -0700 (PDT)
Received: from mx.arx.com (mx.arx.com [212.25.66.96]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA14941 for <[e-mail]>; Tue, 8 Jun 1999 09:45:44 -0700 (PDT)
Received: by mx.arx.com with Internet Mail Service (5.5.2232.9) id <MQ4QP37V>; Tue, 8 Jun 1999 19:39:05 +0300
Message-ID: <[e-mail]>
From: Ilan Shacham <[e-mail]>
To: "Ietf-Pkix (E-mail)" <[e-mail]>
Subject: Certificate requests for encryption keys
Date: Tue, 8 Jun 1999 19:39:04 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There has been much talk lately of using dual key pairs - one key pair
for encryption, and one for signing.
The following question arises - how does one create a certificate request
for an encryption key pair? after all, the certificate request is signed by
the key inside it, but the key is an encryption key, so this is illegal.

I can think of two possible solutions to this problem -
1. For the purposes of certification requests, and for this purpose only,
the
encryption key could be used to sign.
2. First, a certificate is issued to the signing key, and then the signing
key
is used to sign the certification request for the encoding key. (But this
way
there is no Proof Of Posession of the encryption key).

It looks to me like the first option is better, but I couldn't find any
reference
to this problem in the PKIX drafts/RFC's. Is there such a reference? are
there any applications out there that confronted this problem?

Ilan

------------------------------------------------------------------------
Ilan Shacham				mailto:[e-mail]
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA05963 for ietf-pkix-bks; Tue, 8 Jun 1999 05:42:50 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA05958 for <[e-mail]>; Tue, 8 Jun 1999 05:42:48 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA00467; Tue, 8 Jun 1999 05:41:23 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 08 Jun 1999 08:11:53 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Possible clarification to RFC 2459
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom:

Your proposed text is too simple.  Consider the Indirect CRL case.  CA1
uses a CRL Distribution Point (CDP) extension to specifify that CA2 will
issue CRLs for reason CA compromise.  Also, CA3 uses a CRL Distribution
Point (CDP) extension to specifify that CA2 will issue CRLs for reason key
compromise.  So, CA3's CRL must include at least reason codes for CA
compromise and key compromise.  

Russ


At 11:25 AM 6/7/99 -0400, [e-mail] wrote:
>     The current definition of Issuing Distribution Point leaves it relatively
>unclear whether the presence of the "DistributionPoint" field within this
>extension indicates that the CRL at that distribution point is a partial 
>CRL.  I
>would like to suggest that the following text be added to RFC 2459 section
>5.2.5:
>
>     Where the issuingDistributionPoint extension contains either a DN or an
>RDN, the distribution point SHOULD contain only certificates which contain a 
>CRL
>Distribution Point extension one of whose DistributionPoint's contains the
same
>value in the "distributionPoint" field.
>
>     To make it clear that CRL Distribution Point's support partitioning even
>for URL's, the following existing text in section 4.2.1.14 could be
modified as
>follows:
>[Old]     the URI is a pointer to the current CRL for the associated reasons 
>and
>will be issued by the associated cRLIssuer.
>[New]     the URI is a pointer to a current CRL for the associated reasons for
>those certificates and will be issued by the associated cRLIssuer.  The CRL so
>referenced SHOULD contain only certificates whose CRL Distribution Point
>extension contains this URI and certificates not containing any CRL 
>Distribution
>Point extension.
>
>          Tom Gindin
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA04520 for ietf-pkix-bks; Tue, 8 Jun 1999 05:22:44 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA04512 for <[e-mail]>; Tue, 8 Jun 1999 05:22:32 -0700 (PDT)
From: [e-mail]
Subject: RE: Possible clarification to RFC 2459
To: Tom Biskupic <[e-mail]>
Cc: "'Alex Deacon'" <[e-mail]>, "Ambarish Malpani [[e-mail]] (E-mail)" <[e-mail]>, "Ietf-Pkix (E-mail)" <[e-mail]>
Date: Tue, 08 Jun 1999 12:23:28 GMT
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Epic/Iris(Daily Build (based on 166.1)|Apr  6 1999) at 06/08/99 08:27:05 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

That's precisely what Jonah does - we need to be able to determine by
inspection whether a given CRL is a user CRL or an ARL, and the only way we
could find to do this was to use the "onlyContainsUserCerts" and
"onlyContainsCACerts" flags within the IDP extension.

John





Tom Biskupic <[e-mail]>@imc.org on 06/08/99 06:12:11 AM

Sent by:  [e-mail]


To:   "'Alex Deacon'" <[e-mail]>, "Ambarish Malpani
      [[e-mail]] (E-mail)" <[e-mail]>
cc:   "Ietf-Pkix (E-mail)" <[e-mail]>

Subject:  RE: Possible clarification to RFC 2459


Alex, Ambarish,Russ,

Something to take into account here is that some CAs may use the IDP for
full CRLs in order to distinguish them from a ARLs. I see this as a
requirement for CAs posting to directories in which case the CRL and ARL go
into the same location and without this extension, are indistinguishable.

This makes the criteria somewhat more muddy as a partial CRL is then
defined as one which has an IDP containing a DP that is not the same as the
default location for the issuing CA. That is, the only way to tell if this
is a partial CRL is that it has something in the IDP to say it was issued
to somewhere different to the default location.

You could argue that splitting a CRL between a CRL/ARL is effectively
partitioning however in most cases the question you want answered is
'Should this CRL contain this end user certificate if it is revoked" and
this criteria won't help.

Now if CDPs where being used just to allow full CRLs to be published to a
URI or some other type of location (ie a full CRL published to a URI) then
you have no way to tell at all.

Tom Biskupic

On Tuesday, June 08, 1999 4:07 AM, Alex Deacon [SMTP:[e-mail]]
wrote:
>
> OK, on first though this sound like a reasonable way to specify a full
CRL.
> Basically, what you are saying is that if a cert using application gets a
> cert which contains a CDP pointing to a particular partition, but for
some
> reason this application only has a CRL which does not contain an IDP,
then
> they can be confident that they can verify the status of the cert based
on
> this CRL.
>
> Right?
>
> Alex
>
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[e-mail]]
> > Sent: Monday, June 07, 1999 3:06 PM
> > To: [e-mail]; [e-mail]
> > Subject: RE: Possible clarification to RFC 2459
> >
> >
> >
> > I agree with what Tom wants - would like to be able to
> > distinguish whether a CRL is a full or a partial CRL. Can we
> > add the following paragraph to section 5.2.5:
> >
> > A full CRL from/for a CA MUST NOT contain the
> > issuingDistributionPoint extension, unless it is an indirect CRL,
> > in which case, it MAY contain the issuingDistributionPoint
> > extension with only the indirectCRL field set to true.
> >
> > Would this work for most people? Any objections?
> > Ambarish
> >
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                               650.567.5457
> > ValiCert, Inc.
> > [e-mail]
> > 1215 Terra Bella Ave.                        http://www.valicert.com
> > Mountain View, CA 94043-1833
> >
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]On Behalf
> > > Of [e-mail]
> > > Sent: Monday, June 07, 1999 8:25 AM
> > > To: Ambarish Malpani; [e-mail]
> > > Subject: Possible clarification to RFC 2459
> > >
> > >
> > >      The current definition of Issuing Distribution Point
> > > leaves it relatively
> > > unclear whether the presence of the "DistributionPoint" field
> > > within this
> > > extension indicates that the CRL at that distribution point
> > > is a partial CRL.  I
> > > would like to suggest that the following text be added to RFC
> > > 2459 section
> > > 5.2.5:
> > >
> > >      Where the issuingDistributionPoint extension contains
> > > either a DN or an
> > > RDN, the distribution point SHOULD contain only certificates
> > > which contain a CRL
> > > Distribution Point extension one of whose DistributionPoint's
> > > contains the same
> > > value in the "distributionPoint" field.
> > >
> > >      To make it clear that CRL Distribution Point's support
> > > partitioning even
> > > for URL's, the following existing text in section 4.2.1.14
> > > could be modified as
> > > follows:
> > > [Old]     the URI is a pointer to the current CRL for the
> > > associated reasons and
> > > will be issued by the associated cRLIssuer.
> > > [New]     the URI is a pointer to a current CRL for the
> > > associated reasons for
> > > those certificates and will be issued by the associated
> > > cRLIssuer.  The CRL so
> > > referenced SHOULD contain only certificates whose CRL
> > > Distribution Point
> > > extension contains this URI and certificates not containing
> > > any CRL Distribution
> > > Point extension.
> > >
> > >           Tom Gindin
> > >
> > >
> > >
> > >
> >





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA04016 for ietf-pkix-bks; Tue, 8 Jun 1999 04:57:01 -0700 (PDT)
Received: from mailgate.psion.com (mailgate.symbian.com [194.129.1.246]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA04012 for <[e-mail]>; Tue, 8 Jun 1999 04:56:59 -0700 (PDT)
From: [e-mail]
Received: from software-data1.symbian.com (smtpgate2.symbian.com [194.129.2.236] (may be forged)) by mailgate.psion.com (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id MAA01423; Tue, 08 Jun 1999 12:55:00 +0100
Received: from ccMail by software-data1.symbian.com (ccMail Link to SMTP R8.20.00.25) id AA928842763; Tue, 08 Jun 1999 12:52:48 GMT
Message-Id: <[e-mail]>
X-Mailer: ccMail Link to SMTP R8.20.00.25
Date: Tue, 08 Jun 1999 12:53:56 GMT
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re[2]: Summary, was Re: Every time ..., was Re: General form
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: "cc:Mail Note Part"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think we need a simple example to clarify the question:

Suppose I have two different business cards, one of them (A) says:

Veikko Punkka
Symbian Ltd.

while the other one (B) says:

Veikko Punkka
Software Engineer

Now, each of these business cards has a lifetime that is given by the now 
well known Gerck formula:

1/TA = 1/Ta1 + 1/Ta2 (1)

1/TB = 1/Tb1 + 1/Tb2 (2)

Now, suppose I print another business card that has card A on one side and 
card B on the other. Naively thinking you might expect that the lifetime of 
the new card (C) would be given by the formula (after all A and B are not 
100% redundant)

1/TC = 1/TA + 1/TB (3)

but this is not true since a1 and b1 are 100% redundant and therefore

1/TC = 1/Ta1 + 1/Ta2 + 1/Tb2 (4)

Now, my interpretation of the question is: How can we be sure we are not 
making false conclusions like (3)?

Cheers,
    Veikko Punkka


______________________________ Reply Separator _________________________________
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
Author:  Ed Gerck <[e-mail]> at symb-internet
Date:    08/06/99 01:17




Tony Bartoletti wrote:

> The given formula "works" (assuming all component attributes have identical
> lifetimes.)

Tony:

I can't understand the "works" -- do you find a mistake in the results?

> I wanted to explore the more general case, where the component lifetimes
> are unequal, and to help define "degrees of redundancy".
>
> A simple (?) example:
>
>   Consider a certificate C over two attributes A and B with lifetimes given
>   by TA and TB, respectively.
>
>   Assuming no redundancy, we allow 1/TC = 1/TA + 1/TB.

You mean, there is no 100% redundancy? Because redundancy is NOT
a problem in the equation -- as I showed in my e-mail anterior and
you recognized when you wrote above "works" ;-))))

Of course, you cannot just *repeat* the *same* attribute two times
and expect that you have two attributes, in fact you would just one
attribute, no?

>   Suppose, upon closer inspection, we agree that attributes A and B are
>   themselves formed of components.  Specifically:
>
>         A = a1 and a2 and a3  (respective lifetimes Ta1, Ta2, Ta3)
>         B = b1 and b2 and b3  (respective lifetimes Tb1, Tb2, Tb3)
>
>   Note:  Attribute A is valid IFF all of a1, a2, a3 are valid, etc.
>
>   Continuing under assumptions of no redundancy, we still find
>
>         1/TC = 1/TA + 1/TB
>              = 1/Ta1 + 1/Ta2 + 1/Ta3 + 1/Tb1 + 1/Tb2 + 1/Tb3

You "forgot" to impose the conditions, derived directly by your
hypothesis:

1/TA = 1/Ta1 + 1/Ta2 + 1/Ta3
1/TB = 1/Tb1 + 1/Tb2 + 1/Tb3

>   Suppose a "final investigation" reveals that the components a1 and a2 of A
>   are precisely the components b1 and b2 of B.  Thus the certificate C
>   certifies exactly the components a1, a2, a3, b3.

Your affirmation does not make mathematical sense, Tony. What do you mean by

"the components a1 and a2 of A are precisely the components b1 and b2 of B."

Do you mean they are equal? So what? You affirmed before that:

 "Assuming no redundancy, we allow 1/TC = 1/TA + 1/TB"

so we know we are not dealing here with the *same* attributes that were
just repeated, like:

Attribute1 = 'tony'
Attribute2 = 'tony'

So,  your :"results" do not apply. But, it is a simple confusion. Calculate
again, taking into account that:

1/TA = 1/Ta1 + 1/Ta2 + 1/Ta3
1/TB = 1/Tb1 + 1/Tb2 + 1/Tb3

and you will see that it "works".

BTW, the case you want to deal with above, by extending my example
of your suggestion to the case where the lifetimes are different can be
dealt with by regrouping a different number of terms of like lifetimes in
the equation and then simply assigning them to a different set of attributes
of unlike lifetimes. The results will remain the same.

Cheers,

Ed Gerck






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA28759 for ietf-pkix-bks; Tue, 8 Jun 1999 03:09:15 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA28744 for <[e-mail]>; Tue, 8 Jun 1999 03:09:08 -0700 (PDT)
Received: by puma.baltimore.ie; id LAA07108; Tue, 8 Jun 1999 11:49:41 +0100 (GMT/IST)
Received: from ocelot.baltimore.ie(10.49.0.10) by puma.baltimore.ie via smap (4.1) id xma007081; Tue, 8 Jun 99 11:49:19 +0100
Received: from crown (crown.baltimore.ie [10.49.0.138]) by ocelot.baltimore.ie (8.8.7/8.8.5) with SMTP id LAA07035; Tue, 8 Jun 1999 11:10:18 +0100
Received: by localhost with Microsoft MAPI; Tue, 8 Jun 1999 11:12:12 +0100
Message-ID: <[e-mail]>
From: Tom Biskupic <[e-mail]>
To: "'Alex Deacon'" <[e-mail]>, "Ambarish Malpani [[e-mail]] (E-mail)" <[e-mail]>
Cc: "Ietf-Pkix (E-mail)" <[e-mail]>
Subject: RE: Possible clarification to RFC 2459
Date: Tue, 8 Jun 1999 11:12:11 +0100
Organization: Baltimore
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alex, Ambarish,Russ,

Something to take into account here is that some CAs may use the IDP for 
full CRLs in order to distinguish them from a ARLs. I see this as a 
requirement for CAs posting to directories in which case the CRL and ARL go 
into the same location and without this extension, are indistinguishable.

This makes the criteria somewhat more muddy as a partial CRL is then 
defined as one which has an IDP containing a DP that is not the same as the 
default location for the issuing CA. That is, the only way to tell if this 
is a partial CRL is that it has something in the IDP to say it was issued 
to somewhere different to the default location.

You could argue that splitting a CRL between a CRL/ARL is effectively 
partitioning however in most cases the question you want answered is 
'Should this CRL contain this end user certificate if it is revoked" and 
this criteria won't help.

Now if CDPs where being used just to allow full CRLs to be published to a 
URI or some other type of location (ie a full CRL published to a URI) then 
you have no way to tell at all.

Tom Biskupic

On Tuesday, June 08, 1999 4:07 AM, Alex Deacon [SMTP:[e-mail]] 
wrote:
>
> OK, on first though this sound like a reasonable way to specify a full 
CRL.
> Basically, what you are saying is that if a cert using application gets a
> cert which contains a CDP pointing to a particular partition, but for 
some
> reason this application only has a CRL which does not contain an IDP, 
then
> they can be confident that they can verify the status of the cert based 
on
> this CRL.
>
> Right?
>
> Alex
>
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[e-mail]]
> > Sent: Monday, June 07, 1999 3:06 PM
> > To: [e-mail]; [e-mail]
> > Subject: RE: Possible clarification to RFC 2459
> >
> >
> >
> > I agree with what Tom wants - would like to be able to
> > distinguish whether a CRL is a full or a partial CRL. Can we
> > add the following paragraph to section 5.2.5:
> >
> > A full CRL from/for a CA MUST NOT contain the
> > issuingDistributionPoint extension, unless it is an indirect CRL,
> > in which case, it MAY contain the issuingDistributionPoint
> > extension with only the indirectCRL field set to true.
> >
> > Would this work for most people? Any objections?
> > Ambarish
> >
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect					         650.567.5457
> > ValiCert, Inc.				
> > [e-mail]
> > 1215 Terra Bella Ave.		              http://www.valicert.com
> > Mountain View, CA 94043-1833
> >
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]On Behalf
> > > Of [e-mail]
> > > Sent: Monday, June 07, 1999 8:25 AM
> > > To: Ambarish Malpani; [e-mail]
> > > Subject: Possible clarification to RFC 2459
> > >
> > >
> > >      The current definition of Issuing Distribution Point
> > > leaves it relatively
> > > unclear whether the presence of the "DistributionPoint" field
> > > within this
> > > extension indicates that the CRL at that distribution point
> > > is a partial CRL.  I
> > > would like to suggest that the following text be added to RFC
> > > 2459 section
> > > 5.2.5:
> > >
> > >      Where the issuingDistributionPoint extension contains
> > > either a DN or an
> > > RDN, the distribution point SHOULD contain only certificates
> > > which contain a CRL
> > > Distribution Point extension one of whose DistributionPoint's
> > > contains the same
> > > value in the "distributionPoint" field.
> > >
> > >      To make it clear that CRL Distribution Point's support
> > > partitioning even
> > > for URL's, the following existing text in section 4.2.1.14
> > > could be modified as
> > > follows:
> > > [Old]     the URI is a pointer to the current CRL for the
> > > associated reasons and
> > > will be issued by the associated cRLIssuer.
> > > [New]     the URI is a pointer to a current CRL for the
> > > associated reasons for
> > > those certificates and will be issued by the associated
> > > cRLIssuer.  The CRL so
> > > referenced SHOULD contain only certificates whose CRL
> > > Distribution Point
> > > extension contains this URI and certificates not containing
> > > any CRL Distribution
> > > Point extension.
> > >
> > >           Tom Gindin
> > >
> > >
> > >
> > >
> > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA25922 for ietf-pkix-bks; Tue, 8 Jun 1999 01:24:48 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA25906 for <[e-mail]>; Tue, 8 Jun 1999 01:24:46 -0700 (PDT)
Received: from mcg.org.br (pm02-03.sac.verio.net [209.162.64.22]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id BAA18715; Tue, 8 Jun 1999 01:26:28 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 08 Jun 1999 01:17:01 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: PKIX <[e-mail]>, [e-mail]
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony Bartoletti wrote:

> The given formula "works" (assuming all component attributes have identical
> lifetimes.)

Tony:

I can't understand the "works" -- do you find a mistake in the results?

> I wanted to explore the more general case, where the component lifetimes
> are unequal, and to help define "degrees of redundancy".
>
> A simple (?) example:
>
>   Consider a certificate C over two attributes A and B with lifetimes given
>   by TA and TB, respectively.
>
>   Assuming no redundancy, we allow 1/TC = 1/TA + 1/TB.

You mean, there is no 100% redundancy? Because redundancy is NOT
a problem in the equation -- as I showed in my e-mail anterior and
you recognized when you wrote above "works" ;-))))

Of course, you cannot just *repeat* the *same* attribute two times
and expect that you have two attributes, in fact you would just one
attribute, no?

>   Suppose, upon closer inspection, we agree that attributes A and B are
>   themselves formed of components.  Specifically:
>
>         A = a1 and a2 and a3  (respective lifetimes Ta1, Ta2, Ta3)
>         B = b1 and b2 and b3  (respective lifetimes Tb1, Tb2, Tb3)
>
>   Note:  Attribute A is valid IFF all of a1, a2, a3 are valid, etc.
>
>   Continuing under assumptions of no redundancy, we still find
>
>         1/TC = 1/TA + 1/TB
>              = 1/Ta1 + 1/Ta2 + 1/Ta3 + 1/Tb1 + 1/Tb2 + 1/Tb3

You "forgot" to impose the conditions, derived directly by your
hypothesis:

1/TA = 1/Ta1 + 1/Ta2 + 1/Ta3
1/TB = 1/Tb1 + 1/Tb2 + 1/Tb3

>   Suppose a "final investigation" reveals that the components a1 and a2 of A
>   are precisely the components b1 and b2 of B.  Thus the certificate C
>   certifies exactly the components a1, a2, a3, b3.

Your affirmation does not make mathematical sense, Tony. What do you mean by

"the components a1 and a2 of A are precisely the components b1 and b2 of B."

Do you mean they are equal? So what? You affirmed before that:

 "Assuming no redundancy, we allow 1/TC = 1/TA + 1/TB"

so we know we are not dealing here with the *same* attributes that were
just repeated, like:

Attribute1 = 'tony'
Attribute2 = 'tony'

So,  your :"results" do not apply. But, it is a simple confusion. Calculate
again, taking into account that:

1/TA = 1/Ta1 + 1/Ta2 + 1/Ta3
1/TB = 1/Tb1 + 1/Tb2 + 1/Tb3

and you will see that it "works".

BTW, the case you want to deal with above, by extending my example
of your suggestion to the case where the lifetimes are different can be
dealt with by regrouping a different number of terms of like lifetimes in
the equation and then simply assigning them to a different set of attributes
of unlike lifetimes. The results will remain the same.

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA22999 for ietf-pkix-bks; Tue, 8 Jun 1999 00:17:19 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA22995 for <[e-mail]>; Tue, 8 Jun 1999 00:17:18 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id AAA12050; Tue, 8 Jun 1999 00:17:41 -0700 (PDT)
Received: from rhone (dhcp-3-116.engineering.valicert.com [192.168.3.116] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id AAA19173; Tue, 8 Jun 1999 00:18:43 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Alex Deacon'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Possible clarification to RFC 2459
Date: Tue, 8 Jun 1999 00:22:10 -0700
Message-ID: <000901beb17f$a034a440$[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
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Right on! (assuming that the CRL is currently valid, issued by
the right CA, has the right signature....)

Regards,
Ambarish

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


> -----Original Message-----
> From: Alex Deacon [mailto:[e-mail]]
> Sent: Monday, June 07, 1999 8:07 PM
> To: 'Ambarish Malpani'; [e-mail]; [e-mail]
> Subject: RE: Possible clarification to RFC 2459
> 
> 
> 
> OK, on first though this sound like a reasonable way to 
> specify a full CRL.
> Basically, what you are saying is that if a cert using 
> application gets a
> cert which contains a CDP pointing to a particular partition, 
> but for some
> reason this application only has a CRL which does not contain 
> an IDP, then
> they can be confident that they can verify the status of the 
> cert based on
> this CRL.
> 
> Right?
> 
> Alex
> 
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[e-mail]]
> > Sent: Monday, June 07, 1999 3:06 PM
> > To: [e-mail]; [e-mail]
> > Subject: RE: Possible clarification to RFC 2459
> > 
> > 
> > 
> > I agree with what Tom wants - would like to be able to
> > distinguish whether a CRL is a full or a partial CRL. Can we
> > add the following paragraph to section 5.2.5:
> > 
> > A full CRL from/for a CA MUST NOT contain the
> > issuingDistributionPoint extension, unless it is an indirect CRL,
> > in which case, it MAY contain the issuingDistributionPoint
> > extension with only the indirectCRL field set to true.
> > 
> > Would this work for most people? Any objections?
> > Ambarish
> >  
> > 
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect					         650.567.5457
> > ValiCert, Inc.				        
> > [e-mail]
> > 1215 Terra Bella Ave.		              
http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]On Behalf
> > Of [e-mail]
> > Sent: Monday, June 07, 1999 8:25 AM
> > To: Ambarish Malpani; [e-mail]
> > Subject: Possible clarification to RFC 2459
> > 
> > 
> >      The current definition of Issuing Distribution Point 
> > leaves it relatively
> > unclear whether the presence of the "DistributionPoint" field 
> > within this
> > extension indicates that the CRL at that distribution point 
> > is a partial CRL.  I
> > would like to suggest that the following text be added to RFC 
> > 2459 section
> > 5.2.5:
> > 
> >      Where the issuingDistributionPoint extension contains 
> > either a DN or an
> > RDN, the distribution point SHOULD contain only certificates 
> > which contain a CRL
> > Distribution Point extension one of whose DistributionPoint's 
> > contains the same
> > value in the "distributionPoint" field.
> > 
> >      To make it clear that CRL Distribution Point's support 
> > partitioning even
> > for URL's, the following existing text in section 4.2.1.14 
> > could be modified as
> > follows:
> > [Old]     the URI is a pointer to the current CRL for the 
> > associated reasons and
> > will be issued by the associated cRLIssuer.
> > [New]     the URI is a pointer to a current CRL for the 
> > associated reasons for
> > those certificates and will be issued by the associated 
> > cRLIssuer.  The CRL so
> > referenced SHOULD contain only certificates whose CRL 
> > Distribution Point
> > extension contains this URI and certificates not containing 
> > any CRL Distribution
> > Point extension.
> > 
> >           Tom Gindin
> > 
> > 
> > 
> > 
> 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA01612 for ietf-pkix-bks; Mon, 7 Jun 1999 20:05:28 -0700 (PDT)
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 UAA01596 for <[e-mail]>; Mon, 7 Jun 1999 20:05:23 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id UAA24796; Mon, 7 Jun 1999 20:05:44 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id UAA01557; Mon, 7 Jun 1999 20:06:37 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <LM3FKNC1>; Mon, 7 Jun 1999 20:06:37 -0700
Message-ID: <[e-mail]>
From: Alex Deacon <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Possible clarification to RFC 2459
Date: Mon, 7 Jun 1999 20:06:32 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

OK, on first though this sound like a reasonable way to specify a full CRL.
Basically, what you are saying is that if a cert using application gets a
cert which contains a CDP pointing to a particular partition, but for some
reason this application only has a CRL which does not contain an IDP, then
they can be confident that they can verify the status of the cert based on
this CRL.

Right?

Alex

> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Monday, June 07, 1999 3:06 PM
> To: [e-mail]; [e-mail]
> Subject: RE: Possible clarification to RFC 2459
> 
> 
> 
> I agree with what Tom wants - would like to be able to
> distinguish whether a CRL is a full or a partial CRL. Can we
> add the following paragraph to section 5.2.5:
> 
> A full CRL from/for a CA MUST NOT contain the
> issuingDistributionPoint extension, unless it is an indirect CRL,
> in which case, it MAY contain the issuingDistributionPoint
> extension with only the indirectCRL field set to true.
> 
> Would this work for most people? Any objections?
> Ambarish
>  
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect					         650.567.5457
> ValiCert, Inc.				        
> [e-mail]
> 1215 Terra Bella Ave.		              http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]On Behalf
> > Of [e-mail]
> > Sent: Monday, June 07, 1999 8:25 AM
> > To: Ambarish Malpani; [e-mail]
> > Subject: Possible clarification to RFC 2459
> > 
> > 
> >      The current definition of Issuing Distribution Point 
> > leaves it relatively
> > unclear whether the presence of the "DistributionPoint" field 
> > within this
> > extension indicates that the CRL at that distribution point 
> > is a partial CRL.  I
> > would like to suggest that the following text be added to RFC 
> > 2459 section
> > 5.2.5:
> > 
> >      Where the issuingDistributionPoint extension contains 
> > either a DN or an
> > RDN, the distribution point SHOULD contain only certificates 
> > which contain a CRL
> > Distribution Point extension one of whose DistributionPoint's 
> > contains the same
> > value in the "distributionPoint" field.
> > 
> >      To make it clear that CRL Distribution Point's support 
> > partitioning even
> > for URL's, the following existing text in section 4.2.1.14 
> > could be modified as
> > follows:
> > [Old]     the URI is a pointer to the current CRL for the 
> > associated reasons and
> > will be issued by the associated cRLIssuer.
> > [New]     the URI is a pointer to a current CRL for the 
> > associated reasons for
> > those certificates and will be issued by the associated 
> > cRLIssuer.  The CRL so
> > referenced SHOULD contain only certificates whose CRL 
> > Distribution Point
> > extension contains this URI and certificates not containing 
> > any CRL Distribution
> > Point extension.
> > 
> >           Tom Gindin
> > 
> > 
> > 
> > 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA18925 for ietf-pkix-bks; Mon, 7 Jun 1999 16:27:56 -0700 (PDT)
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 QAA18921 for <[e-mail]>; Mon, 7 Jun 1999 16:27:55 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id QAA23154; Mon, 7 Jun 1999 16:29:29 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 07 Jun 1999 16:28:59 -0700
To: Ed Gerck <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
Cc: PKIX <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:32 AM 6/5/99 -0700, you wrote:

>Thus, the first formula is
>
>  To = collective attribute lifetime = x years
>  T1 = T2 = ... = T100 = individual lifetime = 1 year
>
>and, to begin, suppose there is no collective yet:
>
>   1/T = 1/T1 + ... + 1/T100 => T = 1/100 year
>
>but, as redundancy is increased to the next notch, n individuals
>are lost to the collective. Thus, the second formula has less attributes
>to sum up and we obtain the partial expression:
>
>  1/T = 1/To + 1/T1 + ... + 1/T(100 - n) => T =  x/((100-n)*x +1) years
>
>and, as redundancy is further increased, there is a time when all
>individuals are lost to the collective and n = 100, so that we only
>have the collective to take into account:
>
>  1/T = 1/To = x years
>
>which is *also* the result we obtain by making n =100 in the partial
>expression for n above:
>
> T =  x/((100-n)*x +1) years => x/((100-100)*x +1) = x years
>

The given formula "works" (assuming all component attributes have identical
lifetimes.)

I wanted to explore the more general case, where the component lifetimes
are unequal, and to help define "degrees of redundancy".

A simple (?) example:

  Consider a certificate C over two attributes A and B with lifetimes given
  by TA and TB, respectively.

  Assuming no redundancy, we allow 1/TC = 1/TA + 1/TB.

  Suppose, upon closer inspection, we agree that attributes A and B are
  themselves formed of components.  Specifically:

	A = a1 and a2 and a3  (respective lifetimes Ta1, Ta2, Ta3)
	B = b1 and b2 and b3  (respective lifetimes Tb1, Tb2, Tb3)

  Note:  Attribute A is valid IFF all of a1, a2, a3 are valid, etc.

  Continuing under assumptions of no redundancy, we still find

	1/TC = 1/TA + 1/TB
	     = 1/Ta1 + 1/Ta2 + 1/Ta3 + 1/Tb1 + 1/Tb2 + 1/Tb3

  Suppose a "final investigation" reveals that the components a1 and a2 of A
  are precisely the components b1 and b2 of B.  Thus the certificate C
  certifies exactly the components a1, a2, a3, b3.

  Comparing the result to the one that assumed no redundancy, I summarize

	1/TC = 1/TA + 1/TB - SUM(1/Tci) for ci in INTERSECT(A,B)

	     = 1/TA + 1/TB - [ 1/Tb1 + 1/Tb2 ]

	     < 1/TA + 1/TB

  Thus   TC > 1/( 1/TA + 1/TB )

Now this result is not really different than the one you give above, where
increasing redundancy gradually reduces the population of elements.  But it
demonstrates the difficulty in practice.

Since the individual components may have differing lifetimes, it may matter
greatly, exactly which components are removed from the intersection.  Saying
"two out of six components were redundant, so use only four" would not suffice.

And, most importantly, in those (many) cases where no one has the time or
know-how to correctly identify the component attributes of A and B, but
rather applies historical "lifetimes" exhibited by A-like and B-like
attributes, there is no opportunity to adjust proactively the formula

	1/TC = 1/TA + 1/TB

Instead, one would just apply it, and soon discover that observed TC
does not agree with its predicted value (and thus surmise that there
must be redundancy at work somewhere.)

Comments?

___tony___

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18059 for ietf-pkix-bks; Mon, 7 Jun 1999 15:07:47 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18055 for <[e-mail]>; Mon, 7 Jun 1999 15:07:46 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id PAA09207; Mon, 7 Jun 1999 15:08:08 -0700 (PDT)
Received: from rhone (dhcp-3-116.engineering.valicert.com [192.168.3.116] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id PAA12792; Mon, 7 Jun 1999 15:09:09 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Problem with RFC 2459?
Date: Mon, 7 Jun 1999 15:12:36 -0700
Message-ID: <001a01beb132$d9cdb1d0$[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]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Russ,
    Here is a potential model a CA could assume, comply with
the spec and still produce partial CRLs without any of the
issuingDistributionPoint flags set:

If the CA partitions CRLs based on the serial number of the
certificate (say serialNumber %13). Now, the CA has 13 partial
CRLs, with onlyContainsUserCerts and onlyContainsCACerts set
to false and onlySomeReasons not set. How can an application
distinguish any of these 13 CRLs from a full CRL?

Regards,
Ambarish

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


> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Friday, June 04, 1999 3:02 PM
> To: Ambarish Malpani
> Cc: [e-mail]
> Subject: Re: Problem with RFC 2459?
> 
> 
> Ambarish:
> 
> The IDP has the following syntax:
> 
>    issuingDistributionPoint ::= SEQUENCE {
>         distributionPoint       [0] DistributionPointName OPTIONAL,
>         onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
>         onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
>         onlySomeReasons         [3] ReasonFlags OPTIONAL,
>         indirectCRL             [4] BOOLEAN DEFAULT FALSE }
> 
> If indirectCRL is false (the default case), then X.509-1993 says the
> following three things that taken together answer your question:
> 
> 1.  If onlyContainsUserCerts is true, the CRL only contains 
> revocations for
> end-entity certificates.
> 
> 2.  If onlyContainsCACerts is true, the CRL only contains 
> revocations for
> CA-certificates.
> 
> 3.  If onlySomeReasons is present, the CRL only contains 
> revocations for
> the identified reason or reasons, otherwise the CRL contains 
> revocations
> for all reasons.
> 
> Thus, if the onlyContainsUserCerts is false AND onlyContainsCACerts is
> false AND onlySomeReasons is absent AND indirectCRL is false, 
> then the CRL
> is complete.
> 
> Russ
> 
> 
> At 11:48 AM 6/3/99 -0700, Ambarish Malpani wrote:
> >
> >Hi Folks,
> >    Have a quick question about RFC 2459 and CRLDPs.
> >
> >If a CA issues both full CRLs and CRLDPs (which are partitioned
> >based on the serial number of the cert), how can an application
> >figure out whether it has the full CRL or a DP?
> >
> >I know a DP (if it is not the full CRL), must contain the Issuing
> >Distribution Point (IDP) extension. However, I believe most CAs
> >are putting the IDP extension within their full CRLs also. So,
> >is there any way for a application to figure out whether it has
> >the full CRL or just a DP?
> >
> >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 PAA17955 for ietf-pkix-bks; Mon, 7 Jun 1999 15:01:46 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17951 for <[e-mail]>; Mon, 7 Jun 1999 15:01:45 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id PAA09136; Mon, 7 Jun 1999 15:01:57 -0700 (PDT)
Received: from rhone (dhcp-3-116.engineering.valicert.com [192.168.3.116] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id PAA12655; Mon, 7 Jun 1999 15:02:59 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Possible clarification to RFC 2459
Date: Mon, 7 Jun 1999 15:06:26 -0700
Message-ID: <001701beb131$fcbd70a0$[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]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with what Tom wants - would like to be able to
distinguish whether a CRL is a full or a partial CRL. Can we
add the following paragraph to section 5.2.5:

A full CRL from/for a CA MUST NOT contain the
issuingDistributionPoint extension, unless it is an indirect CRL,
in which case, it MAY contain the issuingDistributionPoint
extension with only the indirectCRL field set to true.

Would this work for most people? Any objections?
Ambarish
 

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


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]On Behalf
> Of [e-mail]
> Sent: Monday, June 07, 1999 8:25 AM
> To: Ambarish Malpani; [e-mail]
> Subject: Possible clarification to RFC 2459
> 
> 
>      The current definition of Issuing Distribution Point 
> leaves it relatively
> unclear whether the presence of the "DistributionPoint" field 
> within this
> extension indicates that the CRL at that distribution point 
> is a partial CRL.  I
> would like to suggest that the following text be added to RFC 
> 2459 section
> 5.2.5:
> 
>      Where the issuingDistributionPoint extension contains 
> either a DN or an
> RDN, the distribution point SHOULD contain only certificates 
> which contain a CRL
> Distribution Point extension one of whose DistributionPoint's 
> contains the same
> value in the "distributionPoint" field.
> 
>      To make it clear that CRL Distribution Point's support 
> partitioning even
> for URL's, the following existing text in section 4.2.1.14 
> could be modified as
> follows:
> [Old]     the URI is a pointer to the current CRL for the 
> associated reasons and
> will be issued by the associated cRLIssuer.
> [New]     the URI is a pointer to a current CRL for the 
> associated reasons for
> those certificates and will be issued by the associated 
> cRLIssuer.  The CRL so
> referenced SHOULD contain only certificates whose CRL 
> Distribution Point
> extension contains this URI and certificates not containing 
> any CRL Distribution
> Point extension.
> 
>           Tom Gindin
> 
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA13568 for ietf-pkix-bks; Mon, 7 Jun 1999 10:46:48 -0700 (PDT)
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 KAA13562 for <[e-mail]>; Mon, 7 Jun 1999 10:46:42 -0700 (PDT)
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 NAA28379; Mon, 7 Jun 1999 13:48:28 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 07 Jun 1999 13:49:19 -0400
To: Anders Rundgren <[e-mail]>, "[e-mail]" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-ipki-ecdsa-01.txt
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <01BEB103.3F043090@HYDRA>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

These are very reasonable questions!

#1 ECC refers to the broader class of elliptic curve cryptographic
algorithms.  ECDSA is a specific ECC algorithm.  It is basically an ECC
analog to the Digital Signature Algorithm (DSA).

#2 The scope of this specification was formatting ECDSA keys in X.509
certificates and ECDSA signatures on certs and CRLs.  X9.62 was
sufficiently stable to support this scope.

We were waiting until X9.63 stabilized (X9.63 specifies key agreement and
key transfer algorithms) to address key management keys.  The same key
syntax will work for the forthcoming X9.63, so it should be an incremental
upgrade... same syntax *with* the optional cofactor, different key usage
bits.  (Signature syntax doesn't apply of course.)

X9.63 is getting close, so we will probably follow up with a spec for ECC
key management keys later this year.

Thanks,

Tim Polk

At 04:31 PM 6/7/99 +0200, Anders Rundgren wrote:
>Neophyte ECC / ECDSA Question:
>
>1.  ECC and ECDSA denote the same basic technology?
>
>2. How come the keyEncipherment, dataEncipherment, keyAgreement cannot be
>set in an ECDSA-compatible cert?  I.e. cannot be used for encryption?
>
>Sorry for these probably naive questions but those who never ask will
continue to be ignorant :-)
>
>Regards
>Anders Rundgren
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11712 for ietf-pkix-bks; Mon, 7 Jun 1999 08:24:54 -0700 (PDT)
Received: from smtp7.ny.us.ibm.com (smtp7.ny.us.ibm.com [198.133.22.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11707 for <[e-mail]>; Mon, 7 Jun 1999 08:24:45 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp7.ny.us.ibm.com (8.8.8/8.8.7) with ESMTP id LAA111530; Mon, 7 Jun 1999 11:26:41 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v1.8) with SMTP id LAA268096; Mon, 7 Jun 1999 11:25:48 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256789.0054BD22 ; Mon, 7 Jun 1999 11:25:34 -0400
X-Lotus-FromDomain: IBMUS
To: "Ambarish Malpani" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 7 Jun 1999 11:25:12 -0400
Subject: Possible clarification to RFC 2459
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

     The current definition of Issuing Distribution Point leaves it relatively
unclear whether the presence of the "DistributionPoint" field within this
extension indicates that the CRL at that distribution point is a partial CRL.  I
would like to suggest that the following text be added to RFC 2459 section
5.2.5:

     Where the issuingDistributionPoint extension contains either a DN or an
RDN, the distribution point SHOULD contain only certificates which contain a CRL
Distribution Point extension one of whose DistributionPoint's contains the same
value in the "distributionPoint" field.

     To make it clear that CRL Distribution Point's support partitioning even
for URL's, the following existing text in section 4.2.1.14 could be modified as
follows:
[Old]     the URI is a pointer to the current CRL for the associated reasons and
will be issued by the associated cRLIssuer.
[New]     the URI is a pointer to a current CRL for the associated reasons for
those certificates and will be issued by the associated cRLIssuer.  The CRL so
referenced SHOULD contain only certificates whose CRL Distribution Point
extension contains this URI and certificates not containing any CRL Distribution
Point extension.

          Tom Gindin




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11547 for ietf-pkix-bks; Mon, 7 Jun 1999 08:06:03 -0700 (PDT)
Received: from asec-md.com (ATHM-209-218-xxx-38.Home.net [209.218.80.38] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11543 for <[e-mail]>; Mon, 7 Jun 1999 08:06:02 -0700 (PDT)
Received: from server1.asec-md.com ([209.218.58.10]) by yukon.asec-md.com with ESMTP id <113794>; Mon, 7 Jun 1999 11:05:03 -0400
Received: by server1.asec-md.com with Internet Mail Service (5.0.1461.28) id <M3JGRRQM>; Mon, 7 Jun 1999 11:07:07 -0400
Message-ID: <[e-mail]>
From: "Gerretson, Jim" <[e-mail]>
To: "Sweigert, David" <[e-mail]>, "Donahue, Edward" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: DoD X.509 Certificate Policy
Date: Mon, 7 Jun 1999 10:55:53 -0400
X-Mailer: Internet Mail Service (5.0.1461.28)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The official answer is that DoD is NOT moving away from FORTEZZA cards.
I've seen some of their briefings and they are doing some interesting
things.  They are looking into smart cards and USB as well.

Jim Gerretson
ITSE Program Manager

-----Original Message-----
From: Sweigert, David [mailto:[e-mail]]
Sent: Monday, June 07, 1999 10:31 AM
To: Donahue, Edward; [e-mail]
Cc: [e-mail]
Subject: RE: DoD X.509 Certificate Policy


Ed:

[or anyone else]

The DOD X.509 Certificate Policy, Version 2.0 dated March 1999 discusses
a CRL validity period for class 4 certificates as DAILY.  If class 4 
certificates equate to FORTEZZA certificates, current policy (NAG-69B) 
now says 28 days.  Does anyone know if NAG-69/current policy has been
changed?

Is DOD moving away from FORTEZZA?  Is DOD looking at smart cards or
Universal Serial Bus?


Dave Sweigert
GTE Government Systems




-----Original Message-----
From: Donahue, Edward [mailto:[e-mail]]
Sent: Monday, June 07, 1999 8:32 AM
To: Sweigert, David; [e-mail]
Subject: RE: DoD X.509 Certificate Policy


Dave 

I believe these documents are official, if not final.  They are the versions
which people are currently using.  I have mentioned several times that the
NSFF web site does not have these current versions, but so far the site has
not been updated, so apparently I haven't mentioned it to the right people.


Ed Donahue 

> -----Original Message-----
> From:	Sweigert, David [SMTP:[e-mail]]
> Sent:	Friday, June 04, 1999 2:31 PM
> To:	[e-mail]
> Cc:	[e-mail]; [e-mail]
> Subject:	DoD X.509 Certificate Policy
> 
> It would be great to get any clarification from DoD on the following:
> 
> The Public Key Infrastructure Roadmap for DoD. 
>  
> Is the June 3, 1999, Version 2.0, Revision C available
> for distribution ?  Is it final ?
> 
> Is the DoD X.509 Certificate Policy, Version 2.0 dated March
> 1999 final ?
> 
> Thanks for your interest.
> 
> Dave Sweigert


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11524 for ietf-pkix-bks; Mon, 7 Jun 1999 08:03:59 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11520 for <[e-mail]>; Mon, 7 Jun 1999 08:03:57 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA22064 for <[e-mail]>; Mon, 7 Jun 1999 11:05:38 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA22055 for <[e-mail]>; Mon, 7 Jun 1999 11:05:37 -0400 (EDT)
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 LAA16709 for <[e-mail]>; Mon, 7 Jun 1999 11:05:41 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (avenger53.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Mon, 07 Jun 1999 11:04:29 -0400
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <LX8NT1YH>; Mon, 7 Jun 1999 11:05:27 -0400
Message-Id: <[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "Donahue, Edward" <[e-mail]>, [e-mail], "'Sweigert, David'" <[e-mail]>
Cc: [e-mail], "Heckman, Donald R." <[e-mail]>, "Wagner, Clark J." <[e-mail]>, "Jenkins, Michael J." <[e-mail]>
Subject: RE: DoD X.509 Certificate Policy
Date: Mon, 7 Jun 1999 11:05:16 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BEB0F7.2CA10696"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEB0F7.2CA10696
Content-Type: text/plain

David:

Responses in-line...

> ----------
> From: 	Sweigert, David[SMTP:[e-mail]]
> Sent: 	Monday, June 07, 1999 10:30 AM
> To: 	Donahue, Edward; [e-mail]
> Cc: 	[e-mail]
> Subject: 	RE: DoD X.509 Certificate Policy
> 
> Ed:
> 
> [or anyone else]
> 
> The DOD X.509 Certificate Policy, Version 2.0 dated March 1999 discusses
> a CRL validity period for class 4 certificates as DAILY.  If class 4 
> certificates equate to FORTEZZA certificates, current policy (NAG-69B) 
> now says 28 days.  
> 
The DoD X.509 Certificate Policy applies to Version 3 X.509 certificates
(FORTEZZA or non-FORTEZZA).  NAG-69B equates to Version 1 FORTEZZA
certificate implementations.

> Does anyone know if NAG-69/current policy has been
> changed?
> 
NAG-69 has not been changed to require daily CRL issuance.

> Is DOD moving away from FORTEZZA?  
> 
FORTEZZA based implementations remain one option for DoD network security
applications, and are expected to remain in use for some time.

> Is DOD looking at smart cards or
> Universal Serial Bus?
> 
Yes, though not as a near-term replacement for FORTEZZA.

Dave

> -----Original Message-----
> From: Donahue, Edward [mailto:[e-mail]]
> Sent: Monday, June 07, 1999 8:32 AM
> To: Sweigert, David; [e-mail]
> Subject: RE: DoD X.509 Certificate Policy
> 
> 
> Dave 
> 
> I believe these documents are official, if not final.  They are the
> versions
> which people are currently using.  I have mentioned several times that the
> NSFF web site does not have these current versions, but so far the site
> has
> not been updated, so apparently I haven't mentioned it to the right
> people.
> 
> 
> Ed Donahue 
> 
> > -----Original Message-----
> > From:	Sweigert, David [SMTP:[e-mail]]
> > Sent:	Friday, June 04, 1999 2:31 PM
> > To:	[e-mail]
> > Cc:	[e-mail]; [e-mail]
> > Subject:	DoD X.509 Certificate Policy
> > 
> > It would be great to get any clarification from DoD on the following:
> > 
> > The Public Key Infrastructure Roadmap for DoD. 
> >  
> > Is the June 3, 1999, Version 2.0, Revision C available
> > for distribution ?  Is it final ?
> > 
> > Is the DoD X.509 Certificate Policy, Version 2.0 dated March
> > 1999 final ?
> > 
> > Thanks for your interest.
> > 
> > Dave Sweigert
> 

------_=_NextPart_001_01BEB0F7.2CA10696
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: DoD X.509 Certificate Policy</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">David:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Responses =
in-line...</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D1 FACE=3D"MS Sans Serif">Sweigert, =
David[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D1 FACE=3D"MS Sans Serif">Monday, June 07, 1999 10:30 =
AM</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans Serif">Donahue, =
Edward; [e-mail]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans =
Serif">RE: DoD X.509 Certificate Policy</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ed:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">[or anyone else]</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The DOD X.509 Certificate Policy, =
Version 2.0 dated March 1999 discusses</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a CRL validity period for class 4 =
certificates as DAILY.&nbsp; If class 4 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certificates equate to FORTEZZA =
certificates, current policy (NAG-69B) </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">now says 28 days.&nbsp; </FONT>
</P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The DoD X.509 =
Certificate Policy applies to Version 3 X.509 certificates (FORTEZZA or =
non-FORTEZZA).&nbsp; NAG-69B equates to Version 1 FORTEZZA certificate =
implementations.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Does anyone know if NAG-69/current =
policy has been</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">changed?</FONT>
</P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">NAG-69 has not been =
changed to require daily CRL issuance.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Is DOD moving away from =
FORTEZZA?&nbsp; </FONT>
</P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">FORTEZZA based =
implementations remain one option for DoD network security =
applications, and are expected to remain in use for some =
time.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Is DOD looking at smart cards =
or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Universal Serial Bus?</FONT>
</P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Yes, though not as a =
near-term replacement for FORTEZZA.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Donahue, Edward =
[</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A></=
FONT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Monday, June 07, 1999 8:32 =
AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: Sweigert, David; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: RE: DoD X.509 Certificate =
Policy</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Dave </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I believe these documents are =
official, if not final.&nbsp; They are the versions</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">which people are currently =
using.&nbsp; I have mentioned several times that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">NSFF web site does not have these =
current versions, but so far the site has</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not been updated, so apparently I =
haven't mentioned it to the right people.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ed Donahue </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; From:Sweigert, David =
[SMTP:[e-mail]]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Sent:Friday, June 04, 1999 2:31 =
PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; To:&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Cc:&nbsp;&nbsp; =
[e-mail]; [e-mail]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; =
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DoD X.509 Certificate =
Policy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; It would be great to get any =
clarification from DoD on the following:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The Public Key Infrastructure =
Roadmap for DoD. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Is the June 3, 1999, Version =
2.0, Revision C available</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; for distribution ?&nbsp; Is it =
final ?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Is the DoD X.509 Certificate =
Policy, Version 2.0 dated March</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 1999 final ?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Thanks for your interest.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Dave Sweigert</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BEB0F7.2CA10696--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA11273 for ietf-pkix-bks; Mon, 7 Jun 1999 07:31:48 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA11269 for <[e-mail]>; Mon, 7 Jun 1999 07:31:46 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id QAA04988 for <[e-mail]>; Mon, 7 Jun 1999 16:33:24 +0200
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id QAA70525; Mon, 7 Jun 1999 16:33:21 +0200
Received: by HYDRA with Microsoft Mail id <01BEB103.3F043090@HYDRA>; Mon, 7 Jun 1999 16:31:51 +0200
Message-ID: <01BEB103.3F043090@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-ipki-ecdsa-01.txt
Date: Mon, 7 Jun 1999 16:31:48 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Neophyte ECC / ECDSA Question:

1.  ECC and ECDSA denote the same basic technology?

2. How come the keyEncipherment, dataEncipherment, keyAgreement cannot be
set in an ECDSA-compatible cert?  I.e. cannot be used for encryption?

Sorry for these probably naive questions but those who never ask will continue to be ignorant :-)

Regards
Anders Rundgren



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA11231 for ietf-pkix-bks; Mon, 7 Jun 1999 07:29:33 -0700 (PDT)
Received: from Newman.GSC.GTE.Com ([e-mail] [207.175.88.67]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA11221 for <[e-mail]>; Mon, 7 Jun 1999 07:29:24 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 4606"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #29038) with ESMTP id <[e-mail]> for [e-mail]; Mon, 7 Jun 1999 10:30:41 -0400 (EDT)
Received: by gscex01.ndhm.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <MFTPGXVP>; Mon, 07 Jun 1999 10:30:40 -0400
Content-return: allowed
Date: Mon, 07 Jun 1999 10:30:32 -0400
From: "Sweigert, David" <[e-mail]>
Subject: RE: DoD X.509 Certificate Policy
To: "Donahue, Edward" <[e-mail]>, [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed:

[or anyone else]

The DOD X.509 Certificate Policy, Version 2.0 dated March 1999 discusses
a CRL validity period for class 4 certificates as DAILY.  If class 4 
certificates equate to FORTEZZA certificates, current policy (NAG-69B) 
now says 28 days.  Does anyone know if NAG-69/current policy has been
changed?

Is DOD moving away from FORTEZZA?  Is DOD looking at smart cards or
Universal Serial Bus?


Dave Sweigert
GTE Government Systems




-----Original Message-----
From: Donahue, Edward [mailto:[e-mail]]
Sent: Monday, June 07, 1999 8:32 AM
To: Sweigert, David; [e-mail]
Subject: RE: DoD X.509 Certificate Policy


Dave 

I believe these documents are official, if not final.  They are the versions
which people are currently using.  I have mentioned several times that the
NSFF web site does not have these current versions, but so far the site has
not been updated, so apparently I haven't mentioned it to the right people.


Ed Donahue 

> -----Original Message-----
> From:	Sweigert, David [SMTP:[e-mail]]
> Sent:	Friday, June 04, 1999 2:31 PM
> To:	[e-mail]
> Cc:	[e-mail]; [e-mail]
> Subject:	DoD X.509 Certificate Policy
> 
> It would be great to get any clarification from DoD on the following:
> 
> The Public Key Infrastructure Roadmap for DoD. 
>  
> Is the June 3, 1999, Version 2.0, Revision C available
> for distribution ?  Is it final ?
> 
> Is the DoD X.509 Certificate Policy, Version 2.0 dated March
> 1999 final ?
> 
> Thanks for your interest.
> 
> Dave Sweigert


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA09744 for ietf-pkix-bks; Mon, 7 Jun 1999 04:37:09 -0700 (PDT)
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA09740 for <[e-mail]>; Mon, 7 Jun 1999 04:37:06 -0700 (PDT)
From: [e-mail]
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id NAA50938; Mon, 7 Jun 1999 13:37:21 +0200
Received: from d12mta02.de.ibm.com (d12mta01 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.7m1/NCO v1.8) with SMTP id NAA50878; Mon, 7 Jun 1999 13:37:46 +0200
Received: by d12mta02.de.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id C1256789.003FE196 ; Mon, 7 Jun 1999 13:37:45 +0200
X-Lotus-FromDomain: IBMIL@IBMDE
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 7 Jun 1999 14:37:25 +0300
Subject: Re: Assigning Roles to Strangers
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Regarding the collector:

The signature on collected certificates can be verified through the
issuer's public key and there is no need to authenticate the sending site.
More then that, we believe there will be central repositories that will
hold certificates, some will be given to everyone and some will be
protected through some access control system.

Regarding the X.509 format:

We chose to do our first prototype with X.509v3 certificates but other
formats (e.g. SPKI, Attribute Certificates) can be supported as well. The
only requirement is that each certificate has at least issuer, subject and
attributes.

Regarding the exclusion tag:

It is true that its impossible to make sure that there does not exist
anywhere a certificate of that type. However while the TrustEstablishment
(TE) server works hard to collect 'positive (inclusion)' certificates, it
does not do it for the 'negative (exclusuion)' certificates. We only check
our local collected DB for such certificates.

Regards,

Yosi Mass,
TrustEstablishment Project Manager,
IBM Haifa Research Lab, Tel Aviv Office

p.j. ponder writes:

>The function of the 'collector' seems to be dependent upon a secure DNS or
>some way of authenticating the sites which are visited to collect the
>missing certs.  I have only made a quick pass through the document and I
>may have missed something important.  If the collector acts on URLs then
>it is subject to spoofing and inherent weaknesses in the DNS.
>
>The message above seems to indicate that different forms of certificates
>may be used, the paper itself indicates X.50v3 only.  I'm not keen on
>X.509, for some of the same reasons that led to the development of SPKI,
>but I don't want to light off another religious battle on BER encoding and
>ASN.1 and etc.  I'll send some comments on that for 66 Swiss francs.
>
>In the example,
>
>|<!---- Second rule : a hospital recommended by at least 2 hospitals, and
>|there is no warning about it from any hospital --->
>|  <RULE>
>|    <INCLUSION ID="reco" TYPE="Recommendation" FROM="hospitals"
>|REPEAT=2></INCLUSION>
>|    <EXCLUSION ID="warn" TYPE="Warning" FROM="hospitals"></EXCLUSION>
>|      <FUNCTION>
>
>how does the 'exclusion' work without an exhaustive search of all hospital
>issuers or collectors?  Is there a central global repository of 'warnings'
>in this example, like CRLs?  I read the description of the 'exclusion'
>tag, but it escapes me how that would work in a practical sense.  Is it
>the same thing as saying there are no certificates anywhere where issuer =
>hospital that contain a warning about the subject hospital?  Does it mean
>that if there is a warning found in the local database or in certs we have
>already collected, then the subject hospital is excluded?  It would seem
>in a policy like the one in the example, that an affirmative action would
>be required on the part of the TE to go and see if there are any warnings,
>anywhere, that relate to that hospital.  Similar to a CRL?
>
>Based on a first reading, you seem to have taken elements from some of the
>better work being done and applied them in potentially interesting ways.
>I'll read it over again in the daylight.
>--
>pjp




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA09640 for ietf-pkix-bks; Mon, 7 Jun 1999 04:24:21 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA09634 for <[e-mail]>; Mon, 7 Jun 1999 04:24:00 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19115; Mon, 7 Jun 1999 07:24:22 -0400 (EDT)
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-ipki-ecdsa-01.txt
Date: Mon, 07 Jun 1999 07:24:21 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure  
                          Representation of Elliptic Curve Digital Signature
                          Algorithm (ECDSA) Keys and Signatures in Internet 
                          X.509 Public Key Infrastructure Certificates
	Author(s)	: L. Bassham, D. Johnson, W. Polk
	Filename	: draft-ietf-pkix-ipki-ecdsa-01.txt
	Pages		: 15
	Date		: 04-Jun-99
	
This is the first draft of a profile for specification of Elliptic
Curve Digital Signature Algorithm (ECDSA) keys in Internet Public Key
Infrastructure X.509 certificates. Please send comments on this
document to the [e-mail] mail list.

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA05192 for ietf-pkix-bks; Sun, 6 Jun 1999 22:49:01 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA05188 for <[e-mail]>; Sun, 6 Jun 1999 22:49:01 -0700 (PDT)
Received: from mcg.org.br (pm09-24.sac.verio.net [209.162.65.137]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id WAA04948; Sun, 6 Jun 1999 22:50:21 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sun, 06 Jun 1999 22:40:20 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: "'Ed Gerck'" <[e-mail]>, "'Andrew Probert'" <[e-mail]>, PKIX <[e-mail]>, [e-mail]
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
References: <D1A949D4508DD1119C8100400533BEDC1077B2@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan Lloyd wrote:

> In system enginnering for business enterprises there are
> doctrinal, operational, policy, procedural and human factors to consider
> - as well as system and detailed technical matters - eg implementation
> quality, deployment and scaleability, reliability issues.. I tend to
> work on these aspects..

Alan:

All these aspects can be usefully applied to *one* attribute at a time
for each set of policies. But not (in any meaningful way) to a certificate
that  is a mixed bag with all sorts of different attributes, implicit attributes,
etc. Even when that cert is  just a plain PKIX identity certificate. To say
you can apply the same policies *equally* to *all* the attributes is likewise
meaningless.

So, what you are saying only leaves you with the case of a certificate for
which you can't apply your set of policies unless it has only one set of
attributes. Not very useful.

But, this is where the certificate lifetime equation shows a solution. You simply
apply the doctrinal, operational, policy, procedural and human factors that you
want *for each* attribute, as they can be applied for each. Without treating an
apple like a speedboat. For each type of  attribute, a different policy -- e-mail
names are one thing and live and die like e-mail names, not like public-keys for
example. After you have the lifetimes *for each* attribute (including possible
subattributes you may need in order to cover the risks you consider
significant) them AND ONLY THEN you apply the equation I derived and
whip up the final result FOR THE CERTIFICATE.

So, looks like you got it backwards ...a simple confusion. You thought of
applying the equation first -- but, no. It is to be applied last. Of course, how
else would you get the attribute lifetimes to input into the equation? From
whom/what?

BTW, this is clearly explained in the inlined reference [1] in my original
posting, in many e-mails I and others worte here --  and even in the
very e-mail you are replying to:

 "Gerck's certificate lifetime equation requires the user to input their
 assumptions on each presented attribute validity lifetime (an average)
 of a *given* certificate, ..."

So, you are the equation user, what should you do? Input your assumptions
on each attribute lifetime -- even if you call your assumptions by a long name
such as "doctrinal, operational, policy, procedural and human factors".

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA02974 for ietf-pkix-bks; Sun, 6 Jun 1999 20:32:13 -0700 (PDT)
Received: from smtp.seeder.net.tw (smtp0.seeder.net [210.62.177.90]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA02966 for <[e-mail]>; Sun, 6 Jun 1999 20:32:11 -0700 (PDT)
Received: from ms2.seeder.net ([202.39.153.193]) by smtp.seeder.net.tw with ESMTP (IPAD 2.5) id 3167500 ; Mon, 07 Jun 1999 11:34:25 +0800
Message-ID: <[e-mail]>
Date: Mon, 07 Jun 1999 11:33:47 +0800
From: u8142010 <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Mutiple O and OU in the Distinguish Name
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Does DN containing mutiple O or OU make the ASN.1 parser have different
result? How about you recommendation of using mutiple O and OU in the
subject DN of certificates?

Rgs,
James Lam



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA18091 for ietf-pkix-bks; Sun, 6 Jun 1999 17:00:19 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA18081 for <[e-mail]>; Sun, 6 Jun 1999 17:00:05 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <MM4FLP2W>; Mon, 7 Jun 1999 10:01:38 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC1077B2@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>
Cc: "'Andrew Probert'" <[e-mail]>, PKIX <[e-mail]>, [e-mail]
Subject: RE: Summary, was Re: Every time ..., was Re: General formula
Date: Mon, 7 Jun 1999 10:01:38 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed - some comments

> -----Original Message-----
> From:	Ed Gerck 
> Sent:	Saturday, June 05, 1999 2:44 AM
> To:	Alan Lloyd
> Cc:	'Andrew Probert'; PKIX; [e-mail]
> Subject:	Summary, was Re: Every time ..., was Re: General formula
> 
> 
> 
> Alan Lloyd wrote:
> 
> >  For my three bobs worth, the fundamental issue is that a complex
> > problem like the lifetime of a lump of data cannot be solved by a
> simple
> > (or lightweight) solution or formula
> 
> Alan:
> 
> I feel that a summary is in order -- too many subjects and topics
> on this issue ... we need to see the forest in spite of the trees.
> I also include some comments to other msgs and will try to
> synthezise list arguments so far.
> 
> 1. never say never -- I mean, we don't have a dogma here, do we?
	Is this statement in relation to simple things dont solve
complex problems - if so please prove (operationally) otherwise.

> 2. The more you say it is impossible, the happier I feel ;-)
	Is this statement in relation to simple things dont solve
complex problems - if so please prove (operationally) otherwise. And I
did not say you cannot determine cert life time - Its a qualitative
thing. Some believe - take a set of assumptions from a data perspective
- add a formula or two - and hey presto - an answer pops out - which can
also look about right - from a perspective.

	In system enginnering for business enterprises there are
doctrinal, operational, policy, procedural and human factors to consider
- as well as system and detailed technical matters - eg implementation
quality, deployment and scaleability, reliability issues.. I tend to
work on these aspects..



> 3. As I commented before, I am thankful for your doubts -- they
> have helped me bring to the forefront issues such as Poisson and
> Erlang
> statistics. Even though I may not have been 100% successfull (it
> seems)
> to convince everyone, if my private mailbox can be proof then I have
> been at least partially successfull in pointing out that modelling is
> much,
> much better than guessing ;-)
> 
	Perhaps what is exact to you - ie a set of assumptions about
attributes and applying  formula - is exact. and that you call modelling
However, my view of  this issue is related to modelling operational
systems with the parameters as described above - and I expect that to be
more useful. I dont call what I do guessing . 

> 4. But, I also do not want to impose upon this list a course on
> poisson
> statistics modelling  -- just using the results is usually fine for
> all engineering
> purposes. Further, I take that current doubts from Tom and others can
> be
> solved by resorting to  textbooks, so I am trying to wait and see what
> happens in time on this regard.  Again, the equation does not have to
> be
> deduced before it is used ;-) It is already there and those that may
> feel
> more confortable with examples will be able to verify that it works;
> again,
> in their own due time and there is no pressure.
> 
> 5. If you don't trust the equation, then I suggest you *first* do the
> only
> thing available today -- wild guess the result. 
	Another approach is to ignore the equation. And do a full
operational system analysis - because is that,  what the customer wants
to know - and pay for..
> Then, I suggest you do
> calculate it. Then, I suggest you use whatever you feel is better  --
> the
> "wild guess" or the "wild calculation" ;-) (as you may call it). Then,
> I
> further suggest you wait out and check what happens in the practice.
> With all due respect to theory, this is IMO a far more significat test
> than pages and pages of equations -- paper is too flexible and,
> bytes too easily changed, as we all know ;-)
> 
> 6. If you do want to "wild calculate" then please do read the inlined
> reference [1] in my original posting -- it explains the modelling
> phase that
> *must* precede any lifetime calculation using that equation. As it was
> very
> timely remarked here yesterday by Andrew Probert:
> 
> "However for this, or any capacity planning exercise, real-world data
> and
> assumptions are input to the model."
> 
> Thus, slightly paraphrasing Andrew's following text, I may say:
> 
> "Gerck's certificate lifetime equation requires the user to input
> their
> assumptions on each presented attribute validity lifetime (an average)
> of a *given* certificate, when a single exponential decay is assumed
> for
> each attribute validity.  When this is not true for an attribute (eg,
> in the
> case of a square-function validty) but the attribute can be described
> by a piecewise exponential decay (as it generally can, at least
> approximately) then the user must define and assume enough delayed
> sub-attributes to that attribute so that the each sub-attribute
> validity
> function is given by a single exponential decay in its time slot *and*
> the user must also consider the resulting piecewise application of the
> certificate lifetime equation -- so that in each time slot, all
> attributes
> and sub-attributes are given by single exponential decays.
> 
	WoW - and groan...
> Alternatively, the user can input what certificate lifetime is
> desired,
> for a given set of operational conditions, to derive a maximum number
> of attributes of equal lifetime or a mix of attributes of different
> lifetimes.
> The user does not need to make any assumption about attribute
> dependency besides the trivial case of not using fully redundant
> (whatever this may mean in the operational context) attributes; such
> as repeatingly using the same attribute lifetime in the equation if
> the
> attribute happens to repeated verbatim in the certificate -- since the
> attribute is essentially "one" if simply repeated."
> 
> Hope it is clearer.
> 
	No - its all missed the point - A certficate lifetime ( its
validy and usefulness) also depends on the business and operational
context it lives in..

	A theory about a certificate is just that - for a theoretical
and limited world . If that is useful to you then so be it. It is not
very useful to me because theory is about 10% of my world.

	May I also say that a directory system is about distributed,
object oriented, name based transaction systems - on which (distributed)
PKI and certificate functions are applied.. It is a new approach and
tool set to engineering distributed systems - ie. not just as
client-servers, or applications with databases or simple protocols..
When new tools arrive on the scene - the job gets done differently,
designs get done differently and new theories should be applied...

	just thoughts.
	regards alan

> Cheers,
> 
> Ed Gerck
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA14105 for ietf-pkix-bks; Sun, 6 Jun 1999 04:44:55 -0700 (PDT)
Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA14101 for <[e-mail]>; Sun, 6 Jun 1999 04:44:51 -0700 (PDT)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id LAA28868; Sun, 6 Jun 1999 11:46:12 GMT
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id MAA12815; Sun, 6 Jun 1999 12:46:15 +0100
Message-ID: <[e-mail]>
Date: Sun, 06 Jun 1999 12:46:02 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: Alan Lloyd <[e-mail]>, Bob Blakley <[e-mail]>, Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: Re: Every time ..., was Re: General formula
References: <D1A949D4508DD1119C8100400533BEDC107795@DSG1> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed Gerck wrote:
> 
> Ben Laurie wrote:
> 
> > Ed Gerck wrote:
> > > This also means that if you call someone and it is busy, you could call
> > > right afterwards (just add the round-trip total delay time -- say, 5 sec)
> > > and your sucess rate should be the same as if you would wait some
> > > minutes (as people normally do).
> > >
> > > The reason in both cases is simple -- since phone statistics is given by
> > > a Poison distribution and you don't know when the conversation actually
> > > *started*, its end does not depend on the duration of your observation.
> >
> > I don't believe this for a moment. To take an extreme example, if people
> > make, on average, 1 phone call a year, with a mean duration of 1 minute,
> > then it is intuitively obvious that if I wait a day after they are busy,
> > I have an almost 100% chance that they won't be busy,
> 
> Ben Laurie:
> 
> Is this how people really use the phone where you live? Is this "phone
> statistics"? C'mon, give me a break-- and realize that the statistics of
> your "extreme example" (what an understatement) is not even given by
> a Poisson pdf.

That's the whole point: phone statistics don't follow a Poisson pdf for
an individual user. The Poisson pdf applies to the phone system as a
whole (i.e. the combined statistics for all users). Naturally for an
individual user the call frequency and duration are unrelated (i.e. not
Poisson).

> 
> > whereas 5 seconds
> > later the chances are noticably less than 100%. Of course, I believe the
> > second statement, but the first is not a consequence of it, IMNSHO.
> >
> > You're just making this stuff up as you go along, aren't you?
> 
> You remind me of a guy that drowned in a lake that had just one inch
> of water depth, on average. Just too bad he did not realize it was an
> average, though. Or, even, what an average was.
> 
> Since phone traffic statistic is hardly on-topic here, I might help you off
> list if you consider this important for your understanding of certificate
> lifetimes.
> 
> And, Ben, next time you don't understand something, just ask and say what
> part of my text you did not understand. You don't need to become aggressive
> in order to receive my reply.

But I did understand it, I simply don't believe it is correct. In
particular, the statement "since phone statistics is given by a Poison
distribution" is incorrectly used to support an argument about a single
phone user.

However, I do apologise to you and the list for the tone I used.

Cheers,

Ben.

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

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06483 for ietf-pkix-bks; Sat, 5 Jun 1999 08:14:58 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06479 for <[e-mail]>; Sat, 5 Jun 1999 08:14:57 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id IAA01011; Sat, 5 Jun 1999 08:12:49 -0700 (PDT)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 04 Jun 1999 18:02:23 -0400
To: "Ambarish Malpani" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Problem with RFC 2459?
Cc: [e-mail]
In-Reply-To: <006901beadf1$be7b2e60$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ambarish:

The IDP has the following syntax:

   issuingDistributionPoint ::= SEQUENCE {
        distributionPoint       [0] DistributionPointName OPTIONAL,
        onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
        onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
        onlySomeReasons         [3] ReasonFlags OPTIONAL,
        indirectCRL             [4] BOOLEAN DEFAULT FALSE }

If indirectCRL is false (the default case), then X.509-1993 says the
following three things that taken together answer your question:

1.  If onlyContainsUserCerts is true, the CRL only contains revocations for
end-entity certificates.

2.  If onlyContainsCACerts is true, the CRL only contains revocations for
CA-certificates.

3.  If onlySomeReasons is present, the CRL only contains revocations for
the identified reason or reasons, otherwise the CRL contains revocations
for all reasons.

Thus, if the onlyContainsUserCerts is false AND onlyContainsCACerts is
false AND onlySomeReasons is absent AND indirectCRL is false, then the CRL
is complete.

Russ


At 11:48 AM 6/3/99 -0700, Ambarish Malpani wrote:
>
>Hi Folks,
>    Have a quick question about RFC 2459 and CRLDPs.
>
>If a CA issues both full CRLs and CRLDPs (which are partitioned
>based on the serial number of the cert), how can an application
>figure out whether it has the full CRL or a DP?
>
>I know a DP (if it is not the full CRL), must contain the Issuing
>Distribution Point (IDP) extension. However, I believe most CAs
>are putting the IDP extension within their full CRLs also. So,
>is there any way for a application to figure out whether it has
>the full CRL or just a DP?
>
>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 AAA27736 for ietf-pkix-bks; Sat, 5 Jun 1999 00:40:06 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA27732 for <[e-mail]>; Sat, 5 Jun 1999 00:40:05 -0700 (PDT)
Received: from mcg.org.br (pm02-09.sac.verio.net [209.162.64.28]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id AAA04378; Sat, 5 Jun 1999 00:41:31 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 05 Jun 1999 00:32:08 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: PKIX <[e-mail]>, [e-mail]
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony Bartoletti wrote:

> Ed,
> [snip]
>
>
> But perhaps the problem is that I cannot find REAL variables that
> behave this way.  As hard as I tried, I could only come up with
> examples that support your formula.

that is not bad ... to agree is also valid ;-)

> To wit:
>
>    Consider a very old stick of dynamite, so unstable that it
>    may self-detonate at any time, with an expected life of 1 year.
>
>    Now consider a box of 100 such sticks.  IN ISOLATION, each
>    stick has expected lifetime 1 year.  But given 100 such sticks,
>    the likelyhood that at least one stick will detonate within a
>    weeks time is rather large.  So, packaged together in the box,
>    the collection of dynamite sticks will likely not last a week.
>    (When one of them goes boom, it is almost a certainty that the
>    others will follow!)

I think this is a very illuminating example ;-)

Indeed, a certificate behaves this way -- after all, any attribute that is
in the cert....  is there because it is needed and the cert does "explode"
if any attribute "explodes". At least, it will "explode" as a whole, though
it may survive in "pieces".

Your other question (attribute redundancy) depends on the assumed
redudancy model. In the model  I suggested in my former reply to you,
the number of *effective* attributes is reduced as the inter-attribute
redundancy is increased -- so that when inter-attribute redundancy
is 100%, the number of attributes is only one and that is why 1/T =
1/To.

This redundancy model has some real-world significance. It models
a group that gradually loses individual identities by "quantum jumps"
into a collective identity, which is the final collective attribute. In other
words, as you increase redundancy, the number of individuals will
steadly decrease until only the collective is left. Thus, we need to take
into account also *that* attribute lifetime, the "collective attribute
lifetime". Which can have, interestingly enough, the same lifetime,
a lower lifetime or even a higher lifetime than each individual
attribute. Thus, the first formula is

  To = collective attribute lifetime = x years
  T1 = T2 = ... = T100 = individual lifetime = 1 year

and, to begin, suppose there is no collective yet:

   1/T = 1/T1 + ... + 1/T100 => T = 1/100 year

but, as redundancy is increased to the next notch, n individuals
are lost to the collective. Thus, the second formula has less attributes
to sum up and we obtain the partial expression:

  1/T = 1/To + 1/T1 + ... + 1/T(100 - n) => T =  x/((100-n)*x +1) years

and, as redundancy is further increased, there is a time when all
individuals are lost to the collective and n = 100, so that we only
have the collective to take into account:

  1/T = 1/To = x years

which is *also* the result we obtain by making n =100 in the partial
expression for n above:

 T =  x/((100-n)*x +1) years => x/((100-100)*x +1) = x years

Note thus that there is a progressive change from "1 year" to "x years",
going over  x/((100-n)*x +1) years, as redundancy is varied from 0%
to 100%. However, as I wrote above, one may have x >1, x < 1 or
x =1 -- as a function of the operational  context.


Is this what you had in mind?

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA03438 for ietf-pkix-bks; Fri, 4 Jun 1999 19:12:35 -0700 (PDT)
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 TAA03430 for <[e-mail]>; Fri, 4 Jun 1999 19:12:34 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id TAA12243; Fri, 4 Jun 1999 19:13:59 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 04 Jun 1999 19:13:32 -0700
To: Ed Gerck <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
Cc: PKIX <[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
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed,

Apologies for being somewhat imprecise (and perhaps a little dense)
but I still fail to see how T can approach To.

I know that terms like "almost perfectly redundant or dependent"
are vague, so let me try to define "X almost redundant to Y" to
mean that the probability that X changes (becomes invalid) while
Y does not change can be considered very small.  Indeed, smaller
by orders of magnitude when compared to the size of the set of
variables to which the phrase "almost redundant" applies to every
pair.

Now if I consider 100 such variables, and independently assess
each to have an expected lifetime of 1 year, then I get

   To = T1 = T2 = ... = T99 = 1 (year)
and
   1/T = 1/To + 1/T1 + ... + 1/T99
so
   1/T = 100, T = 1/100  (not at all close to To = 1)

But perhaps the problem is that I cannot find REAL variables that
behave this way.  As hard as I tried, I could only come up with
examples that support your formula.  To wit:

   Consider a very old stick of dynamite, so unstable that it
   may self-detonate at any time, with an expected life of 1 year.

   Now consider a box of 100 such sticks.  IN ISOLATION, each
   stick has expected lifetime 1 year.  But given 100 such sticks,
   the likelyhood that at least one stick will detonate within a
   weeks time is rather large.  So, packaged together in the box,
   the collection of dynamite sticks will likely not last a week.
   (When one of them goes boom, it is almost a certainty that the
   others will follow!)

But this is a strange kind of "strong dependency", and not the kind
I intend by "almost redundant".  In the dynamite example, the
"linkage" of lifetimes is one of causality.  If one stick goes,
then the others follow as an effect.  And if, at time t, one of the
sticks is still intact, it is almost certainly because none of the
other sticks have detonated.

Perhaps what I intend by "almost redundant" is not a reality?
Informationally, a bit is either redundant, or not (boolean).

Comments?

___tony___


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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA29759 for ietf-pkix-bks; Fri, 4 Jun 1999 17:33:25 -0700 (PDT)
Received: from smtp.seeder.net.tw (smtp1.seeder.net [210.62.177.91]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA29755 for <[e-mail]>; Fri, 4 Jun 1999 17:33:23 -0700 (PDT)
From: [e-mail]
Received: from blues ([202.39.153.193]) by smtp.seeder.net.tw with SMTP (IPAD 2.5) id 4366100 ; Sat, 05 Jun 1999 08:35:27 +0800
Message-ID: <005901beaeeb$39375df0$[e-mail]>
To: <[e-mail]>
Subject: Fw: authorityKeyIdentifier and subjectkeyIdentifier inplement in the real  case or model
Date: Sat, 5 Jun 1999 08:34:50 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

What attributes of  athorityKeyIdentifier do you put, keyIdentifier,  or
authorityCertIssuer and authorityCertSerialNumber?
In the end user's certificates, does subjectKeyIndetifier have its purpose
or function to support the cert verification or trading security? In waht
situation will make the subjectKeyIdentifier useful?

Rgs,

Jame Lam.
----- Original Message -----
From: Jim Schaad (Exchange) <[e-mail]>
To: 'u8142010' <[e-mail]>; <[e-mail]>
Sent: Saturday, June 05, 1999 2:17 AM
Subject: RE: authorityKeyIdentifier and subjectkeyIdentifier inplement in
the real case or model


> I can really only answer this question for how Microsoft is currently
doing
> this, but atleast some people in Microsoft have bought into SKI/AKI very
big
> time.
>
> The Microsoft Certificate Servers in Win2000 will put AKI and SKI values
> into all certificates issued by default.  The Microsoft code does not
appear
> to match either of the RFC algorithms for computing the SKI value, but is
> all internally consistent about how it does that computation.  I believe
> that you can actually put an SKI value into a certificate requestion and
the
> server will honor it.
>
> The chaining code used on the new Microsoft products (IE 5.0 and Win2000
> atleast) is very strong into doing chaining with AKI values, to the extent
> that it will ignore all Issuer/Subject chaining if the AKI extension
exists
> in a certificate.  I personally have yet to decide if this is the correct
> behavior, but that is not one of the areas over which I have a large
amount
> of control.
>
> So,
> -- AKI and SKI are implemented in the real world.
> -- If a certificate has an AKI, but the corresponding SKI is missing there
> may be problems in doing the chaining for some products. (I think this is
a
> fault in the products and they should be falling back to name chaining if
no
> matches are found.)
> -- If both are missing then everybody falls back to the good old name
> chaining code.
>
> jim
>
>
> -----Original Message-----
> From: u8142010 [mailto:[e-mail]]
> Sent: Friday, June 04, 1999 2:59 AM
> To: [e-mail]
> Subject: authorityKeyIdentifier and subjectkeyIdentifier inplement in
> the real case or model
>
>
> Hi:
> I read the X.509 V3 document and felt some confusing with
> authorityKeyIdentifier and subjectKeyIdentifier.
> Does authorityKeyIdentifier and subjectkeyIdentifier inplement in the
> real case or model, and how to implement the flow?
> If without subjectkeyIdentifier, will verification of client's certs be
> confused or fail? And in what situation it happens?
>
> Best Regards,
> James L.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA28943 for ietf-pkix-bks; Fri, 4 Jun 1999 16:26:28 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA28939 for <[e-mail]>; Fri, 4 Jun 1999 16:26:26 -0700 (PDT)
Received: from mcg.org.br (pm05-46.sac.verio.net [209.162.64.206]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id QAA21732; Fri, 4 Jun 1999 16:27:49 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 04 Jun 1999 16:18:18 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony Bartoletti wrote:

> At 09:53 AM 6/4/99 -0700, Ed Gerck wrote:
>
> [snip]
>
> >Thus, slightly paraphrasing Andrew's following text, I may say:
>
> [snip]
>
> >The user does not need to make any assumption about attribute
> >dependency besides the trivial case of not using fully redundant
> >(whatever this may mean in the operational context) attributes; such
> >as repeatingly using the same attribute lifetime in the equation if the
> >attribute happens to repeated verbatim in the certificate -- since the
> >attribute is essentially "one" if simply repeated."
> >
> >Hope it is clearer.
> >
> >Cheers,
> >
> >Ed Gerck
>
> But is this "trivial case" always obvious?

Tony:

Good question. The answer is indeed a NO (as you imply) because of
the caveat above "(whatever this may mean in the operational context)".
It is trivial (a word often used in science to mean that the math is easy)
since you have nothing to calculate ... but deciding it may not be obvious.

For example, some postings ago you presented the following interesting
case:

T> Consider certifying my following attributes:
T>
T> 1.  First Name = "Anthony"
T>
T> 2.  First Name Writ Backward = "ynohtnA"
T>
T> 3.  First Name all in caps = "ANTHONY"

which you thought (in your operational context) to be 100% redundant.
However, I provided a different operational context (perverted?) where
you could have reached a different conclusion:

E> For example, if those 3 attributes were to be interpreted as three different
E> things as viewed from your computer (as the observer):

E> 1. "Anthony" is your login
E> 2. "ynohtnA" is your initial password
E> 3. "ANTHONY" is your email address at the maihost.
E>
E> Now, of course, each one of them has a different meaning and denotes
E> a different entity to the observer (the computer) -- and each one is also
E> quite independent in their lifetimes.

As I hinted then, we need to recognize that 100% redundant terms carry no
information (in IT terms). Thus, there is no sense in distinguishing among
them if they are indeed 100% redundant. So, they should NOT be
included in the equation  -- this is the simple answer.

Why? Because the equation 1/T = 1/T1 + .. +1/TN was derived *for
each* attribute that can be *recognized*. In other words, if there is no
information (surprise) for an attribute, it must not be counted -- since it
was already counted.

However, and here lies that subtle (so, certainly also not obvious) point,
the measurement of information (hence, redundancy) depends on the
observer -- as I showed then using your own example (and, copied
above).

> This issue is rarely one
> where we disagree axiomatically with statements like "Under these
> premises, this formula holds true".  Rather, the disagreements arise
> in assuming particular case data satisfy the formula's premises.

Yes, and this must be very clear to the user, as I commented in my
sixth point in this thread (previous msg):

"Gerck's certificate lifetime equation requires the user to input their
assumptions on each presented attribute validity lifetime (an average)
of a *given* certificate, when a single exponential decay is assumed for
each attribute validity.  When this is not true for an attribute (eg, in the
case of a square-function validty) but the attribute can be described
by a piecewise exponential decay (as it generally can, at least
approximately) then the user must define and assume enough delayed
sub-attributes ..."

In all, the "equation user" is central. And, most surely *different* users will
disagree! But, how can that be possible? Or, useful? Because we are
dealing here with an intersubjective evaluation -- much like the medical
diagnosis of a patient, which, acceptably, is not unique. See "intersubjective"
in http://www.mcg.org.br/trustdef.htm for definition and examples.

Mind you, the same applies to the calculation of entropy in Physics.
Without wishing to open another can of worms (not this time), it
is entirely possible that two competent physicists justifiedly disagree
on an entropy calculation. And yet, Thernodynamics is a very useful
science.

> And "verbatum repetition" need not characterize "perfect redundancy".
> My silly example:
>
> We certify that person X is named "fred", person Y is named "john".
>
> Fred's cert has one attribute:
>
> 1   Person's name = fred
>
> John's cert has 5 attributes:
>
> 1   Person's name = fred

simple mistype:

1   Person's name = john

> 2   First letter of person's name  = j  (or first letter of attribute 1)
> 3   second letter of person's name = o
> 4   Third letter of person's name  = h
> 5   Fourth letter of person's name = n
>

Your example is not silly -- it is actually much more difficult than several
very complicated  examples I have seen.

> I would love to see example lifetimes assigned to these attributes,
> and how the formula might be applied.  Should the second certificate
> have a shorter lifetime?

If both have the same operational context, I can safely say that
they should have the same a priori lifetime.

> Can we "hide" redundancy even further?

;-) Well, there are many things that you have "hidden" already in
that example -- just look at the whole backward trust chain you
are taking at face value even for that declaration:

person  X is named "fred"

not to mention the validity of the CA root key, for example
(which is NOT part of the cert's *visible* attributes).
See also my previous comments to Bob Jueneman on this:

E> The a priori decay of trust with time is what makes
E> the attribute validity decay for the a priori determination
E> of its lifetime. This also shows that a certificate has many
E> unseen attributes, if you recall the list I used to discuss
E> the topics, which will nonetheless reduce its lifetime. One
E> example, of several discussed in
E> http://www.mcg.org.br/cert.htm , is the validity of the CA
E> signing certificate -- which is not mentioned in the
E> subscriber certificate as an attribute but can render it
E> invalid if the CA cert expires or is revoked before the
E> subscriber's certificate lifetime expires.

and, as I commented to Peter Williams on this:

E> As exemplified above, the *same* certificate could afford
E> increased lifetimes in the progression of the different
E> contexts presented -- even legally. And, in all cases,
E> the same lifetime equation would apply, though with
E> a different number of attribute lifetimes and respective
E> values.

> Yes, almost anyone can see the strict dependency of attribute 1 with
> attributes 2 .. 5 in the second cert.

Not everyone will see it in the same way, though. For example,
if that cert was created *that* way, then it may be verifying the
correct decoding of r-p's UNICODE platform when (for some
lamguages) there may be more than one coding for a single word,
though each single letter codes uniquely.

Again, it depends (as we both already agreed in this thread) on the
operational context.

>  But it seems intuitive that
> in cases where attributes only "tend toward" perfect dependency, the
> formula must yield a value that "tends toward" the value of any single
> attribute.

Yes, for sure -- for that *same* operational context though

> I wish I could construct an example for (say) 100 "almost dependent"
> attributes, each with expected lifetime t.  As "almost dependent" tends
> toward perfection, intuition says that the collection must have an
> expected lifetime that approaches t. I fail to see how the formula
> can behave so.

There are two different issues here (see my sixth point,before, at
the end):

1. Direct use: The equation does not calculate attribute lifetime -- it
calculates the average certificate lifetime *given* all the attribute
lifetimes which the user has decided upon. Then, simply, the
certificate lifetime will change (increasing *or* decreasing) as
you increase the inter-attribute dependency from "almost
dependent" to "100% dependent".

2. Inverse use (your case, above): You have a given certificate
lifetime you want and you investigate how many "almost dependent"
attributes you need in order to obtain  lifetime To -- as a function
of what you mean by "almost dependent". As you write the formula
starting with attribute 1, the certificate lifetime must decrease with
each term you add for that specific value of redundancy -- so you
must then stop adding attributes when you are in a neighborhood
of the desired lifetime To. Now, as you do various tests (note, it is
you that inputs the attribute lifetimes) and  increase inter-attribute
redundancy, each individual attribute lifetime  will change and this
will allow the inverse of the sum of their inverses (ie, certificate
lifetime T) to also change until To is reached when you have
only that *one* attribute (100% redundancy) and 1/T = 1/To,
so that T = To.

Comments?

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA26561 for ietf-pkix-bks; Fri, 4 Jun 1999 13:20:48 -0700 (PDT)
Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26557 for <[e-mail]>; Fri, 4 Jun 1999 13:20:47 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail02-ewr.pilot.net with ESMTP id QAA25104; Fri, 4 Jun 1999 16:22:15 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id QAA23273; Fri, 4 Jun 1999 16:22:14 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256786.006F1D9F ; Fri, 4 Jun 1999 16:13:40 -0400
X-Lotus-FromDomain: FDC
To: Ed Gerck <[e-mail]>
cc: PKIX <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 4 Jun 1999 13:20:13 -0700
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

... i recollect number of people in the early 90s commenting about the
networking types in the x.500 meetings re-inventing 1960s database technology.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA26422 for ietf-pkix-bks; Fri, 4 Jun 1999 12:59:20 -0700 (PDT)
Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA26418 for <[e-mail]>; Fri, 4 Jun 1999 12:59:19 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail02-ewr.pilot.net with ESMTP id QAA18457; Fri, 4 Jun 1999 16:00:46 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id QAA21794; Fri, 4 Jun 1999 16:00:45 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256786.006D24D6 ; Fri, 4 Jun 1999 15:52:08 -0400
X-Lotus-FromDomain: FDC
To: Ed Gerck <[e-mail]>
cc: PKIX <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 4 Jun 1999 12:58:11 -0700
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>From the AADS/business standpoint ... there is alwas an account record someplace
containing a bunch of fields and the certificate contains R/O replication from
some set of those fields (taken at some point in time). The question then is
two-fold ... 1) frequency/probability that specific information is changed in
the master account record and 2) procedures/processes of propogating
invalidation/update signals to all the locations containing read-only copies
(and 3) discontinuities
introduced with latency in the invalidate/update signals).

This characterization has been extensively modeled for cpu caches, database
caches, replicated databases, filesystem caches, and replicated filesystems.
Modeling scenerios are typically master/slave (master/original location persists
over long duration with one or more read/only copies), single writer (only one
master at a moment, but it may float), and multiple writers. Certificates tend
to most closely resemble master/slave ... with the account record at the
certificate issuer representing the "master copy" (with the number of places a
certificate information replication occuring potentially arbritarily large).
Sometimes the database models will also look at things like duration and size of
information inconsistency and the effect on correct operation (although this
tends to be more data/application sensitive).




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25795 for ietf-pkix-bks; Fri, 4 Jun 1999 11:53:52 -0700 (PDT)
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 LAA25791 for <[e-mail]>; Fri, 4 Jun 1999 11:53:51 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id LAA18469; Fri, 4 Jun 1999 11:54:43 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 04 Jun 1999 11:54:16 -0700
To: Ed Gerck <[e-mail]>, PKIX <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Summary, was Re: Every time ..., was Re: General formula
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 09:53 AM 6/4/99 -0700, Ed Gerck wrote:

[snip]

>Thus, slightly paraphrasing Andrew's following text, I may say:

[snip]

>The user does not need to make any assumption about attribute
>dependency besides the trivial case of not using fully redundant
>(whatever this may mean in the operational context) attributes; such
>as repeatingly using the same attribute lifetime in the equation if the
>attribute happens to repeated verbatim in the certificate -- since the
>attribute is essentially "one" if simply repeated."
>
>Hope it is clearer.
>
>Cheers,
>
>Ed Gerck

But is this "trivial case" always obvious?  This issue is rarely one
where we disagree axiomatically with statements like "Under these
premises, this formula holds true".  Rather, the disagreements arise
in assuming particular case data satisfy the formula's premises.

And "verbatum repetition" need not characterize "perfect redundancy".
My silly example:

We certify that person X is named "fred", person Y is named "john".

Fred's cert has one attribute:

1   Person's name = fred

John's cert has 5 attributes:

1   Person's name = fred
2   First letter of person's name  = j  (or first letter of attribute 1)
3   second letter of person's name = o
4   Third letter of person's name  = h
5   Fourth letter of person's name = n

I would love to see example lifetimes assigned to these attributes,
and how the formula might be applied.  Should the second certificate
have a shorter lifetime?  Can we "hide" redundancy even further?

Yes, almost anyone can see the strict dependency of attribute 1 with
attributes 2 .. 5 in the second cert.  But it seems intuitive that
in cases where attributes only "tend toward" perfect dependency, the
formula must yield a value that "tends toward" the value of any single
attribute.

I wish I could construct an example for (say) 100 "almost dependent"
attributes, each with expected lifetime t.  As "almost dependent" tends
toward perfection, intuition says that the collection must have an
expected lifetime that approaches t. I fail to see how the formula
can behave so.

Comments?

___tony___





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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25418 for ietf-pkix-bks; Fri, 4 Jun 1999 11:30:00 -0700 (PDT)
Received: from Newman.GSC.GTE.Com ([e-mail] [207.175.88.67]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25410 for <[e-mail]>; Fri, 4 Jun 1999 11:29:59 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 2289"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #29038) with ESMTP id <[e-mail]> for [e-mail]; Fri, 4 Jun 1999 14:31:25 -0400 (EDT)
Received: by gscex01.ndhm.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <MFTPF6CR>; Fri, 04 Jun 1999 14:31:23 -0400
Content-return: allowed
Date: Fri, 04 Jun 1999 14:31:22 -0400
From: "Sweigert, David" <[e-mail]>
Subject: DoD X.509 Certificate Policy
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It would be great to get any clarification from DoD on the following:

The Public Key Infrastructure Roadmap for DoD. 
 
Is the June 3, 1999, Version 2.0, Revision C available
for distribution ?  Is it final ?

Is the DoD X.509 Certificate Policy, Version 2.0 dated March
1999 final ?

Thanks for your interest.

Dave Sweigert



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25277 for ietf-pkix-bks; Fri, 4 Jun 1999 11:16:27 -0700 (PDT)
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 LAA25273 for <[e-mail]>; Fri, 4 Jun 1999 11:16:27 -0700 (PDT)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <K5PL7YBK>; Fri, 4 Jun 1999 11:17:14 -0700
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5FE0@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'u8142010'" <[e-mail]>, [e-mail]
Subject: RE: authorityKeyIdentifier and subjectkeyIdentifier inplement in  the real  case or model
Date: Fri, 4 Jun 1999 11:17:11 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="windows-1252"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I can really only answer this question for how Microsoft is currently doing
this, but atleast some people in Microsoft have bought into SKI/AKI very big
time.

The Microsoft Certificate Servers in Win2000 will put AKI and SKI values
into all certificates issued by default.  The Microsoft code does not appear
to match either of the RFC algorithms for computing the SKI value, but is
all internally consistent about how it does that computation.  I believe
that you can actually put an SKI value into a certificate requestion and the
server will honor it.

The chaining code used on the new Microsoft products (IE 5.0 and Win2000
atleast) is very strong into doing chaining with AKI values, to the extent
that it will ignore all Issuer/Subject chaining if the AKI extension exists
in a certificate.  I personally have yet to decide if this is the correct
behavior, but that is not one of the areas over which I have a large amount
of control.  

So,
-- AKI and SKI are implemented in the real world.
-- If a certificate has an AKI, but the corresponding SKI is missing there
may be problems in doing the chaining for some products. (I think this is a
fault in the products and they should be falling back to name chaining if no
matches are found.)
-- If both are missing then everybody falls back to the good old name
chaining code.

jim


-----Original Message-----
From: u8142010 [mailto:[e-mail]]
Sent: Friday, June 04, 1999 2:59 AM
To: [e-mail]
Subject: authorityKeyIdentifier and subjectkeyIdentifier inplement in
the real case or model


Hi:
I read the X.509 V3 document and felt some confusing with
authorityKeyIdentifier and subjectKeyIdentifier.
Does authorityKeyIdentifier and subjectkeyIdentifier inplement in the
real case or model, and how to implement the flow?
If without subjectkeyIdentifier, will verification of client's certs be
confused or fail? And in what situation it happens?

Best Regards,
James L.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24620 for ietf-pkix-bks; Fri, 4 Jun 1999 10:02:29 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24616 for <[e-mail]>; Fri, 4 Jun 1999 10:02:28 -0700 (PDT)
Received: from mcg.org.br (pm06-13.sac.verio.net [209.162.64.220]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id KAA21633 for <[e-mail]>; Fri, 4 Jun 1999 10:03:51 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 04 Jun 1999 09:53:41 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: Summary, was Re: Every time ..., was Re: General formula
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan Lloyd wrote:

>  For my three bobs worth, the fundamental issue is that a complex
> problem like the lifetime of a lump of data cannot be solved by a simple
> (or lightweight) solution or formula

Alan:

I feel that a summary is in order -- too many subjects and topics
on this issue ... we need to see the forest in spite of the trees.
I also include some comments to other msgs and will try to
synthezise list arguments so far.

1. never say never -- I mean, we don't have a dogma here, do we?

2. The more you say it is impossible, the happier I feel ;-)

3. As I commented before, I am thankful for your doubts -- they
have helped me bring to the forefront issues such as Poisson and Erlang
statistics. Even though I may not have been 100% successfull (it seems)
to convince everyone, if my private mailbox can be proof then I have
been at least partially successfull in pointing out that modelling is much,
much better than guessing ;-)

4. But, I also do not want to impose upon this list a course on poisson
statistics modelling  -- just using the results is usually fine for all
engineering purposes. Further, I take that current doubts from Tom and
others can be solved by resorting to  textbooks, so I am trying to wait
and see what happens in time on this regard.  Again, the equation does
not have to be deduced before it is used ;-) It is already there and 
those that may feel more confortable with examples will be able to verify
that it works; again, in their own due time and there is no pressure.

5. If you don't trust the equation, then I suggest you *first* do the only
thing available today -- wild guess the result. Then, I suggest you do
calculate it. Then, I suggest you use whatever you feel is better  -- the
"wild guess" or the "wild calculation" ;-) (as you may call it). Then, I
further suggest you wait out and check what happens in the practice.
With all due respect to theory, this is IMO a far more significat test
than pages and pages of equations -- paper is too flexible and,
bytes too easily changed, as we all know ;-)

6. If you do want to "wild calculate" then please do read the inlined
reference [1] in my original posting -- it explains the modelling phase that
*must* precede any lifetime calculation using that equation. As it was very
timely remarked here yesterday by Andrew Probert:

"However for this, or any capacity planning exercise, real-world data and
assumptions are input to the model."

Thus, slightly paraphrasing Andrew's following text, I may say:

"Gerck's certificate lifetime equation requires the user to input their
assumptions on each presented attribute validity lifetime (an average)
of a *given* certificate, when a single exponential decay is assumed for
each attribute validity.  When this is not true for an attribute (eg, in the
case of a square-function validty) but the attribute can be described
by a piecewise exponential decay (as it generally can, at least
approximately) then the user must define and assume enough delayed
sub-attributes to that attribute so that the each sub-attribute validity
function is given by a single exponential decay in its time slot *and*
the user must also consider the resulting piecewise application of the
certificate lifetime equation -- so that in each time slot, all attributes
and sub-attributes are given by single exponential decays.
Alternatively, the user can input what certificate lifetime is desired,
for a given set of operational conditions, to derive a maximum number
of attributes of equal lifetime or a mix of attributes of different lifetimes.
The user does not need to make any assumption about attribute
dependency besides the trivial case of not using fully redundant
(whatever this may mean in the operational context) attributes; such
as repeatingly using the same attribute lifetime in the equation if the
attribute happens to repeated verbatim in the certificate -- since the
attribute is essentially "one" if simply repeated."

Hope it is clearer.

Cheers,

Ed Gerck


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24565 for ietf-pkix-bks; Fri, 4 Jun 1999 09:53:32 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24559 for <[e-mail]>; Fri, 4 Jun 1999 09:53:29 -0700 (PDT)
Received: from novaware.cps.softex.br (pm06-13.sac.verio.net [209.162.64.220]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id JAA19269; Fri, 4 Jun 1999 09:54:37 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 04 Jun 1999 09:44:27 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: "'Andrew Probert'" <[e-mail]>, PKIX <[e-mail]>, [e-mail]
Subject: Summary, was Re: Every time ..., was Re: General formula
References: <D1A949D4508DD1119C8100400533BEDC1077B0@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan Lloyd wrote:

>  For my three bobs worth, the fundamental issue is that a complex
> problem like the lifetime of a lump of data cannot be solved by a simple
> (or lightweight) solution or formula

Alan:

I feel that a summary is in order -- too many subjects and topics
on this issue ... we need to see the forest in spite of the trees.
I also include some comments to other msgs and will try to
synthezise list arguments so far.

1. never say never -- I mean, we don't have a dogma here, do we?

2. The more you say it is impossible, the happier I feel ;-)

3. As I commented before, I am thankful for your doubts -- they
have helped me bring to the forefront issues such as Poisson and Erlang
statistics. Even though I may not have been 100% successfull (it seems)
to convince everyone, if my private mailbox can be proof then I have
been at least partially successfull in pointing out that modelling is much,
much better than guessing ;-)

4. But, I also do not want to impose upon this list a course on poisson
statistics modelling  -- just using the results is usually fine for all engineering
purposes. Further, I take that current doubts from Tom and others can be
solved by resorting to  textbooks, so I am trying to wait and see what
happens in time on this regard.  Again, the equation does not have to be
deduced before it is used ;-) It is already there and those that may feel
more confortable with examples will be able to verify that it works; again,
in their own due time and there is no pressure.

5. If you don't trust the equation, then I suggest you *first* do the only
thing available today -- wild guess the result. Then, I suggest you do
calculate it. Then, I suggest you use whatever you feel is better  -- the
"wild guess" or the "wild calculation" ;-) (as you may call it). Then, I
further suggest you wait out and check what happens in the practice.
With all due respect to theory, this is IMO a far more significat test
than pages and pages of equations -- paper is too flexible and,
bytes too easily changed, as we all know ;-)

6. If you do want to "wild calculate" then please do read the inlined
reference [1] in my original posting -- it explains the modelling phase that
*must* precede any lifetime calculation using that equation. As it was very
timely remarked here yesterday by Andrew Probert:

"However for this, or any capacity planning exercise, real-world data and
assumptions are input to the model."

Thus, slightly paraphrasing Andrew's following text, I may say:

"Gerck's certificate lifetime equation requires the user to input their
assumptions on each presented attribute validity lifetime (an average)
of a *given* certificate, when a single exponential decay is assumed for
each attribute validity.  When this is not true for an attribute (eg, in the
case of a square-function validty) but the attribute can be described
by a piecewise exponential decay (as it generally can, at least
approximately) then the user must define and assume enough delayed
sub-attributes to that attribute so that the each sub-attribute validity
function is given by a single exponential decay in its time slot *and*
the user must also consider the resulting piecewise application of the
certificate lifetime equation -- so that in each time slot, all attributes
and sub-attributes are given by single exponential decays.
Alternatively, the user can input what certificate lifetime is desired,
for a given set of operational conditions, to derive a maximum number
of attributes of equal lifetime or a mix of attributes of different lifetimes.
The user does not need to make any assumption about attribute
dependency besides the trivial case of not using fully redundant
(whatever this may mean in the operational context) attributes; such
as repeatingly using the same attribute lifetime in the equation if the
attribute happens to repeated verbatim in the certificate -- since the
attribute is essentially "one" if simply repeated."

Hope it is clearer.

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23711 for ietf-pkix-bks; Fri, 4 Jun 1999 07:40:15 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23707 for <[e-mail]>; Fri, 4 Jun 1999 07:40:15 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (swf-caw1.spyrus.com [207.212.34.211]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA17038; Fri, 4 Jun 1999 07:38:38 -0700 (PDT)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 03 Jun 1999 12:43:24 -0400
To: Christopher Stacy <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
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
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I know of at least one Governemnt agency that is looking into this
technology for this exact use.

Russ


At 11:28 PM 6/1/99 -0400, Christopher Stacy wrote:
>>>>>> On Tue, 01 Jun 1999 13:22:22 -0400, Russ Housley ("Russ") writes:
> Russ> There are a few real needs for encrypted attributes.
>
>Certainly in a military security context, there is a need for such secret
>authorizations: classification compartment identifiers are themselves 
>classified. 
>(I don't know if anyone is actually planning to use certificate attributes in
>such a direct mapping, but it would be very natural in a multi-mode 
>environment.)
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16021 for ietf-pkix-bks; Fri, 4 Jun 1999 02:57:57 -0700 (PDT)
Received: from smtp.seeder.net.tw (smtp4.seeder.net [210.62.177.94]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16017 for <[e-mail]>; Fri, 4 Jun 1999 02:57:56 -0700 (PDT)
Received: from ms2.seeder.net ([202.39.153.193]) by smtp.seeder.net.tw with ESMTP (IPAD 2.5) id 4238800 ; Fri, 04 Jun 1999 17:59:49 +0800
Message-ID: <[e-mail]>
Date: Fri, 04 Jun 1999 17:59:13 +0800
From: u8142010 <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: authorityKeyIdentifier and subjectkeyIdentifier inplement in the real  case or model
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi:
I read the X.509 V3 document and felt some confusing with
authorityKeyIdentifier and subjectKeyIdentifier.
Does authorityKeyIdentifier and subjectkeyIdentifier inplement in the
real case or model, and how to implement the flow?
If without subjectkeyIdentifier, will verification of client's certs be
confused or fail? And in what situation it happens?

Best Regards,
James L.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA15923 for ietf-pkix-bks; Fri, 4 Jun 1999 02:38:53 -0700 (PDT)
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 CAA15918 for <[e-mail]>; Fri, 4 Jun 1999 02:38:50 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id LAA23550; Fri, 4 Jun 1999 11:38:49 +0200
Message-ID: <[e-mail]>
Date: Fri, 04 Jun 1999 11:39:44 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Sarbari Gupta <[e-mail]>
CC: "'Robert Zuccherato'" <[e-mail]>, "PKIX (E-mail)" <[e-mail]>
Subject: Re: Inclusion of a Status code within a TSAToken
References: <51BF55C30B4FD1118B4900207812701E38F952@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari,

I have been away from my desk only two days and I see that the discussion is
still on going with Robert.

I agree with your nice analysis about denial of service attacks which shows
that signed errors add nothing: nothing can stop denial of service. I would
like to close that discussion which has already taken too long and for this
effect to add one final argument:

We need to be consistent within the PKIX WG: this means that we should
address similar problems in different documents in the same way.

The OCSP standard is addressing the problem the following way :

"  In case of errors, the OCSP Responder may return an error message.
   These messages are not signed. "

The Proposol for the LAAP protocol (Limited AC Acquisition Protocol) is
proposing in  <draft-ietf-pkix-ac509prof-00.txt>

   LACResponseMessage ::= CHOICE {
        ac        [0]  AttributeCertificate,
        errorInfo [1]  ErrorMsgContent -- from [CMP]
   }

I see no reason why TSP should behave differently. In all cases a signed
response is given back when the request was well-formed and an unsigned
status is given back on the contrary.

I hope we can all agree on this and change the current draft accordingly. I
do know that Robert is favoring signed status but I hope that he can
(reluctantly) accept the final argument.

Regards,

Denis


> > > The status code is relevant only to the protocol between
> > the TSA client
> > > and the TSA. The TSA Token, on the other hand, has a much longer
> > > life-span and may be processed by many, many, other
> > entities. I would
> > > strongly recommend that the status info not be included
> > the TSA Token.
> > >
> > I would tend to disagree with this statement.  Remember that
> > these tokens
> > will be used to support non-repudiation and may end up being used as
> > evidence in some dispute resolution process.  Therefore, it does seem
> > reasonable that some environments may require more than just
> > "the absence of
> > an error code means that this is a valid timestamp".  They
> > may require a
> > more explicit "this is a valid token" statement from the TSA.
> >  This is what
> > the presence of a value 0 (granted) provides in the present
> > token structure.
>
> I don't get it. Are you saying that a valid signed TSAToken does not in
> itself constitute a valid timestamp? You need an additional field with
> value zero (0) within the token indicating that it's a valid token? Why
> is a TSA signing an invalid TSAToken in the first place? Are you
> envisioning non-zero status within otherwise valid TSATokens? If so, you
> are contradicting a previous statement you made:
>
> >>If an error is
> >>present, the response is an error message, not a valid token.  If no
> error
> >>is present, a status code indicating that a valid token was produced
> does
> >>appear within the token.
>
> However, I think I have made my case for excluding the Status info from
> the TSAToken. If there is anyone else on this list who has strong
> feelings on this issue, let them speak up. Otherwise, continue on with
> the current protocol definitions.
>
> Best regards,
>
> - Sarbari



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA15171 for ietf-pkix-bks; Fri, 4 Jun 1999 00:28:57 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA15167 for <[e-mail]>; Fri, 4 Jun 1999 00:28:53 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <MCLY41JJ>; Fri, 4 Jun 1999 17:30:14 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC1077B0@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Andrew Probert'" <[e-mail]>, PKIX <[e-mail]>
Subject: RE: Every time ..., was Re: General formula
Date: Fri, 4 Jun 1999 17:30:12 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Gosh Andy - all you ever do is spend is two bob - which represents AU$
0.50. :-)
 For my three bobs worth, the fundamental issue is that a complex
problem like the lifetime of a lump of data cannot be solved by a simple
(or lightweight) solution or formula eg. good old LDAP did not and will
not solve directory SYSTEM issues - just server - access issues.

Cert validity / lifetimes should be modelled in terms of operational
usage with the reliability requirements of the service.. ie from a
requirements perspective  in the context of a system design - not a
predictive perspective  based on theory or massive assumptions about the
data.

The process of ILS, LCC, error mode and criticality analysis and service
availablity prediction processes work for me in this regard - as it
takes into account the system components, their architecture and their
usage, etc.. 

Perhaps a discusion on ILS and LCC might be useful eh!

regards alan 

> -----Original Message-----
> From:	Andrew Probert 
> Sent:	Friday, June 04, 1999 10:57 AM
> To:	PKIX
> Subject:	RE: Every time ..., was Re: General formula
> 
> Two bobs worth ..
> 
> Erlang calculations have been tablulated to give people an easy lookup
> for
> telephony calculations.  Given a presented load in seconds, and a
> number of
> lines, what is the percentage of calls that will get a busy signal?
> 
> It works, given 3 factors you can lookup any way you like.
> 
> However for this, or any capacity planning exercise, real-world data
> and
> assumptions are input to the model.  
> 
> Erlang tables require the user to input their assumptions on presented
> load
> (an average) and number of lines avaliable to derive busy.
> Alternatively
> how much busy time they can tolerate, for a given load to derive a
> minimum
> number of lines.
> 
> I'm all for a model, please send me the Excel spreadsheet
> implementation
> when its complete.  
> 
> However, I think the real world of certs is too complex.
> 
> 
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  [phone]
> Fax [phone]
> 
> 
> 
	snip


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA19007 for ietf-pkix-bks; Thu, 3 Jun 1999 17:57:22 -0700 (PDT)
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 RAA19003 for <[e-mail]>; Thu, 3 Jun 1999 17:57:18 -0700 (PDT)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <MB6NB5QL>; Fri, 4 Jun 1999 10:56:56 +1000
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A64B2@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: PKIX <[e-mail]>
Subject: RE: Every time ..., was Re: General formula
Date: Fri, 4 Jun 1999 10:56:55 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Two bobs worth ..

Erlang calculations have been tablulated to give people an easy lookup for
telephony calculations.  Given a presented load in seconds, and a number of
lines, what is the percentage of calls that will get a busy signal?

It works, given 3 factors you can lookup any way you like.

However for this, or any capacity planning exercise, real-world data and
assumptions are input to the model.  

Erlang tables require the user to input their assumptions on presented load
(an average) and number of lines avaliable to derive busy.  Alternatively
how much busy time they can tolerate, for a given load to derive a minimum
number of lines.

I'm all for a model, please send me the Excel spreadsheet implementation
when its complete.  

However, I think the real world of certs is too complex.


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



> -----Original Message-----
> From:	Ed Gerck [SMTP:[e-mail]]
> Sent:	Friday, June 04, 1999 6:09 AM
> To:	Ben Laurie
> Cc:	Alan Lloyd; Bob Blakley; Graham Klyne; PKIX
> Subject:	Re: Every time ..., was Re: General formula
> 
> 
> 
> Ben Laurie wrote:
> 
> > Ed Gerck wrote:
> > > This also means that if you call someone and it is busy, you could
> call
> > > right afterwards (just add the round-trip total delay time -- say, 5
> sec)
> > > and your sucess rate should be the same as if you would wait some
> > > minutes (as people normally do).
> > >
> > > The reason in both cases is simple -- since phone statistics is given
> by
> > > a Poison distribution and you don't know when the conversation
> actually
> > > *started*, its end does not depend on the duration of your
> observation.
> >
> > I don't believe this for a moment. To take an extreme example, if people
> > make, on average, 1 phone call a year, with a mean duration of 1 minute,
> > then it is intuitively obvious that if I wait a day after they are busy,
> > I have an almost 100% chance that they won't be busy,
> 
> Ben Laurie:
> 
> Is this how people really use the phone where you live? Is this "phone
> statistics"? C'mon, give me a break-- and realize that the statistics of
> your "extreme example" (what an understatement) is not even given by
> a Poisson pdf.
> 
> > whereas 5 seconds
> > later the chances are noticably less than 100%. Of course, I believe the
> > second statement, but the first is not a consequence of it, IMNSHO.
> >
> > You're just making this stuff up as you go along, aren't you?
> 
> You remind me of a guy that drowned in a lake that had just one inch
> of water depth, on average. Just too bad he did not realize it was an
> average, though. Or, even, what an average was.
> 
> Since phone traffic statistic is hardly on-topic here, I might help you
> off
> list if you consider this important for your understanding of certificate
> lifetimes.
> 
> And, Ben, next time you don't understand something, just ask and say what
> part of my text you did not understand. You don't need to become
> aggressive
> in order to receive my reply.
> 
> Cheers,
> 
> Ed Gerck
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA18940 for ietf-pkix-bks; Thu, 3 Jun 1999 17:45:34 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA18935 for <[e-mail]>; Thu, 3 Jun 1999 17:45:27 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <MCLY41G7>; Fri, 4 Jun 1999 10:46:38 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC1077A7@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'David Chia'" <[e-mail]>, [e-mail]
Subject: RE: Every time ..., was Re: General formula
Date: Fri, 4 Jun 1999 10:46:36 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks - comments in line.

> -----Original Message-----
> From:	David Chia 
> Sent:	Thursday, June 03, 1999 4:01 PM
> To:	[e-mail]
> Subject:	Re: Every time ..., was Re: General formula
> 
> > 
> > Ed - this is all too hard for me ... I cannot even predict how long
> my
> > wife will be on the phone tonight or the number of times my mobile
> will
> > drop out when using it (hands free of course) in the car.
> > 
> > As to certificate usage and lifetime - theory is useful - but
> practice
> > makes perfect. 
> > 
> > What is the lifetime of a Bus or Train ticket... It depends on the
> > attitude and hunger of the damn machines that read them...QED
> > 
> 
> You seem to have missed the point. 
	That some times happens when the point is hard to see or there
is no purpose for hitting it.

> The aim is not to predict 'exactly'
> the life time of any 'particular' certificate.  The exercise is to
> determine if collectively the phenomon exibits predictable behaviour
> and to estimate the 'expected' or the statistical maximum likelihood
> value (together with the standard error of estimation if possible) so
> that cost can be evaluated and alternatives can be compared.
	I understand that - and being involved with this stuff for the
last 100 years or so - I will always state that a looking at a data
structure in isolation is a very limited exercise. I often present to
companies  - and one line I use is that a certificate represents a
currency (within a domain) and it is verified through the use of
directory services. A currency has a lifetime according to treasury
policy.. but and instance of the currency has a lifetime that is
affected by use and application. 
	Eg. an Australian $ note (being plastic) does not last long if
hot water is poured on it.

	Ie.- its makes little sense to talk about the theory treasurey
policy when in real life - lifetime is a usage issue. 
	I have pointed out that the maths associated with the validity
of a certificate is theory. And that, in operational systems, a
certficate being valid or not - in order to deliver customer services -
is a small part of the picture. So any theoretical formula without its
application is  just theory.

	 
> When I buy hardware I usually also check the mean time between failure
> value beside cost and warrantee.
> 
	The MTBF of my car is 3 years - however when I break it -
operationally - is costs me heaps or its lifetime is shortened.
	 MTTR and Cost of repair is also useful - Shall we discuss
Integrated Logistics Support systems and Life Cycle Costs ?

	I hope this helps and regards alan

> David Chia, RMIT University


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA16419 for ietf-pkix-bks; Thu, 3 Jun 1999 13:18:01 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16415 for <[e-mail]>; Thu, 3 Jun 1999 13:18:00 -0700 (PDT)
Received: from mcg.org.br (pm04-47.sac.verio.net [209.162.64.160]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id NAA18537; Thu, 3 Jun 1999 13:18:48 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 03 Jun 1999 13:09:09 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Laurie <[e-mail]>
CC: Alan Lloyd <[e-mail]>, Bob Blakley <[e-mail]>, Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: Re: Every time ..., was Re: General formula
References: <D1A949D4508DD1119C8100400533BEDC107795@DSG1> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ben Laurie wrote:

> Ed Gerck wrote:
> > This also means that if you call someone and it is busy, you could call
> > right afterwards (just add the round-trip total delay time -- say, 5 sec)
> > and your sucess rate should be the same as if you would wait some
> > minutes (as people normally do).
> >
> > The reason in both cases is simple -- since phone statistics is given by
> > a Poison distribution and you don't know when the conversation actually
> > *started*, its end does not depend on the duration of your observation.
>
> I don't believe this for a moment. To take an extreme example, if people
> make, on average, 1 phone call a year, with a mean duration of 1 minute,
> then it is intuitively obvious that if I wait a day after they are busy,
> I have an almost 100% chance that they won't be busy,

Ben Laurie:

Is this how people really use the phone where you live? Is this "phone
statistics"? C'mon, give me a break-- and realize that the statistics of
your "extreme example" (what an understatement) is not even given by
a Poisson pdf.

> whereas 5 seconds
> later the chances are noticably less than 100%. Of course, I believe the
> second statement, but the first is not a consequence of it, IMNSHO.
>
> You're just making this stuff up as you go along, aren't you?

You remind me of a guy that drowned in a lake that had just one inch
of water depth, on average. Just too bad he did not realize it was an
average, though. Or, even, what an average was.

Since phone traffic statistic is hardly on-topic here, I might help you off
list if you consider this important for your understanding of certificate
lifetimes.

And, Ben, next time you don't understand something, just ask and say what
part of my text you did not understand. You don't need to become aggressive
in order to receive my reply.

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA15444 for ietf-pkix-bks; Thu, 3 Jun 1999 11:44:51 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA15440 for <[e-mail]>; Thu, 3 Jun 1999 11:44:50 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id LAA14785 for <[e-mail]>; Thu, 3 Jun 1999 11:44:43 -0700 (PDT)
Received: from rhone (dhcp-3-116.engineering.valicert.com [192.168.3.116] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id LAA22439 for <[e-mail]>; Thu, 3 Jun 1999 11:45:43 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>
Subject: Problem with RFC 2459?
Date: Thu, 3 Jun 1999 11:48:59 -0700
Message-ID: <006901beadf1$be7b2e60$[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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Folks,
    Have a quick question about RFC 2459 and CRLDPs.

If a CA issues both full CRLs and CRLDPs (which are partitioned
based on the serial number of the cert), how can an application
figure out whether it has the full CRL or a DP?

I know a DP (if it is not the full CRL), must contain the Issuing
Distribution Point (IDP) extension. However, I believe most CAs
are putting the IDP extension within their full CRLs also. So,
is there any way for a application to figure out whether it has
the full CRL or just a DP?

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 IAA13392 for ietf-pkix-bks; Thu, 3 Jun 1999 08:23:43 -0700 (PDT)
Received: from pain.fw.isotic.org (mail.isotic.org [198.77.79.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13388 for <[e-mail]>; Thu, 3 Jun 1999 08:23:42 -0700 (PDT)
Received: by PAIN with Internet Mail Service (5.5.2448.0) id <KPQJYNN3>; Thu, 3 Jun 1999 11:24:57 -0400
Message-ID: <F1067954A1E7D211AF9700105A24BA7902E8B0@PAIN>
From: Matt Paschal <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject:  pki
Date: Thu, 3 Jun 1999 11:24:56 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 

> Subscribe [e-mail] ietf-pkix


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12984 for ietf-pkix-bks; Thu, 3 Jun 1999 07:35:43 -0700 (PDT)
Received: from USlink.net (link3.uslink.net [199.199.168.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA12980 for <[e-mail]>; Thu, 3 Jun 1999 07:35:41 -0700 (PDT)
Received: from iami.org ([206.146.187.195]) by USlink.net (8.9.3/8.8.8) with SMTP id JAA27972 for <[e-mail]>; Thu, 3 Jun 1999 09:37:31 -0500 (CDT)
Received: from ntserver.iami.org [206.146.187.234] by iami.org (1.61/SMTP) for <[e-mail]>
Date: Thu, 03 Jun 99 08:38:24 Central Daylight Time
Message-Id: <[e-mail]>
Message-ID: <001501beadc5$a8fd7ce0$[e-mail]>
From: "IAMI" <[e-mail]>
To: <[e-mail]>
Subject: Information on National Association of Review Appraisers
Date: Thu, 3 Jun 1999 08:33:26 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_01BEAD9B.C02774E0"
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01BEAD9B.C02774E0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0012_01BEAD9B.C02774E0"


------=_NextPart_001_0012_01BEAD9B.C02774E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



ATTN: Real Estate Appraisal Department
=20
On behalf of the National Association of Review Appraisers & Mortgage =
Underwriters, I would like to invite you to membership and the =
"CRA-Certified Review Appraiser" Designation.  Our Association is =
composed of more than 3,000 Designated Members.  One of the main =
purposes of NARA/MU is to improve competency in the field of Appraisal =
Review and to offer a Professional Designation.
The CRA designated membership is available to individuals who are active =
in performing appraisal reviews.  No appraisal license is required for =
this designation, as the Reviewer is not valuing, only reviewing the =
appraisal.  It is important that even the occasional reviewer has an =
in-depth understanding of how to properly review appraisal reports.  =
NARA/MU is the only association that deals exclusively with reviewing =
appraisal reports.
=20
Membership includes a subscription to the NARA/MU Appraisal Review & =
Mortgage Underwriting Journal, The Reviewing Times a quarterly =
newsletter; "How To" Guideline Booklets; the Association's Directory of =
Members, and much more. =20
=20
For your convenience I have provided links to our website and online =
application form.
=20
=20
Sincerely,
Robert G. Johnson
Executive Director=20
NATIONAL ASSOCIATION OF REVIEW APPRAISERS
AND MORTGAGE UNDERWRITERS
http://www.iami.org/nara.html
http://www.iami.org/nara/apply.html
=20

------=_NextPart_001_0012_01BEAD9B.C02774E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"" size=3D2>ATTN: Real Estate =
Appraisal=20
Department</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>On behalf of the National Association of Review =
Appraisers=20
&amp; Mortgage Underwriters, I would like to invite you to membership =
and the=20
&quot;CRA-Certified Review Appraiser&quot; Designation.&nbsp; Our =
Association is=20
composed of more than 3,000 Designated Members.&nbsp; One of the main =
purposes=20
of NARA/MU is to improve competency in the field of Appraisal Review and =
to=20
offer a Professional Designation.</FONT></DIV>
<DIV><FONT size=3D2>The CRA designated membership is available to =
individuals who=20
are active in performing appraisal reviews.&nbsp; No appraisal license =
is=20
required for this designation, as the Reviewer is not valuing, only =
reviewing=20
the appraisal.&nbsp; It is important that even the occasional reviewer =
has an=20
in-depth understanding of how to properly review appraisal =
reports.&nbsp;=20
NARA/MU is the only association that deals exclusively with reviewing =
appraisal=20
reports.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Membership includes a subscription to the NARA/MU =
Appraisal=20
Review &amp; Mortgage Underwriting Journal, The Reviewing Times a =
quarterly=20
newsletter; &quot;How To&quot; Guideline Booklets; the Association's =
Directory=20
of Members, and much more.&nbsp; </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>For your convenience I have provided =
links to=20
our website and online application form.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Sincerely,<BR></FONT><FONT size=3D2>Robert G.=20
Johnson<BR>Executive Director </FONT></DIV>
<DIV><FONT size=3D2>NATIONAL ASSOCIATION OF REVIEW APPRAISERS<BR>AND =
MORTGAGE=20
UNDERWRITERS</FONT></DIV>
<DIV><FONT size=3D2><A=20
href=3D"http://www.iami.org/nara.html">http://www.iami.org/nara.html</A><=
/FONT></DIV>
<DIV><FONT size=3D2><A=20
href=3D"http://www.iami.org/nara/apply.html">http://www.iami.org/nara/app=
ly.html</A></FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_0012_01BEAD9B.C02774E0--

------=_NextPart_000_0011_01BEAD9B.C02774E0
Content-Type: application/octet-stream;
	name="MU Application FORM.url"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="MU Application FORM.url"

[InternetShortcut]
URL=http://www.iami.org/nara/apply.html
Modified=40B9EBAC7EA7BE0174

------=_NextPart_000_0011_01BEAD9B.C02774E0
Content-Type: application/octet-stream;
	name="MU Homepage.url"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="MU Homepage.url"

[InternetShortcut]
URL=http://www.iami.org/nara.html
Modified=206A36A47EA7BE0148

------=_NextPart_000_0011_01BEAD9B.C02774E0--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA10654 for ietf-pkix-bks; Thu, 3 Jun 1999 04:21:18 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA10650 for <[e-mail]>; Thu, 3 Jun 1999 04:21:16 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA09215; Thu, 3 Jun 1999 13:22:32 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 3 Jun 1999 13:22:32 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id NAA01170; Thu, 3 Jun 1999 13:22:30 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id NAA26877; Thu, 3 Jun 1999 13:22:30 +0200
Date: Thu, 3 Jun 1999 13:22:30 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Inclusion of a Status code within a TSAToken
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > > 
> > I would tend to disagree with this statement.  Remember that 
> > these tokens
> > will be used to support non-repudiation and may end up being used as
> > evidence in some dispute resolution process.  Therefore, it does seem
> > reasonable that some environments may require more than just 
> > "the absence of
> > an error code means that this is a valid timestamp".  They 
> > may require a
> > more explicit "this is a valid token" statement from the TSA. 
> >  This is what
> > the presence of a value 0 (granted) provides in the present 
> > token structure.
To be or not to be is a binary value. The presence of a PKIStatus
with granted and no other information is not necessary, it should
be the default. 


> 
> I don't get it. Are you saying that a valid signed TSAToken does not in
> itself constitute a valid timestamp? You need an additional field with
> value zero (0) within the token indicating that it's a valid token? Why
> is a TSA signing an invalid TSAToken in the first place? Are you
> envisioning non-zero status within otherwise valid TSATokens? If so, you
> are contradicting a previous statement you made:
The TSA is not signing an INVLID TSAToken. First, to nit-pick, it is
signing a TSTInfo (The signed object is a TSAToken.) 

It might be useful to have a VALID Token (granted) with whatever kind
of free form message (someone might want to include a commercial text
in there in order to finance the service.) :-) 

> 
> >>If an error is
> >>present, the response is an error message, not a valid token.  If no
> error
> >>is present, a status code indicating that a valid token was produced
> does
> >>appear within the token. 
> 
> However, I think I have made my case for excluding the Status info from
> the TSAToken. If there is anyone else on this list who has strong
> feelings on this issue, let them speak up. Otherwise, continue on with
> the current protocol definitions. 
The proposals are technically equivalent. This seems a matter of taste
to distinguish two things either by an OID, or by a number (The PKIStatus).

On the other hand it seems interesting to me to regard the protocol
and the data structure from a DCS standpoint. It would be nice to
have a common data structure, and the absence of most values would
just indicate time stamping (or as it is said in the DCS text, DCS
is an extension of time stamping.) 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA07212 for ietf-pkix-bks; Thu, 3 Jun 1999 02:01:13 -0700 (PDT)
Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA07208 for <[e-mail]>; Thu, 3 Jun 1999 02:01:11 -0700 (PDT)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id JAA09223; Thu, 3 Jun 1999 09:02:06 GMT
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id KAA21216; Thu, 3 Jun 1999 10:02:16 +0100
Message-ID: <[e-mail]>
Date: Thu, 03 Jun 1999 10:02:05 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: Alan Lloyd <[e-mail]>, Bob Blakley <[e-mail]>, Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: Re: Every time ..., was Re: General formula
References: <D1A949D4508DD1119C8100400533BEDC107795@DSG1> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed Gerck wrote:
> This also means that if you call someone and it is busy, you could call
> right afterwards (just add the round-trip total delay time -- say, 5 sec)
> and your sucess rate should be the same as if you would wait some
> minutes (as people normally do).
> 
> The reason in both cases is simple -- since phone statistics is given by
> a Poison distribution and you don't know when the conversation actually
> *started*, its end does not depend on the duration of your observation.

I don't believe this for a moment. To take an extreme example, if people
make, on average, 1 phone call a year, with a mean duration of 1 minute,
then it is intuitively obvious that if I wait a day after they are busy,
I have an almost 100% chance that they won't be busy, whereas 5 seconds
later the chances are noticably less than 100%. Of course, I believe the
second statement, but the first is not a consequence of it, IMNSHO.

You're just making this stuff up as you go along, aren't you?

Cheers,

Ben.

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

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA06298 for ietf-pkix-bks; Thu, 3 Jun 1999 00:16:18 -0700 (PDT)
Received: from fnmt.es ([194.224.76.148]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA06294 for <[e-mail]>; Thu, 3 Jun 1999 00:16:17 -0700 (PDT)
Received: from [192.168.1.176] by fnmt.es (NTMail 3.02.13) with ESMTP id ea007388 for <[e-mail]>; Thu, 3 Jun 1999 09:17:31 +0100
Message-ID: <00c301bead90$b6b28040$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: "Sarbari Gupta" <[e-mail]>, "'Robert Zuccherato'" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Inclusion of a Status code within a TSAToken
Date: Thu, 3 Jun 1999 09:14:21 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

>> > The status code is relevant only to the protocol between
>> the TSA client
>> > and the TSA. The TSA Token, on the other hand, has a much longer
>> > life-span and may be processed by many, many, other
>> entities. I would
>> > strongly recommend that the status info not be included
>> the TSA Token.
>> >
>> I would tend to disagree with this statement.  Remember that
>> these tokens
>> will be used to support non-repudiation and may end up being used as
>> evidence in some dispute resolution process.  Therefore, it does seem
>> reasonable that some environments may require more than just
>> "the absence of
>> an error code means that this is a valid timestamp".  They
>> may require a
>> more explicit "this is a valid token" statement from the TSA.
>>  This is what
>> the presence of a value 0 (granted) provides in the present
>> token structure.
>
>I don't get it. Are you saying that a valid signed TSAToken does not in
>itself constitute a valid timestamp? You need an additional field with
>value zero (0) within the token indicating that it's a valid token? Why
>is a TSA signing an invalid TSAToken in the first place? Are you
>envisioning non-zero status within otherwise valid TSATokens? If so, you
>are contradicting a previous statement you made:


It is my concern that a signedData structure correctly signed is enough
proof of validity, specially in the case of an Authority (i.e. making
reference to its policy within that structure). There is no need (even of
dubious worth) to have a field specifying "granted" for it does not provide
further information on the service. We might advocate in a different
direction if more values could be provided (e.g. "granted with mods") but
this is not the case.

>>>If an error is
>>>present, the response is an error message, not a valid token.  If no
>error
>>>is present, a status code indicating that a valid token was produced
>does
>>>appear within the token.
>
>However, I think I have made my case for excluding the Status info from
>the TSAToken. If there is anyone else on this list who has strong
>feelings on this issue, let them speak up. Otherwise, continue on with
>the current protocol definitions.


It is my belief that in the interest of keeping the protocol simple and
coherent, using different structures, one for TSATokens and one for
signaling errors, is the cleanest solution. Since the Status info for a
TSAToken structure can be assumed (a single value) it should not be
included. If we agree that authenticated error messages are to be provided,
then a CHOICE within the SignedData Content structure will do.

>
>Best regards,
>
>- Sarbari

kind regards,
Juan.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA05747 for ietf-pkix-bks; Wed, 2 Jun 1999 23:00:18 -0700 (PDT)
Received: from urgento.gse.rmit.EDU.AU (urgento.gse.rmit.edu.au [131.170.69.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA05741 for <[e-mail]>; Wed, 2 Jun 1999 23:00:15 -0700 (PDT)
Received: (from rsedc@localhost) by urgento.gse.rmit.EDU.AU (8.9.1a/8.9.1) id QAA15164; Thu, 3 Jun 1999 16:01:14 +1000 (EST)
From: David Chia <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Every time ..., was Re: General formula
To: [e-mail]
Date: Thu, 3 Jun 1999 16:01:14 +1000 (EST)
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC107795@DSG1> from "Alan Lloyd" at Jun 3, 99 08:54:42 am
X-Mailer: ELM [version 2.4 PL25+3 PGP6+4]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Ed - this is all too hard for me ... I cannot even predict how long my
> wife will be on the phone tonight or the number of times my mobile will
> drop out when using it (hands free of course) in the car.
> 
> As to certificate usage and lifetime - theory is useful - but practice
> makes perfect. 
> 
> What is the lifetime of a Bus or Train ticket... It depends on the
> attitude and hunger of the damn machines that read them...QED
> 

You seem to have missed the point. The aim is not to predict 'exactly'
the life time of any 'particular' certificate.  The exercise is to
determine if collectively the phenomon exibits predictable behaviour
and to estimate the 'expected' or the statistical maximum likelihood
value (together with the standard error of estimation if possible) so
that cost can be evaluated and alternatives can be compared.

When I buy hardware I usually also check the mean time between failure
value beside cost and warrantee.


David Chia, RMIT University


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA05526 for ietf-pkix-bks; Wed, 2 Jun 1999 22:21:24 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA05522 for <[e-mail]>; Wed, 2 Jun 1999 22:21:21 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <MCLY41C2>; Thu, 3 Jun 1999 15:22:37 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC1077A0@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>
Cc: PKIX <[e-mail]>
Subject: RE: good example, was Re: Every time ... 
Date: Thu, 3 Jun 1999 15:22:36 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> snip
> > >
> > > I might be tempted to model it ;-)
> >
> > Go for it Ed - we need this world  wide :-)
> >         ie the life time of a mobile phone call (in a car) depends
> on:
> >                 the type of terminal, the make of car, its location,
> > speed and direction, the mobile aerial array (height/power), other
> > multiplexed services (capacities), etc, etc as well as the weather
> and
> > what big lumps of steel around - specifically tunnels and bridges,
> or if
> > a Roo has just hit the front of your car.
> >
> >         Whoops I could be supporting your theory that the more
> > attributes things have, the shorter the lifetime of the object (the
> > call). :-)
> 
> Good example ... got you!
> 
	I know - I only wrote it to stop the debate about certs -

	Its these gophers that interest me.. do you think they would
want smart cards, PKIs and directory services..


> Have fun with the Roos, What else can one do with them but have fun -
> and sell the PKI and directory services.  We even paint pictures of
> the buggers on our aeroplanes.
> 
	regards alan
> Ed Gerck


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA05466 for ietf-pkix-bks; Wed, 2 Jun 1999 22:09:18 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA05462 for <[e-mail]>; Wed, 2 Jun 1999 22:09:17 -0700 (PDT)
Received: from mcg.org.br (pm04-32.sac.verio.net [209.162.64.145]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id WAA22142; Wed, 2 Jun 1999 22:10:25 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 Jun 1999 22:00:56 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: Bob Blakley <[e-mail]>, Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: good example, was Re: Every time ... 
References: <D1A949D4508DD1119C8100400533BEDC10779E@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan Lloyd wrote:

> > Alan:
> >
> > Theory says that "how long your wife will be on the phone" does NOT
> > depend when you first noted that she was on the phone -- if this is
> > of any use to you, though it may already relate to your experience ;-)
> >
> > This also means that if you call someone and it is busy, you could
> > call right afterwards (just add the round-trip total delay time -- say, 5
> > sec) and your sucess rate should be the same as if you would wait some
> > minutes (as people normally do).
> >
>         I never call people - the phone is always in use :-)

Still, the same rule applies -- it would be of no use for me to wait a few
minutes before calling again .. it would still be busy ;-)

> > > or the number of times my mobile will drop out when using it (hands
> >>  free of course) in the car.
> >
> > I might be tempted to model it ;-)
>
> Go for it Ed - we need this world  wide :-)
>         ie the life time of a mobile phone call (in a car) depends on:
>                 the type of terminal, the make of car, its location,
> speed and direction, the mobile aerial array (height/power), other
> multiplexed services (capacities), etc, etc as well as the weather and
> what big lumps of steel around - specifically tunnels and bridges, or if
> a Roo has just hit the front of your car.
>
>         Whoops I could be supporting your theory that the more
> attributes things have, the shorter the lifetime of the object (the
> call). :-)

Good example ... got you!

Have fun with the Roos,

Ed Gerck



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA05385 for ietf-pkix-bks; Wed, 2 Jun 1999 21:58:08 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA05380 for <[e-mail]>; Wed, 2 Jun 1999 21:57:52 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <MCLY41B0>; Thu, 3 Jun 1999 14:59:08 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC10779E@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>
Cc: Bob Blakley <[e-mail]>, Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: RE: Every time ..for ammusement only
Date: Thu, 3 Jun 1999 14:59:03 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed a wonderful response - what a mine of information - comments follow
 
> -----Original Message-----
> From:	Ed Gerck 
> Sent:	Thursday, June 03, 1999 1:48 PM
> To:	Alan Lloyd
> Cc:	Bob Blakley; Graham Klyne; PKIX
> Subject:	Re: Every time ..., was Re: General formula
> 
> 
> 
> Alan Lloyd wrote:
> 
> > Ed - this is all too hard for me ... I cannot even predict how long
> my
> > wife will be on the phone tonight
> 
> Alan:
> 
> Theory says that "how long your wife will be on the phone" does NOT
> depend when you first noted that she was on the phone -- if this is
> of any use to you, though it may already relate to your experience ;-)
> 
> This also means that if you call someone and it is busy, you could
> call
> right afterwards (just add the round-trip total delay time -- say, 5
> sec)
> and your sucess rate should be the same as if you would wait some
> minutes (as people normally do).
> 
	I never call people - the phone is always in use :-)

> The reason in both cases is simple -- since phone statistics is given
> by
> a Poison distribution and you don't know when the conversation
> actually
> *started*, its end does not depend on the duration of your
> observation.
	I dont really care how long it goes for its the business model
that affects me - as it will with PKI systems..
	ie. This Erlang guy is not what I wanted - I wanted some one who
can relate my wifes calls to the local, interstate and international
billing tarrifs in a predictable fashion. :-)

> So, theory is nice -- when it corresponds to reality (as the above two
> examples do). It allows us to use elevators, credit and rely on
> chemistry.
> 
> 
> > or the number of times my mobile will drop out when using it (hands
> free
> > of course) in the car.
> 
> I might be tempted to model it ;-) - Go for it Ed - we need this world
> wide :-)
	ie the life time of a mobile phone call (in a car) depends on:
		the type of terminal, the make of car, its location,
speed and direction, the mobile aerial array (height/power), other
multiplexed services (capacities), etc, etc as well as the weather and
what big lumps of steel around - specifically tunnels and bridges, or if
a Roo has just hit the front of your car.

	Whoops I could be supporting your theory that the more
attributes things have, the shorter the lifetime of the object (the
call). :-)

> > As to certificate usage and lifetime - theory is useful - but
> practice
> > makes perfect.
> 
> Oh, not the cliche again! Don't have anything better down there? Yes -
> Roos generally - lots of them "Tie me kangaroo down sport" is often
> heard in certificate issuance processes when trying to give the
> buggers their smart cards. :-)
> 
> > What is the lifetime of a Bus or Train ticket... It depends on the
> > attitude and hunger of the damn machines that read them...QED
> 
> No -- their lifetime is actually the expected duration of their
> existence as
> tickets, ie, the expected duration of time that you can still use
> them. Well,
> I do have a metro ticket for Washington DC that I use for three months
> now... and I sure expect them to be valid this whole year, their
> lifetime.
	As I said with certs under a business policy - user will expect
a lifetime - regardless of the PKI theory see other mails.

> > PS - This person that predicted phone calls and phone connections -
> gee
> > he must be "one from on high" - can you ask him how big my next
> month's
> > bill will be :-)
> 
> His name was Agner Krarup Erlang -- Eralng for short. And his name is
> also
> the unit for phone traffic.
	I am sure Elang did not deal with Carrier tarrif systems  re
billing. I wonder what his wife was like re phone charges ?

	Have Fun  and regards alan

> Cheers,
> 
> Ed Gerck
> ______________________________________________________________________
> Dr.rer.nat. E. Gerck                                 [e-mail]
>   ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA05377 for ietf-pkix-bks; Wed, 2 Jun 1999 21:57:45 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA05373 for <[e-mail]>; Wed, 2 Jun 1999 21:57:43 -0700 (PDT)
Received: from mcg.org.br (pm07-11.sac.verio.net [209.162.65.30]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id VAA19991; Wed, 2 Jun 1999 21:58:49 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 Jun 1999 21:49:23 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: Alan Lloyd <[e-mail]>, Bob Blakley <[e-mail]>, Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: Re: Every time ..., was Re: General formula
References: <D1A949D4508DD1119C8100400533BEDC107794@DSG1> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony Bartoletti wrote:

> Ed,
>
> I still think the central problem begged by the formula is
> "What IS an attribute"?

Tony:

Yes, and in this context this is for PKIX to define. But, in the
equation, this is not relevant -- please see the comments I made
on "sub-attributes" in the original posting.  However, it may be
useful to group or ungroup attributes in order to simplify
calculations.

> To take Alan Lloyd's example, I certify a color table.  I can
> (it would seem, arbitrarily) consider the entire array of values
> as the table's "single attribute", or consider each color entry
> (say RGB triplet) to be an attribute, or even take each R, G,
> and B value separately as an attribute.
>
> If the lifetime/lifespan of the table depends upon the lifetime
> of each individual component, how do I know at what level of
> granularity to assign attribute-hood, and thus apply the formula
> correctly?

If you consider the whole certificate as one attribute -- fine. Then,
there is few to calculate but there is all to model.

If you consider each R, G, B component as different attributes -- fine.
Then, there is all to calculate but few to model.

Engineers usually work in-between these cases. The equation applies
to either case and also in-between.

> If you certify my name as "Tony", is that one attribute,
> or is it four (each letter a separate attribute.)
>
> As a first guess, I would say that if something can change
> independently of another thing (and yes, are treated semantically
> as separable values), then they can be separate attributes.

Yes.

> Otherwise, _in_the_context_ where two things are treated as
> completely dependent (redundant) by definition, then they cannot
> be treated as "two", as they are really "one".

Yes -- but most things are neither. Most things are partially dependent.
However, even if they are partially dependent, the equation is still the
same because the equation deals with the *effective* validity for each
attribute. I tried to explain this in the inlined reference [1] of my original
posting -- it would be useful if you could please check it and verify if
it is clear (at least, in hindsight).

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA05056 for ietf-pkix-bks; Wed, 2 Jun 1999 21:20:10 -0700 (PDT)
Received: from selva.dit.upm.es (selva-gw.dit.upm.es [138.4.2.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA05052 for <[e-mail]>; Wed, 2 Jun 1999 21:20:08 -0700 (PDT)
Received: from dit.upm.es (toro-3.dit.upm.es [138.4.21.3]) by selva.dit.upm.es (8.9.1a/8.9.1) with ESMTP id GAA25444; Thu, 3 Jun 1999 06:20:50 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 03 Jun 1999 06:29:24 +0200
From: "Jose A. Manas" <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Robert Zuccherato <[e-mail]>, "'Sarbari Gupta'" <[e-mail]>, "PKIX (E-mail)" <[e-mail]>
Subject: Re: Inclusion of a Status code within a TSAToken
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Terry Hayes wrote:

For time-stamps ...

> The token itself should be the "this is a valid token" statement.  It is a
> SignedData object, it has the proper content type OID, and is signed correctly
> by a valid TSA.  There is no need for an additional status field in the token.

I think there are some cases were warnings might be issued,
without preventing the time-stamp to be granted.
Either these warnings go into free data, or somehow get
a code that fits into the status code.
I prefer a field to encode them.

For error responses ...

> In summary - we need message imprint and/or nonce along with the error code.
> That's it.

Exactly.

Best,
pp

-- --------------------------------------------------------
Prof. Jose A. Manas                     <[e-mail]>
Dpt. Telematica                 http://www.dit.upm.es/~pepe
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA04859 for ietf-pkix-bks; Wed, 2 Jun 1999 20:57:39 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA04841 for <[e-mail]>; Wed, 2 Jun 1999 20:57:04 -0700 (PDT)
Received: from mcg.org.br (pm07-11.sac.verio.net [209.162.65.30]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id UAA07800; Wed, 2 Jun 1999 20:57:23 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 Jun 1999 20:47:56 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: Bob Blakley <[e-mail]>, Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: Re: Every time ..., was Re: General formula
References: <D1A949D4508DD1119C8100400533BEDC107795@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan Lloyd wrote:

> Ed - this is all too hard for me ... I cannot even predict how long my
> wife will be on the phone tonight

Alan:

Theory says that "how long your wife will be on the phone" does NOT
depend when you first noted that she was on the phone -- if this is
of any use to you, though it may already relate to your experience ;-)

This also means that if you call someone and it is busy, you could call
right afterwards (just add the round-trip total delay time -- say, 5 sec)
and your sucess rate should be the same as if you would wait some
minutes (as people normally do).

The reason in both cases is simple -- since phone statistics is given by
a Poison distribution and you don't know when the conversation actually
*started*, its end does not depend on the duration of your observation.

So, theory is nice -- when it corresponds to reality (as the above two
examples do). It allows us to use elevators, credit and rely on chemistry.


> or the number of times my mobile will drop out when using it (hands free
> of course) in the car.

I might be tempted to model it ;-)

> As to certificate usage and lifetime - theory is useful - but practice
> makes perfect.

Oh, not the cliche again! Don't have anything better down there?

> What is the lifetime of a Bus or Train ticket... It depends on the
> attitude and hunger of the damn machines that read them...QED

No -- their lifetime is actually the expected duration of their existence as
tickets, ie, the expected duration of time that you can still use them. Well,
I do have a metro ticket for Washington DC that I use for three months
now... and I sure expect them to be valid this whole year, their lifetime.

> PS - This person that predicted phone calls and phone connections - gee
> he must be "one from on high" - can you ask him how big my next month's
> bill will be :-)

His name was Agner Krarup Erlang -- Eralng for short. And his name is also
the unit for phone traffic.

 A.K. Erlang was the first person to study the problem of telephone networks.
 By studying a village telephone exchange he worked out a formula, now known
 as Erlang's formula, to calculate the fraction of callers attempting to call someone
 outside the village that must wait because all of the lines are in use. Although
 Erlang's model is a simple one, the mathematics underlying today's complex
 telephone networks is still based on his work.

Check in
 http://pass.maths.org.uk/issue2/erlang/index.html


> PPS good luck with the paper - is it signed - and how many
> attributes does it have.?

That is why long postings must be very carefully written; the more
you write the less it tends to live without at least one correction. I hope
this may be a good enough excuse for my long postings.... I risk more
when they are long ;-)

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA24932 for ietf-pkix-bks; Wed, 2 Jun 1999 15:57:32 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA24907 for <[e-mail]>; Wed, 2 Jun 1999 15:55:30 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <MCLY41AB>; Thu, 3 Jun 1999 08:54:47 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC107795@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>
Cc: Bob Blakley <[e-mail]>, Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: RE: Every time ..., was Re: General formula
Date: Thu, 3 Jun 1999 08:54:42 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed - this is all too hard for me ... I cannot even predict how long my
wife will be on the phone tonight or the number of times my mobile will
drop out when using it (hands free of course) in the car.

As to certificate usage and lifetime - theory is useful - but practice
makes perfect. 

What is the lifetime of a Bus or Train ticket... It depends on the
attitude and hunger of the damn machines that read them...QED

regards as always.

PS - This person that predicted phone calls and phone connections - gee
he must be "one from on high" - can you ask him how big my next month's
bill will be :-)

	PPS good luck with the paper - is it signed - and how many
attributes does it have.?

> -----Original Message-----
> From:	Ed Gerck 
> Sent:	Thursday, June 03, 1999 4:12 AM
> To:	Alan Lloyd
> Cc:	Bob Blakley; Graham Klyne; PKIX
> Subject:	Every time ..., was Re: General formula
> 
> 
> 
> Alan Lloyd wrote:
> 
> > Ed I  still do not know how anyone on this planet ...
> > can predict the life time of a cert.
> 
> Every time you make a phone call, it gets through because
> somebody on this planet was able to predict its duration.
> And yet, how can anybody on this planet be able to
> predict the lifetime (Lebendauer) of that connection?
> 
> The answer: By following very similar (though not
> equal) arguments as the ones I used. So, there is
> nothing magical about it.
> 
> I suggest you read my original posting here and its
> inlined reference [1]. The full paper will hopefully
> make it clearer also by examples.
> 
> Cheers,
> 
> Ed Gerck
> ______________________________________________________________________
> Dr.rer.nat. E. Gerck                                 [e-mail]
>   ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA23237 for ietf-pkix-bks; Wed, 2 Jun 1999 13:44:37 -0700 (PDT)
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 NAA23232 for <[e-mail]>; Wed, 2 Jun 1999 13:44:37 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id NAA04236; Wed, 2 Jun 1999 13:43:52 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 02 Jun 1999 13:43:27 -0700
To: Ed Gerck <[e-mail]>, Alan Lloyd <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Every time ..., was Re: General formula
Cc: Bob Blakley <[e-mail]>, Graham Klyne <[e-mail]>, PKIX <[e-mail]>
In-Reply-To: <[e-mail]>
References: <D1A949D4508DD1119C8100400533BEDC107794@DSG1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed,

I still think the central problem begged by the formula is
"What IS an attribute"?

To take Alan Lloyd's example, I certify a color table.  I can
(it would seem, arbitrarily) consider the entire array of values
as the table's "single attribute", or consider each color entry
(say RGB triplet) to be an attribute, or even take each R, G,
and B value separately as an attribute.

If the lifetime/lifespan of the table depends upon the lifetime
of each individual component, how do I know at what level of
granularity to assign attribute-hood, and thus apply the formula
correctly?

If you certify my name as "Tony", is that one attribute,
or is it four (each letter a separate attribute.)

As a first guess, I would say that if something can change
independently of another thing (and yes, are treated semantically
as separable values), then they can be separate attributes.

Otherwise, _in_the_context_ where two things are treated as
completely dependent (redundant) by definition, then they cannot
be treated as "two", as they are really "one".

___tony___

At 11:12 AM 6/2/99 -0700, Ed Gerck wrote:
>
>
>Alan Lloyd wrote:
>
>> Ed I  still do not know how anyone on this planet ...
>> can predict the life time of a cert.
>
>Every time you make a phone call, it gets through because
>somebody on this planet was able to predict its duration.
>And yet, how can anybody on this planet be able to
>predict the lifetime (Lebendauer) of that connection?
>
>The answer: By following very similar (though not
>equal) arguments as the ones I used. So, there is
>nothing magical about it.
>
>I suggest you read my original posting here and its
>inlined reference [1]. The full paper will hopefully
>make it clearer also by examples.
>
>Cheers,
>
>Ed Gerck
>______________________________________________________________________
>Dr.rer.nat. E. Gerck                                 [e-mail]
>  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---
>
>
>
>

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA23094 for ietf-pkix-bks; Wed, 2 Jun 1999 13:29:54 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA23090 for <[e-mail]>; Wed, 2 Jun 1999 13:29:49 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA14003 for <[e-mail]>; Wed, 2 Jun 1999 13:30:35 -0700 (PDT)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.03) with ESMTP id FCPVMZ00.0ZI; Wed, 2 Jun 1999 13:30:35 -0700 
Message-ID: <[e-mail]>
Date: Wed, 02 Jun 1999 13:30:05 -0700
From: [e-mail] (Terry Hayes)
Reply-To: [e-mail]
Organization: Netscape Communications, Inc.
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>
CC: "'Sarbari Gupta'" <[e-mail]>, "PKIX (E-mail)" <[e-mail]>
Subject: Re: Inclusion of a Status code within a TSAToken
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert Zuccherato wrote:

> Sarbari;
>
> > The status code is relevant only to the protocol between the TSA client
> > and the TSA. The TSA Token, on the other hand, has a much longer
> > life-span and may be processed by many, many, other entities. I would
> > strongly recommend that the status info not be included  the TSA Token.
> >
> I would tend to disagree with this statement.  Remember that these tokens
> will be used to support non-repudiation and may end up being used as
> evidence in some dispute resolution process.  Therefore, it does seem
> reasonable that some environments may require more than just "the absence of
> an error code means that this is a valid timestamp".  They may require a
> more explicit "this is a valid token" statement from the TSA.  This is what
> the presence of a value 0 (granted) provides in the present token structure.

The token itself should be the "this is a valid token" statement.  It is a
SignedData object, it has the proper content type OID, and is signed correctly
by a valid TSA.  There is no need for an additional status field in the token.

>
> > [ Error structure removed ]
> >
> The problem is that within your error structure you only have the status and
> nonce.  However, the TSA's policy information should also be included.  It
> may be helpful to have the TSA's name (see discussion of this topic in
> another thread).  For some error codes (e.g. tdaNotAvailable), the time
> would probably be a useful field to include, depending on policy.  If a
> nonce has not been used to link the request and response, then the
> messageImprint field must be present to do so.  The tsaFreeData field would
> probably be useful to some TSA's in the error response.  We probably also
> want to include the version, in case the format changes.  This accounts for
> all of the fields in the token except for tdaTokens and serialNumber, which
> are OPTIONAL.  Therefore, even if we used your proposal, we would end up
> with a structure that looked almost exactly like the present token.  Does it
> really make sense to define a separate structure for an error response with
> almost exactly the same fields as for a valid token?  I don't think so.

I disagree that all these fields are necessary (or even desirable).

Policy - I see no need for a policy identifier.  A policy would be useful if
there could be significant variation in the interpretation of the message.  In
that case the policy indicates what the signer intended the message to mean
within the framework of the protocol.  I don't see why we need to allow any
variation in the error response.

TSA Name - If the error response itself is signed, there is plenty of
opportunity to put the name of the TSA in the SignerInfo field.

time - I don't see why the current time would be useful in a message that
indicates an error occured.  The operation failed, we shouldn't provide partial
results unless they might be useful in future exchanges with the TSA.

serialNumber and tdaTokens - you say they are OPTIONAL.  I say that's a
problem.  These fields shouldn't be allowed in the error responses.  It's better
to leave them out of the definition of the response data type.

message imprint - you are correct here.  If the initial request had a message
imprint, it would be useful to put it in the response to allow the client to
match the two parts of the exchange.

In summary - we need message imprint and/or nonce along with the error code.
That's it.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA22990 for ietf-pkix-bks; Wed, 2 Jun 1999 13:18:09 -0700 (PDT)
Received: from USlink.net (link3.uslink.net [199.199.168.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA22986 for <[e-mail]>; Wed, 2 Jun 1999 13:18:08 -0700 (PDT)
Received: from iami.org ([206.146.187.195]) by USlink.net (8.9.3/8.8.8) with SMTP id PAA07163 for <[e-mail]>; Wed, 2 Jun 1999 15:19:50 -0500 (CDT)
Received: from ntserver.iami.org [206.146.187.234] by iami.org (1.61/SMTP) for <[e-mail]>
Date: Wed, 02 Jun 99 14:17:35 Central Daylight Time
Message-Id: <[e-mail]>
Message-ID: <006f01bead2b$e1b224e0$[e-mail]>
From: "IAMI" <[e-mail]>
To: <[e-mail]>
Subject: Information on National Association of Mortgage Underwriters
Date: Wed, 2 Jun 1999 14:12:39 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0069_01BEAD01.F8DC1CE0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0069_01BEAD01.F8DC1CE0
Content-Type: multipart/related;
	boundary="----=_NextPart_001_006A_01BEAD01.F8DC1CE0";
	type="multipart/alternative"


------=_NextPart_001_006A_01BEAD01.F8DC1CE0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_006B_01BEAD01.F8DC1CE0"


------=_NextPart_002_006B_01BEAD01.F8DC1CE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






ATTN: Mortgage Underwriting Department

On behalf of the Board of Directors, I would like to invite you to =
become a member of the National Association of Review Appraisers and =
Mortgage Underwriters and hold the professional designation =
"RMU-Registered Mortgage Underwriter". Membership includes a =
subscription to the NARA/MU Appraisal Review & Mortgage Underwriting =
Journal, The Reviewing Times newsletter, "How to" Guideline booklets, =
the Association's Directory of Members plus much more.
=20
For more information and your convenience, I have provided links =
directly to our website and application page.
=20
Sincerely,
Robert G. Johnson
Executive Director
NATIONAL ASSOCIATION OF REVIEW APPRAISERS AND MORTGAGE UNDERWRITERS
http://www.iami.org/nara.html
http://www.iami.org/nara/apply.html
=20

------=_NextPart_002_006B_01BEAD01.F8DC1CE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML =
PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><IMG align=3Dbaseline =
alt=3D"" border=3D0=20
hspace=3D0 =
src=3D"cid:005901bead2b$e176a280$[e-mail]"></DIV>
<DIV><FONT color=3D#000000 size=3D2>ATTN: Mortgage Underwriting =
Department<BR><BR>On=20
behalf of the Board of Directors, I would like to invite you to become a =
member=20
of the National Association of Review Appraisers and Mortgage =
Underwriters and=20
hold the professional designation &quot;RMU-Registered Mortgage=20
Underwriter&quot;. Membership includes a subscription to the NARA/MU =
Appraisal=20
Review &amp; Mortgage Underwriting Journal, The Reviewing Times =
newsletter,=20
&quot;How to&quot; Guideline booklets, the Association's Directory of =
Members=20
plus much more.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;<FONT color=3D#000000 =
size=3D2><BR>For=20
more information and your convenience, I have provided links directly to =
our=20
website and application page.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Sincerely,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Robert G. Johnson<BR>Executive=20
Director</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>NATIONAL ASSOCIATION OF REVIEW =
APPRAISERS <FONT=20
color=3D#000000 size=3D2>AND MORTGAGE UNDERWRITERS</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.iami.org/nara.html">http://www.iami.org/nara.html</A><=
/FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.iami.org/nara/apply.html">http://www.iami.org/nara/app=
ly.html</A></FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000=20
size=3D2></FONT></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_002_006B_01BEAD01.F8DC1CE0--

------=_NextPart_001_006A_01BEAD01.F8DC1CE0
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Content-ID: <005901bead2b$e176a280$[e-mail]>

/9j/4AAQSkZJRgABAAEAYABgAAD//gAfTEVBRCBUZWNobm9sb2dpZXMgSW5jLiBWMS4wMQD/2wCE
ABUODxIPDRUSERIXFhUZHzQiHx0dH0AuMCY0TENQT0tDSUhUX3lmVFlyW0hJaY9qcn2Bh4mHUWWV
n5OEnnmFh4IBFhcXHxsfPiIiPoJXSVeCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKC
goKCgoKCgoKCgoKCgoKCgv/EAaIAAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKCwEAAwEBAQEB
AQEBAQAAAAAAAAECAwQFBgcICQoLEAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEU
MoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl
ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK
0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+foRAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYS
QVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNU
VVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5
usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/AABEIAG8AzwMBEQACEQEDEQH/
2gAMAwEAAhEDEQA/AOxoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo
AKACgAoAKACgAoAKAOeubueG+nRpX8mW8hijGfuN+7JX6Mpb2+U/3qAJLvVbsLeLEETZFK8Uu3IB
jIDDryee4ABH8Q5oAnW6unvXtEkjWRSSXdNy/KsZICggjJkzyTjHvwARJrUjRLcskaREYKsTkHyf
NyWHbHGNue/tQA6K8uZZrdZlMUiXRicD5dw8lmGQGYdx3PTPsACG4mk/tX7Wsc5ht3WIurDy9p++
T83YsM8HHl9RzgAstf3Mcs8YEJ4PkHdwxDBSM55OWAwdvPGTywAIn1S4MEzgRKbaIySqVJLkM4Kj
n5T+7P8AeHPcDJAJDfTYLMYwjTeWiqcOMTCMnnIYHOTwMZA75ABVfULy4gbyykLeZBIj7SQyPJgD
hskcdTgkEjatAE7alPtuZIymLRXkcSDcXAeQbQRjb/q+uD1HXHIBZtb6Wa88tlTy383YADlfLcIc
nvnOegx0560AMW9uXlQgwiOWaSBAVJKMu/5ic8j5DxgdevHIBJovmnSbRpHLu8QcsxJJyM8kknv/
APq6UAaFABQAUAFABQAUAFABQAUAFABQAUAQmGIlgY1O5g54HLDGD9RgfkKAG/ZoBOZhCglJBL7R
uJAIBz9CR+NADHsLR4vKa2hMYIOwxgjIGAcfTj6UAYV14jW2u5YzpyM0czfP5nJI+Xd93rjj6cVn
zq9i+U1tK+yXFlb3NvbxRgrkBUA2HnIHA6EsPxPrVp3IYupzx2GmTyGBXjH3o+gbc2Dnjvkmhuyu
NK5n6Pq8GrXc8J0+OIvHukbIbzAMDB4GeD3pRlcbVjZaztmMW63iPk/6rKD930+76dB09KokwL/x
DaWt9LHHYLK24b5CQu5lPHY5xjg+3FS5WKUS/pNxaanbySJawxsWYSptBzuxknjkHAznrj2ojLmQ
mrF9rO2dkLQRM0bFkJQEqxOSR6HPNUIesMaMGWNFYbsEAZGTk/meTQAi28C3DTrFGJmGGkCjcR6E
9ew/KgB8aLEgRFCqowqqMAD0FAElABQAUAFABQAUAFABQAUAFABQAUAFABQAUAea6tKw1W8AJ4nf
p/vGsXFXNU9DU8J6q0F59jmIEUxyhOOH+vvjH1xVx00JkdF4lG7QrkZx93/0IUTdoijuYXhAAalJ
gf8ALE/+hLWdP4ip7HVXU32a0mmxu8pGfbnGcDOK2eiMzz1Lea9kkOSWVWldjk8AZJJ/zyawW5sz
U8J3Zh1QwHO2dCAAP4l5H6Z/Orp7kyO1rUzCgAoAKACgAoAKACgAoAKACgAoAjlljgjMkrqiDqzH
AH40AV/7V0//AJ/rX/v8v+NK6HZh/alhjP262x6+av8AjRdBZijVLA9L22P/AG1X/Gi6CzD+07H/
AJ/bb/v6v+NLmXcLMT+1dP8A+f8Atf8Av8v+NO6CzF/tOwzj7bbZ9PNX/GjmXcLM47UdPu5NRuZF
tbggzMVKxEhhk89Kxad3oaJqxc17Sp4NQ+1WccjiRi/7pSWRh1Ofrz/+qqlF3uhJ6amleTXGoeHZ
Ga1lSc7Q0XltnIYdAR0xz/8Aqpyu4krRlLwva3EGoSNPbSxDySAzoQDyKmCaZUnoX/E5uZLBILaG
WQyPl9ibhtHOD6c4/I1cr2sTHcg8LWEsHn3FxE0bnCIHBBx1PB7dPyNTTjbUcmYY069tL7dFazye
RLlG8lsNtPB+hxU2knoirpo7MahahVMs8cLlQTHI4VlyM4Izwa15kZ2Yp1OwHBvbYf8AbVf8afMg
sw/tOwPS9tv+/q/40cy7hZh/adh/z+23/f1f8aXMu4WYf2nYf8/tt/39X/GjmXcLMP7TsOP9Ntue
n71ef1p8y7hZgupWTOqJd27MxwFEikk/nRdBZlumIKACgAoAKAMrxNj+wrnIz93/ANCFTPYcdyz/
AGVp/wDz42v/AH5X/CnZBdinS7AjBsrbH/XJf8KOVBdif2Vp/wDz4Wv/AH5X/CiyC7F/sywxj7Fb
Y/65L/hRyrsF2J/ZWng5+w2v/flf8KLILsX+zLDOfsVt/wB+l/wpcq7BdnGanf3seo3Kpd3CosrA
KshGBuPvWTk7miSsdteQNc2zxJM8LMOJEOCprZq6MkcC2r6pb/aLV7iUMTsbMhLIQexzx0xU6ovc
1fCF5dXOpyJPcTSqIScPIWGdy880J6ikRa5qVw2rSpb3cscUbBMIxUDHX9c1EpO5UVoQpr+oxoFW
6baOm5Qx/MjNSpSWlx8qIbnWb+Zt73sy8YGxtn6DFPmkwsjofDptNSs2+0wRzXERw7yqHZgehJI+
o/CrjZrUiWmxrHTLA9bK2P8A2yX/AAq+VdhXYDTLEdLK2H/bJf8AClyrsF2A0yxHSytv+/S/4Ucq
7BdgdNsTjNnbnAwMxL/hT5UF2A0yxHSyth/2yX/ClyrsF2Zur2dtbvp7wwQxMbyMZRADjnjik0la
w0zdqyQoAKACgAoAyvE+f7Bucf7P/oQqZ7DjuatUIKACgAoAKACgDgtRsLyS/uDHa3Dq0zkERtjG
49KwcXduxqmrHe1uZHLeKNIaWVLy3ieR3O2VVBY8Dg4A9Bg/hUST3RcWV9AgutOuLiZ7Sf5YG2r5
bDc2RgDioje97DlYqWen3bajA89rcMrTKZC8TEEZ5zkfnSSbeqG2rHeVuZGR4mtPteksFjeSSN1d
EQZJPTp9CamS00HHcw/DIvbLUQs9ncpFKuxiY2Cg9QTx+H41MVZlS1R2daEBQAUAFABQBk69/wAw
7/r+i/rUvoM1qoQUAFABQAUAY/ik48PXRH+z/wChik9hrcz/ABlcXFubL7PcSw7t+7y3K5+7jpSk
7DiYcVxrNxETBLqEoVsEoztz9RUq7K0Qjy65bjzJ5NRSMfeZy4A545pu9haGro/ia5N5Ha3uJRK4
QMqgMpOAOnGP8+1CbYOJ2FWQUtVuvsenXE4JDKnykDOCeB+pqZOyuNK7OFOpahyfttzj/rq3+NZc
zNLHd6XcC7063n3b2ZBubGMsOD+ua2TujN7lymIyfElybbSZAuQ0pEYwAevX9AaibtEqKuyh4Qtk
WGa44JZvLHy8qAMnn3yPyqaa3Y5mJqWoXo1C8SO7uEVJnVVWVhgAnpzSbaY0tDb8IX8twlxBczGS
RSHXexLYPB69uB+dXF3JkjX1e4+y6Xcy5YEIQCnUE8A/macnZCW5wi6vfk4+2XAz0/et/jWevc00
Osv55U8KJOJJFl8mI7wxDZJXPNW78pC3M/wreXNxqUiTzyyIISQHckZ3L61MHqOWx1takHEa/qN3
ba1cRxXEyxrtwqyEAfKKyle+5cdjZvGL6dozucs1xASWPJOP50+iF1ZvVoSFABQAUAFAGR4p50C6
H+5/6GKUthrcy/HHBsSen7zP/jtTMcS14JOdJm/6+D/6CtOOwS3OhqiTy68VJdQlS0VnRpCIlUEk
gn5fes15Gh6jWhmcv4uuSHt7YdMGRgRwT0H/ALN+dY1H0NILqZj6Y66JFduVLNIQdgJ+XHGfTkH/
AL6FS46cyHfWxpeDbkKtxZkjIIlXg5PY/wDsv51pB3Jkjqa0IOR8aX0iTwWi/cC+Y3uSSB+WD+dZ
zV9C4m/o0DW+lW0b5DbNxBGCCecfhnFVFWViW7s5Fog3iQ7grRvelSp5z8/IIrP7RfQn8LyG01w2
8ykSMjx4AHDA5OT/AMBNOK1CWxreLbjZZQ24LAyvk46YHY/iR+VFR6CgtTlNQsvsn2ReN8luJGIP
Ulmx+mKL6DOr1IEeDEB6+RD/ADWqfwkr4jM8HZGqyenkH/0JainuVLY7OtjM4HxGoPiO6J6DZ/6A
KxqM0idBc86bov8A13g/9Bp9Ii6s3q1ICgAoAKACgDN162lu9JnggTfK+3auQM4YHvSktBrcxNd/
08QDVc6XsLeX/wAt/MzjP3emOOvrUvzGvIq2GmzSRt/Zeo3rwK+C0KBFLYBPBkB7jtRbsFx95pt5
HbNJfXGoyRqc4aNX28dcCQ4781MkxpkekHS7ZhKkn2u8LAQRSRtGQ2SMZG5cnjBPTjp2tWB3OhF/
rH/QE/8AJtP8Kd2TZGHeLpuoXUtydUC726C2fgAYH6CspKLd2y1e2xuMunS6YbCO7g2bAikSAkHs
eCMnPPvV+7axOt7mLYCw027E8OpebIoYCMxNGHJHALHgDOOtRGyejKd30NwX2q/9Acf+BS/4Vd5d
iLLucs+/WNY84wb2lcHyt2MqB0z9B1rLmbkaWsjqft2q/wDQI/8AJla1vLsRZdzHW2sBrZcan+9N
zu8ryG+9v+7n68ZqXFc17ju7C6jZWNjry3cmom2csJfKETHIzz8wPfB/Oq0TErtFjW4rXUNRjt5N
Q8qSPCiLyS3zNjv78VMrN2uON0iPXLHTxdwia9FsY4VRE8pn+UE4OaU0trhFs0LyGBvDixvc7YfK
jHnbCeBjB29ef61btyiW5T8O29lBeuba989/KOV8krxkc5P+eaiCV9GOV7HSVsQcjrtnYvqkktxq
P2eRtp2fZ2bHygdR1rNpX1ZabsXmjubhNPghtt9rA8Mi3G8DeoA52nkdaGnpYWmp0FaEhQAUAFAB
QAUAcn46GTY88/vP/ZaiRUSz4IGNIlz/AM/B/wDQVpx2FI6B0WRCjqGVhggjIIqhHmWjN/xObLP/
AD3T/wBCFRYtndeJLsWujT8jdKPLUEHnPX9M1UnZErc4/SNPm1GRoYGRWVdx3kgdcdgfWsbczNL2
Rqr4W1FDlZrYMDkHc3B/75o9mxc6MrU7W4s7x4bggyHDZGcNnuM0NWeo07nWRaox8NteuwSVYiCe
vz9AcY7nB/GtOb3bkW1sZvg/zpLiVy48qOPbt9yeP5GoprUqZ1lbGZwu3/ip84H/AB+/+z1z3941
+yXvGcAWa2uQrEsDGT/CMcj8eT+VXNdSYlGxmk1XxFBNLtRncOdg4+UZ9f8AZpL3pDeiLPi8/wDE
0j9oB/6E1KpuENjXuIZLjwskcS7n+zxsFx1wAcD34q2rwsSnaRz2hajFYX4mlB8t0KMR/Dkg59+l
ZwfK9S5K6OqbWtNSLzTeRbcA4DZbn/Z6/pW/MjOzOL1K5Op6nJPDE2JWAROpPAA/HjpWTd2aLRHe
WULW9lBC5BaONUJHTIGK1SsjJlmmAUAFABQAUAFAGPr2hnWfI/0jyfJ3fwbs5x7j0pNXGnYl0PSz
pNo8Hn+ducvu27ccAY6n0oSsDdy+rq7MAQSpwwB6HGcH8CPzpiOXHgvy5RJDqDIVOU/d/MvpyGHP
vSsVzGrrmjtq6woLkwrGSSNu4MT07jpz+dDVxJ2HaJo66RDKok815GyXC7eB0GMn3/OklYG7mrVC
MjWNFXU5IXEoiZAQTsyWHbuOnP51Eo3KjKxXPh1m0/7Ebv5RKJQ3lcjgjHWpULK1x82ty/pGnLpl
oYVkMmXLFiMc9OB+Aq4xsrEt3NCqEYQ8O41P7Z9q/wCW3m7PL/2s4zmsvZ63uXzaWLetaYdVtEgE
3k7XD7tu7sRjqPWtGrkp2K2jaB/ZNy032nziyFMbNvcH1PpUqNncbdw1jQf7Uulm+0mLagTaEz3J
z196JQu7gpWNS1h+zWkMOd3loqbsYzgYzVJWRJkX/hm2upPMgb7MxwCqqCh/DjB6VMoJlKVjHPg7
UDkeba4/3m/+JpcjHzI29G8PQ6U7SM/nTHhXK42j2GTz7/5NJWJbNuqEFABQAUAYd7bNc6rMEs7O
4cW0YU3B4Q7pOg2nPv06UAV7W9u3a3iS7AUpEqCRgJJFKKS+zaxJ5bndgFeeAcgEjX18bZZ/LzKX
ZEiXOC6xOW4Byf3gK4ORhRj1oAIdQvUUyiaK7iUhPklDgswIA3hFAO4IO+N5J4xgAtWl3cqsrXxC
i0iCzFeQzjJZuBn7uxgAP4yOSOADMP2nTAJpVhs2vGQSyo4YhzJuPVcD5Wk5O4YUc8cgFkX5NwiS
ap5Vt+82XGYx5uBHjkrtOCzjgDp7GgBTqV7JaM8rR2zBo0JI2eWTEHbczbgvJwMqfTqcgAU6hO8G
4ypbOYYWdiSqqxLhlJIYJgrjJB9OuMACJf3z30SmRIsmMCB/kZ1KqWOzaW4JYZDYG3nocgEiX90w
sJGmj3TormJExu3HsDndgHnDDbjJyCBQBHr84jlQyhRHCqvtLBS+XG4pn+NVXAwc/vOCDjIBNrbu
8VjNbMXKz+anlnPmBY3baMf3gMfj3oApQ3btfz3RuHgt7nyz5jDHlRjzQpG4YAYqDyP4/XmgCw1z
e3VneRxysDHbs0TRr+8kO9wpB6cqg6DndkY4oAaNUkTZsvPPmZpF8gBGOxVcq4UYJLBVPXB3cYyM
ACxajK1sFlu41UT7WuEdWxGUJDbtoXlxsztx1HXmgCJ9VvHCmG4gCAN5Ts4HnkSOvQK2/hVJCbT8
3HUYANK7mit9Rt5p5EijEUqb3YKu4tGQMnvwfyNAFK2nubaC0iyU8qC2DRlfvF22MGzyMY4xjnrn
pQBVbUJprhbmG5Qy+QwaAgKbY+bGGycZGB3YEfKTjHFAFqK7v5VWOGaGZwksiMvz+Zt2YXdhV5Zi
CQOgxkHJoAbNql6sMsqKojZWuIGyDmJUPUYGMsEPriTHBGQALfXF5GXeOR90FxtKxg7ZD5AIBBzg
FiAAD/F/ewaAHWd7cmSKIXUE6STKnmK3m4Gx2YblVBn5R6kZyeooAt6XdyyvOJZfOCkEMqcDOcr0
BBGBlTkrkZY54ANOgAoAKACgAoAilhSVAjrkBlYDPdSCP1AoAGiVpklK/OilQc9iQT/6CKAJaACg
AoAKACgAoAKACgCsLeJrnz/nZwerOSq8YyFJwDjuB3PqaAJJohNH5bbwp7o5U/mCDQA2CNIIgiDg
dz1PqSe57570AT0AFABQAUAFABQAUAFAH//Z

------=_NextPart_001_006A_01BEAD01.F8DC1CE0--

------=_NextPart_000_0069_01BEAD01.F8DC1CE0
Content-Type: application/octet-stream;
	name="MU Application FORM.url"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="MU Application FORM.url"

[InternetShortcut]
URL=http://www.iami.org/nara/apply.html
Modified=40B9EBAC7EA7BE0174

------=_NextPart_000_0069_01BEAD01.F8DC1CE0
Content-Type: application/octet-stream;
	name="MU Homepage.url"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="MU Homepage.url"

[InternetShortcut]
URL=http://www.iami.org/nara.html
Modified=206A36A47EA7BE0148

------=_NextPart_000_0069_01BEAD01.F8DC1CE0--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA22980 for ietf-pkix-bks; Wed, 2 Jun 1999 13:18:03 -0700 (PDT)
Received: from USlink.net (link3.uslink.net [199.199.168.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA22973 for <[e-mail]>; Wed, 2 Jun 1999 13:18:01 -0700 (PDT)
Received: from iami.org ([206.146.187.195]) by USlink.net (8.9.3/8.8.8) with SMTP id PAA07120 for <[e-mail]>; Wed, 2 Jun 1999 15:19:43 -0500 (CDT)
Received: from ntserver.iami.org [206.146.187.234] by iami.org (1.61/SMTP) for <[e-mail]>
Date: Wed, 02 Jun 99 14:17:35 Central Daylight Time
Message-Id: <[e-mail]>
Message-ID: <006f01bead2b$e1b224e0$[e-mail]>
From: "IAMI" <[e-mail]>
To: <[e-mail]>
Subject: Information on National Association of Mortgage Underwriters
Date: Wed, 2 Jun 1999 14:12:39 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0069_01BEAD01.F8DC1CE0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0069_01BEAD01.F8DC1CE0
Content-Type: multipart/related;
	boundary="----=_NextPart_001_006A_01BEAD01.F8DC1CE0";
	type="multipart/alternative"


------=_NextPart_001_006A_01BEAD01.F8DC1CE0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_006B_01BEAD01.F8DC1CE0"


------=_NextPart_002_006B_01BEAD01.F8DC1CE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






ATTN: Mortgage Underwriting Department

On behalf of the Board of Directors, I would like to invite you to =
become a member of the National Association of Review Appraisers and =
Mortgage Underwriters and hold the professional designation =
"RMU-Registered Mortgage Underwriter". Membership includes a =
subscription to the NARA/MU Appraisal Review & Mortgage Underwriting =
Journal, The Reviewing Times newsletter, "How to" Guideline booklets, =
the Association's Directory of Members plus much more.
=20
For more information and your convenience, I have provided links =
directly to our website and application page.
=20
Sincerely,
Robert G. Johnson
Executive Director
NATIONAL ASSOCIATION OF REVIEW APPRAISERS AND MORTGAGE UNDERWRITERS
http://www.iami.org/nara.html
http://www.iami.org/nara/apply.html
=20

------=_NextPart_002_006B_01BEAD01.F8DC1CE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML =
PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><IMG align=3Dbaseline =
alt=3D"" border=3D0=20
hspace=3D0 =
src=3D"cid:005901bead2b$e176a280$[e-mail]"></DIV>
<DIV><FONT color=3D#000000 size=3D2>ATTN: Mortgage Underwriting =
Department<BR><BR>On=20
behalf of the Board of Directors, I would like to invite you to become a =
member=20
of the National Association of Review Appraisers and Mortgage =
Underwriters and=20
hold the professional designation &quot;RMU-Registered Mortgage=20
Underwriter&quot;. Membership includes a subscription to the NARA/MU =
Appraisal=20
Review &amp; Mortgage Underwriting Journal, The Reviewing Times =
newsletter,=20
&quot;How to&quot; Guideline booklets, the Association's Directory of =
Members=20
plus much more.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;<FONT color=3D#000000 =
size=3D2><BR>For=20
more information and your convenience, I have provided links directly to =
our=20
website and application page.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Sincerely,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Robert G. Johnson<BR>Executive=20
Director</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>NATIONAL ASSOCIATION OF REVIEW =
APPRAISERS <FONT=20
color=3D#000000 size=3D2>AND MORTGAGE UNDERWRITERS</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.iami.org/nara.html">http://www.iami.org/nara.html</A><=
/FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.iami.org/nara/apply.html">http://www.iami.org/nara/app=
ly.html</A></FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000=20
size=3D2></FONT></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_002_006B_01BEAD01.F8DC1CE0--

------=_NextPart_001_006A_01BEAD01.F8DC1CE0
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Content-ID: <005901bead2b$e176a280$[e-mail]>

/9j/4AAQSkZJRgABAAEAYABgAAD//gAfTEVBRCBUZWNobm9sb2dpZXMgSW5jLiBWMS4wMQD/2wCE
ABUODxIPDRUSERIXFhUZHzQiHx0dH0AuMCY0TENQT0tDSUhUX3lmVFlyW0hJaY9qcn2Bh4mHUWWV
n5OEnnmFh4IBFhcXHxsfPiIiPoJXSVeCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKC
goKCgoKCgoKCgoKCgoKCgv/EAaIAAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKCwEAAwEBAQEB
AQEBAQAAAAAAAAECAwQFBgcICQoLEAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEU
MoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl
ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK
0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+foRAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYS
QVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNU
VVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5
usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/AABEIAG8AzwMBEQACEQEDEQH/
2gAMAwEAAhEDEQA/AOxoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo
AKACgAoAKACgAoAKAOeubueG+nRpX8mW8hijGfuN+7JX6Mpb2+U/3qAJLvVbsLeLEETZFK8Uu3IB
jIDDryee4ABH8Q5oAnW6unvXtEkjWRSSXdNy/KsZICggjJkzyTjHvwARJrUjRLcskaREYKsTkHyf
NyWHbHGNue/tQA6K8uZZrdZlMUiXRicD5dw8lmGQGYdx3PTPsACG4mk/tX7Wsc5ht3WIurDy9p++
T83YsM8HHl9RzgAstf3Mcs8YEJ4PkHdwxDBSM55OWAwdvPGTywAIn1S4MEzgRKbaIySqVJLkM4Kj
n5T+7P8AeHPcDJAJDfTYLMYwjTeWiqcOMTCMnnIYHOTwMZA75ABVfULy4gbyykLeZBIj7SQyPJgD
hskcdTgkEjatAE7alPtuZIymLRXkcSDcXAeQbQRjb/q+uD1HXHIBZtb6Wa88tlTy383YADlfLcIc
nvnOegx0560AMW9uXlQgwiOWaSBAVJKMu/5ic8j5DxgdevHIBJovmnSbRpHLu8QcsxJJyM8kknv/
APq6UAaFABQAUAFABQAUAFABQAUAFABQAUAQmGIlgY1O5g54HLDGD9RgfkKAG/ZoBOZhCglJBL7R
uJAIBz9CR+NADHsLR4vKa2hMYIOwxgjIGAcfTj6UAYV14jW2u5YzpyM0czfP5nJI+Xd93rjj6cVn
zq9i+U1tK+yXFlb3NvbxRgrkBUA2HnIHA6EsPxPrVp3IYupzx2GmTyGBXjH3o+gbc2Dnjvkmhuyu
NK5n6Pq8GrXc8J0+OIvHukbIbzAMDB4GeD3pRlcbVjZaztmMW63iPk/6rKD930+76dB09KokwL/x
DaWt9LHHYLK24b5CQu5lPHY5xjg+3FS5WKUS/pNxaanbySJawxsWYSptBzuxknjkHAznrj2ojLmQ
mrF9rO2dkLQRM0bFkJQEqxOSR6HPNUIesMaMGWNFYbsEAZGTk/meTQAi28C3DTrFGJmGGkCjcR6E
9ew/KgB8aLEgRFCqowqqMAD0FAElABQAUAFABQAUAFABQAUAFABQAUAFABQAUAea6tKw1W8AJ4nf
p/vGsXFXNU9DU8J6q0F59jmIEUxyhOOH+vvjH1xVx00JkdF4lG7QrkZx93/0IUTdoijuYXhAAalJ
gf8ALE/+hLWdP4ip7HVXU32a0mmxu8pGfbnGcDOK2eiMzz1Lea9kkOSWVWldjk8AZJJ/zyawW5sz
U8J3Zh1QwHO2dCAAP4l5H6Z/Orp7kyO1rUzCgAoAKACgAoAKACgAoAKACgAoAjlljgjMkrqiDqzH
AH40AV/7V0//AJ/rX/v8v+NK6HZh/alhjP262x6+av8AjRdBZijVLA9L22P/AG1X/Gi6CzD+07H/
AJ/bb/v6v+NLmXcLMT+1dP8A+f8Atf8Av8v+NO6CzF/tOwzj7bbZ9PNX/GjmXcLM47UdPu5NRuZF
tbggzMVKxEhhk89Kxad3oaJqxc17Sp4NQ+1WccjiRi/7pSWRh1Ofrz/+qqlF3uhJ6amleTXGoeHZ
Ga1lSc7Q0XltnIYdAR0xz/8Aqpyu4krRlLwva3EGoSNPbSxDySAzoQDyKmCaZUnoX/E5uZLBILaG
WQyPl9ibhtHOD6c4/I1cr2sTHcg8LWEsHn3FxE0bnCIHBBx1PB7dPyNTTjbUcmYY069tL7dFazye
RLlG8lsNtPB+hxU2knoirpo7MahahVMs8cLlQTHI4VlyM4Izwa15kZ2Yp1OwHBvbYf8AbVf8afMg
sw/tOwPS9tv+/q/40cy7hZh/adh/z+23/f1f8aXMu4WYf2nYf8/tt/39X/GjmXcLMP7TsOP9Ntue
n71ef1p8y7hZgupWTOqJd27MxwFEikk/nRdBZlumIKACgAoAKAMrxNj+wrnIz93/ANCFTPYcdyz/
AGVp/wDz42v/AH5X/CnZBdinS7AjBsrbH/XJf8KOVBdif2Vp/wDz4Wv/AH5X/CiyC7F/sywxj7Fb
Y/65L/hRyrsF2J/ZWng5+w2v/flf8KLILsX+zLDOfsVt/wB+l/wpcq7BdnGanf3seo3Kpd3CosrA
KshGBuPvWTk7miSsdteQNc2zxJM8LMOJEOCprZq6MkcC2r6pb/aLV7iUMTsbMhLIQexzx0xU6ovc
1fCF5dXOpyJPcTSqIScPIWGdy880J6ikRa5qVw2rSpb3cscUbBMIxUDHX9c1EpO5UVoQpr+oxoFW
6baOm5Qx/MjNSpSWlx8qIbnWb+Zt73sy8YGxtn6DFPmkwsjofDptNSs2+0wRzXERw7yqHZgehJI+
o/CrjZrUiWmxrHTLA9bK2P8A2yX/AAq+VdhXYDTLEdLK2H/bJf8AClyrsF2A0yxHSytv+/S/4Ucq
7BdgdNsTjNnbnAwMxL/hT5UF2A0yxHSyth/2yX/ClyrsF2Zur2dtbvp7wwQxMbyMZRADjnjik0la
w0zdqyQoAKACgAoAyvE+f7Bucf7P/oQqZ7DjuatUIKACgAoAKACgDgtRsLyS/uDHa3Dq0zkERtjG
49KwcXduxqmrHe1uZHLeKNIaWVLy3ieR3O2VVBY8Dg4A9Bg/hUST3RcWV9AgutOuLiZ7Sf5YG2r5
bDc2RgDioje97DlYqWen3bajA89rcMrTKZC8TEEZ5zkfnSSbeqG2rHeVuZGR4mtPteksFjeSSN1d
EQZJPTp9CamS00HHcw/DIvbLUQs9ncpFKuxiY2Cg9QTx+H41MVZlS1R2daEBQAUAFABQBk69/wAw
7/r+i/rUvoM1qoQUAFABQAUAY/ik48PXRH+z/wChik9hrcz/ABlcXFubL7PcSw7t+7y3K5+7jpSk
7DiYcVxrNxETBLqEoVsEoztz9RUq7K0Qjy65bjzJ5NRSMfeZy4A545pu9haGro/ia5N5Ha3uJRK4
QMqgMpOAOnGP8+1CbYOJ2FWQUtVuvsenXE4JDKnykDOCeB+pqZOyuNK7OFOpahyfttzj/rq3+NZc
zNLHd6XcC7063n3b2ZBubGMsOD+ua2TujN7lymIyfElybbSZAuQ0pEYwAevX9AaibtEqKuyh4Qtk
WGa44JZvLHy8qAMnn3yPyqaa3Y5mJqWoXo1C8SO7uEVJnVVWVhgAnpzSbaY0tDb8IX8twlxBczGS
RSHXexLYPB69uB+dXF3JkjX1e4+y6Xcy5YEIQCnUE8A/macnZCW5wi6vfk4+2XAz0/et/jWevc00
Osv55U8KJOJJFl8mI7wxDZJXPNW78pC3M/wreXNxqUiTzyyIISQHckZ3L61MHqOWx1takHEa/qN3
ba1cRxXEyxrtwqyEAfKKyle+5cdjZvGL6dozucs1xASWPJOP50+iF1ZvVoSFABQAUAFAGR4p50C6
H+5/6GKUthrcy/HHBsSen7zP/jtTMcS14JOdJm/6+D/6CtOOwS3OhqiTy68VJdQlS0VnRpCIlUEk
gn5fes15Gh6jWhmcv4uuSHt7YdMGRgRwT0H/ALN+dY1H0NILqZj6Y66JFduVLNIQdgJ+XHGfTkH/
AL6FS46cyHfWxpeDbkKtxZkjIIlXg5PY/wDsv51pB3Jkjqa0IOR8aX0iTwWi/cC+Y3uSSB+WD+dZ
zV9C4m/o0DW+lW0b5DbNxBGCCecfhnFVFWViW7s5Fog3iQ7grRvelSp5z8/IIrP7RfQn8LyG01w2
8ykSMjx4AHDA5OT/AMBNOK1CWxreLbjZZQ24LAyvk46YHY/iR+VFR6CgtTlNQsvsn2ReN8luJGIP
Ulmx+mKL6DOr1IEeDEB6+RD/ADWqfwkr4jM8HZGqyenkH/0JainuVLY7OtjM4HxGoPiO6J6DZ/6A
KxqM0idBc86bov8A13g/9Bp9Ii6s3q1ICgAoAKACgDN162lu9JnggTfK+3auQM4YHvSktBrcxNd/
08QDVc6XsLeX/wAt/MzjP3emOOvrUvzGvIq2GmzSRt/Zeo3rwK+C0KBFLYBPBkB7jtRbsFx95pt5
HbNJfXGoyRqc4aNX28dcCQ4781MkxpkekHS7ZhKkn2u8LAQRSRtGQ2SMZG5cnjBPTjp2tWB3OhF/
rH/QE/8AJtP8Kd2TZGHeLpuoXUtydUC726C2fgAYH6CspKLd2y1e2xuMunS6YbCO7g2bAikSAkHs
eCMnPPvV+7axOt7mLYCw027E8OpebIoYCMxNGHJHALHgDOOtRGyejKd30NwX2q/9Acf+BS/4Vd5d
iLLucs+/WNY84wb2lcHyt2MqB0z9B1rLmbkaWsjqft2q/wDQI/8AJla1vLsRZdzHW2sBrZcan+9N
zu8ryG+9v+7n68ZqXFc17ju7C6jZWNjry3cmom2csJfKETHIzz8wPfB/Oq0TErtFjW4rXUNRjt5N
Q8qSPCiLyS3zNjv78VMrN2uON0iPXLHTxdwia9FsY4VRE8pn+UE4OaU0trhFs0LyGBvDixvc7YfK
jHnbCeBjB29ef61btyiW5T8O29lBeuba989/KOV8krxkc5P+eaiCV9GOV7HSVsQcjrtnYvqkktxq
P2eRtp2fZ2bHygdR1rNpX1ZabsXmjubhNPghtt9rA8Mi3G8DeoA52nkdaGnpYWmp0FaEhQAUAFAB
QAUAcn46GTY88/vP/ZaiRUSz4IGNIlz/AM/B/wDQVpx2FI6B0WRCjqGVhggjIIqhHmWjN/xObLP/
AD3T/wBCFRYtndeJLsWujT8jdKPLUEHnPX9M1UnZErc4/SNPm1GRoYGRWVdx3kgdcdgfWsbczNL2
Rqr4W1FDlZrYMDkHc3B/75o9mxc6MrU7W4s7x4bggyHDZGcNnuM0NWeo07nWRaox8NteuwSVYiCe
vz9AcY7nB/GtOb3bkW1sZvg/zpLiVy48qOPbt9yeP5GoprUqZ1lbGZwu3/ip84H/AB+/+z1z3941
+yXvGcAWa2uQrEsDGT/CMcj8eT+VXNdSYlGxmk1XxFBNLtRncOdg4+UZ9f8AZpL3pDeiLPi8/wDE
0j9oB/6E1KpuENjXuIZLjwskcS7n+zxsFx1wAcD34q2rwsSnaRz2hajFYX4mlB8t0KMR/Dkg59+l
ZwfK9S5K6OqbWtNSLzTeRbcA4DZbn/Z6/pW/MjOzOL1K5Op6nJPDE2JWAROpPAA/HjpWTd2aLRHe
WULW9lBC5BaONUJHTIGK1SsjJlmmAUAFABQAUAFAGPr2hnWfI/0jyfJ3fwbs5x7j0pNXGnYl0PSz
pNo8Hn+ducvu27ccAY6n0oSsDdy+rq7MAQSpwwB6HGcH8CPzpiOXHgvy5RJDqDIVOU/d/MvpyGHP
vSsVzGrrmjtq6woLkwrGSSNu4MT07jpz+dDVxJ2HaJo66RDKok815GyXC7eB0GMn3/OklYG7mrVC
MjWNFXU5IXEoiZAQTsyWHbuOnP51Eo3KjKxXPh1m0/7Ebv5RKJQ3lcjgjHWpULK1x82ty/pGnLpl
oYVkMmXLFiMc9OB+Aq4xsrEt3NCqEYQ8O41P7Z9q/wCW3m7PL/2s4zmsvZ63uXzaWLetaYdVtEgE
3k7XD7tu7sRjqPWtGrkp2K2jaB/ZNy032nziyFMbNvcH1PpUqNncbdw1jQf7Uulm+0mLagTaEz3J
z196JQu7gpWNS1h+zWkMOd3loqbsYzgYzVJWRJkX/hm2upPMgb7MxwCqqCh/DjB6VMoJlKVjHPg7
UDkeba4/3m/+JpcjHzI29G8PQ6U7SM/nTHhXK42j2GTz7/5NJWJbNuqEFABQAUAYd7bNc6rMEs7O
4cW0YU3B4Q7pOg2nPv06UAV7W9u3a3iS7AUpEqCRgJJFKKS+zaxJ5bndgFeeAcgEjX18bZZ/LzKX
ZEiXOC6xOW4Byf3gK4ORhRj1oAIdQvUUyiaK7iUhPklDgswIA3hFAO4IO+N5J4xgAtWl3cqsrXxC
i0iCzFeQzjJZuBn7uxgAP4yOSOADMP2nTAJpVhs2vGQSyo4YhzJuPVcD5Wk5O4YUc8cgFkX5NwiS
ap5Vt+82XGYx5uBHjkrtOCzjgDp7GgBTqV7JaM8rR2zBo0JI2eWTEHbczbgvJwMqfTqcgAU6hO8G
4ypbOYYWdiSqqxLhlJIYJgrjJB9OuMACJf3z30SmRIsmMCB/kZ1KqWOzaW4JYZDYG3nocgEiX90w
sJGmj3TormJExu3HsDndgHnDDbjJyCBQBHr84jlQyhRHCqvtLBS+XG4pn+NVXAwc/vOCDjIBNrbu
8VjNbMXKz+anlnPmBY3baMf3gMfj3oApQ3btfz3RuHgt7nyz5jDHlRjzQpG4YAYqDyP4/XmgCw1z
e3VneRxysDHbs0TRr+8kO9wpB6cqg6DndkY4oAaNUkTZsvPPmZpF8gBGOxVcq4UYJLBVPXB3cYyM
ACxajK1sFlu41UT7WuEdWxGUJDbtoXlxsztx1HXmgCJ9VvHCmG4gCAN5Ts4HnkSOvQK2/hVJCbT8
3HUYANK7mit9Rt5p5EijEUqb3YKu4tGQMnvwfyNAFK2nubaC0iyU8qC2DRlfvF22MGzyMY4xjnrn
pQBVbUJprhbmG5Qy+QwaAgKbY+bGGycZGB3YEfKTjHFAFqK7v5VWOGaGZwksiMvz+Zt2YXdhV5Zi
CQOgxkHJoAbNql6sMsqKojZWuIGyDmJUPUYGMsEPriTHBGQALfXF5GXeOR90FxtKxg7ZD5AIBBzg
FiAAD/F/ewaAHWd7cmSKIXUE6STKnmK3m4Gx2YblVBn5R6kZyeooAt6XdyyvOJZfOCkEMqcDOcr0
BBGBlTkrkZY54ANOgAoAKACgAoAilhSVAjrkBlYDPdSCP1AoAGiVpklK/OilQc9iQT/6CKAJaACg
AoAKACgAoAKACgCsLeJrnz/nZwerOSq8YyFJwDjuB3PqaAJJohNH5bbwp7o5U/mCDQA2CNIIgiDg
dz1PqSe57570AT0AFABQAUAFABQAUAFAH//Z

------=_NextPart_001_006A_01BEAD01.F8DC1CE0--

------=_NextPart_000_0069_01BEAD01.F8DC1CE0
Content-Type: application/octet-stream;
	name="MU Application FORM.url"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="MU Application FORM.url"

[InternetShortcut]
URL=http://www.iami.org/nara/apply.html
Modified=40B9EBAC7EA7BE0174

------=_NextPart_000_0069_01BEAD01.F8DC1CE0
Content-Type: application/octet-stream;
	name="MU Homepage.url"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="MU Homepage.url"

[InternetShortcut]
URL=http://www.iami.org/nara.html
Modified=206A36A47EA7BE0148

------=_NextPart_000_0069_01BEAD01.F8DC1CE0--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA22718 for ietf-pkix-bks; Wed, 2 Jun 1999 12:43:27 -0700 (PDT)
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 MAA22714 for <[e-mail]>; Wed, 2 Jun 1999 12:43:26 -0700 (PDT)
Received: 	id PAB09360; Wed, 2 Jun 1999 15:36:25 -0400
Received: by gateway id <LMMMAAQV>; Wed, 2 Jun 1999 15:38:52 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Sarbari Gupta'" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Do we need to authenticate error status and nonce information in  TSA responses?
Date: Wed, 2 Jun 1999 15:38:51 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari;

> ----------
> From: 	Sarbari Gupta[SMTP:[e-mail]]
> Sent: 	Wednesday, June 02, 1999 12:42 PM
> To: 	'Robert Zuccherato'
> Cc: 	PKIX (E-mail)
> Subject: 	RE: Do we need to authenticate error status and nonce
> information in  TSA responses?
> 
> The OCSP case is absolutely relevant to this discussion. It also returns
> a signed token when successful and an (unsigned) error message when
> unsuccessful. The OCSP token is also long-lived exactly like the
> TSAToken. The OCSP document, just like the TSA document, is an Intenet
> Draft and is undergoing review.
> 
> As a group, PKIX should be able to justify design decisions it has made
> in various I-Ds that are currently being reviewed. Decisions made should
> be consistent for documents that are in parallel paths (at the very
> least). I don't see how or why OCSP should be treated differently with
> respect to error messages being signed or unsigned. The fundamental
> characteristics are identical! 
> 
No, they are not.  In OCSP the basic protocol does not link the request and
response.  This allows caching of responses.  Therefore, a signed error
message could be returned by an attacker in response to any request and thus
signed error messages are of no more value than unsigned error messages in
the OCSP case.  In this protocol, requests are always linked with responses,
and thus signed error messages are of value.  Since the underlying
assumptions and protocol characteristics are different, the OCSP case is not
relevant.  Could we now stick to discussing this protocol?

> > > If an attacker were changing the error type, what could
> > > the attacker gain from that action that they couldn't 
> > achieve by simply
> > > deleting the entire (signed or unsigned) error response?
> > > 
> > They could change "time not available for the next week" with 
> > "malformed
> > request" which would cause me to repeatedly try and fix my 
> > request for a
> > week.  Or, they could change "malformed request" with "time 
> > not available"
> > which may cause me not to get the document timestamped until 
> > next week.  
> 
> All of the above scenarios are examples of denial-of-service attacks,
> whereby the attacker is preventing the client from obtaining a valid
> TSAToken. 
> 
Yes, they are examples of denial-of-service attacks.  However, they are
preventable by using signed error messages.  Also, because of these kinds of
attacks, I cannot trust any unsigned error message and every unsigned error
message is indistinguishable from a "no response".  As I said earlier, when
you receive a "no response" you probably want to contact your server by some
other method to find out what is going on.  Do we really want to design a
protocol that forces users to contact the server every time an error is
produced?

> > Or,
> > they could change any error with "TSA XXX down, please try 
> > TSA YYY" where
> > TSA YYY is a competitor.  There are many possibilities.
> 
> This is not a valid example. The TSA client trusts the TSA for
> timestamping. A TSA is not supposed to offer referral services, and even
> if it does, the TSA client is under no obligation to use that referral
> unless it has reason to trust TSA YYY through a valid certificate chain.
> In that case, the referral is immaterial, the TSA client trusts TSA YYY
> anyway, and would probably have used TSA YYY if TSA XXX were not
> responding. 
> 
Of course, these are just three examples that came into my head as I was
writing the email.  I'm sure we could all think of other, similar attacks.

	Robert.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA22680 for ietf-pkix-bks; Wed, 2 Jun 1999 12:39:33 -0700 (PDT)
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 MAA22676 for <[e-mail]>; Wed, 2 Jun 1999 12:39:31 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <LSH85PVZ>; Wed, 2 Jun 1999 15:42:16 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F952@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Inclusion of a Status code within a TSAToken
Date: Wed, 2 Jun 1999 15:42:14 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > The status code is relevant only to the protocol between 
> the TSA client
> > and the TSA. The TSA Token, on the other hand, has a much longer
> > life-span and may be processed by many, many, other 
> entities. I would
> > strongly recommend that the status info not be included  
> the TSA Token.
> > 
> I would tend to disagree with this statement.  Remember that 
> these tokens
> will be used to support non-repudiation and may end up being used as
> evidence in some dispute resolution process.  Therefore, it does seem
> reasonable that some environments may require more than just 
> "the absence of
> an error code means that this is a valid timestamp".  They 
> may require a
> more explicit "this is a valid token" statement from the TSA. 
>  This is what
> the presence of a value 0 (granted) provides in the present 
> token structure.

I don't get it. Are you saying that a valid signed TSAToken does not in
itself constitute a valid timestamp? You need an additional field with
value zero (0) within the token indicating that it's a valid token? Why
is a TSA signing an invalid TSAToken in the first place? Are you
envisioning non-zero status within otherwise valid TSATokens? If so, you
are contradicting a previous statement you made:

>>If an error is
>>present, the response is an error message, not a valid token.  If no
error
>>is present, a status code indicating that a valid token was produced
does
>>appear within the token. 

However, I think I have made my case for excluding the Status info from
the TSAToken. If there is anyone else on this list who has strong
feelings on this issue, let them speak up. Otherwise, continue on with
the current protocol definitions. 

Best regards, 

- Sarbari


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA22533 for ietf-pkix-bks; Wed, 2 Jun 1999 12:20:17 -0700 (PDT)
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 MAA22527 for <[e-mail]>; Wed, 2 Jun 1999 12:20:16 -0700 (PDT)
Received: 	id PAA01755; Wed, 2 Jun 1999 15:18:44 -0400
Received: by gateway id <LMMMAAKY>; Wed, 2 Jun 1999 15:21:11 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Sarbari Gupta'" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Inclusion of a Status code within a TSAToken
Date: Wed, 2 Jun 1999 15:21:10 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari;

> ----------
> From: 	Sarbari Gupta[SMTP:[e-mail]]
> Sent: 	Wednesday, June 02, 1999 12:40 PM
> To: 	'Robert Zuccherato'
> Cc: 	PKIX (E-mail)
> Subject: 	Inclusion of a Status code within a TSAToken
>   
> The status code is relevant only to the protocol between the TSA client
> and the TSA. The TSA Token, on the other hand, has a much longer
> life-span and may be processed by many, many, other entities. I would
> strongly recommend that the status info not be included  the TSA Token.
> 
I would tend to disagree with this statement.  Remember that these tokens
will be used to support non-repudiation and may end up being used as
evidence in some dispute resolution process.  Therefore, it does seem
reasonable that some environments may require more than just "the absence of
an error code means that this is a valid timestamp".  They may require a
more explicit "this is a valid token" statement from the TSA.  This is what
the presence of a value 0 (granted) provides in the present token structure.

> > But this is so that we do not have 
> > to produce
> > responses that consist of a signed token inside of another 
> > signed object
> > which contains the error codes (assuming that the status codes must be
> > signed).  
> 
> This is not an adequate reason to justify a design decision. It just
> implies that we need to think about other possibilities. I had presented
> a proposal to achieve exactly this purpose in a previous note. In this
> proposal, the TSAToken does not contain status info, but the error
> messages were signed. Did you get a chance to review this proposal? 
> 
I must have missed it among the flood of emails I have been receiving on
this topic.

> I
> repeat it (modified slightly to not exclude the nonce from the TSAToken)
> here for your convenience.
> 
Thank you.

> [modified proposal from my 5/20/99 note]
> >>Define TSAResponse as the response from a TSA:
> >>
> >>TSAResponse ::= CHOICE {
> >>	errorInfo		SignedData,  
> >>	tokenInfo		TokenInformation}
> >>
> >>For an error information message (of type SignedData) the eContentType
> is defined as:
> >>id-ct-TSTerrorInfo	OBJECT IDENTIFIER	 ::= {id-ct 5}
> >>
> >>and the eContent shall be of the ASN.1 type TSTErrorInfo.
> >>
> >>TSTErrorInfo ::= SEQUENCE {
> >>	status 	PKIStatusInfo,
> >>	nonce 	Integer OPTIONAL}
> 
The problem is that within your error structure you only have the status and
nonce.  However, the TSA's policy information should also be included.  It
may be helpful to have the TSA's name (see discussion of this topic in
another thread).  For some error codes (e.g. tdaNotAvailable), the time
would probably be a useful field to include, depending on policy.  If a
nonce has not been used to link the request and response, then the
messageImprint field must be present to do so.  The tsaFreeData field would
probably be useful to some TSA's in the error response.  We probably also
want to include the version, in case the format changes.  This accounts for
all of the fields in the token except for tdaTokens and serialNumber, which
are OPTIONAL.  Therefore, even if we used your proposal, we would end up
with a structure that looked almost exactly like the present token.  Does it
really make sense to define a separate structure for an error response with
almost exactly the same fields as for a valid token?  I don't think so.

	Robert.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA22021 for ietf-pkix-bks; Wed, 2 Jun 1999 11:20:44 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22017 for <[e-mail]>; Wed, 2 Jun 1999 11:20:38 -0700 (PDT)
Received: from mcg.org.br (pm05-41.sac.verio.net [209.162.64.201]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id LAA23569; Wed, 2 Jun 1999 11:21:29 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 02 Jun 1999 11:12:07 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: Bob Blakley <[e-mail]>, Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: Every time ..., was Re: General formula
References: <D1A949D4508DD1119C8100400533BEDC107794@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan Lloyd wrote:

> Ed I  still do not know how anyone on this planet ...
> can predict the life time of a cert.

Every time you make a phone call, it gets through because
somebody on this planet was able to predict its duration.
And yet, how can anybody on this planet be able to
predict the lifetime (Lebendauer) of that connection?

The answer: By following very similar (though not
equal) arguments as the ones I used. So, there is
nothing magical about it.

I suggest you read my original posting here and its
inlined reference [1]. The full paper will hopefully
make it clearer also by examples.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21143 for ietf-pkix-bks; Wed, 2 Jun 1999 09:39:00 -0700 (PDT)
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 JAA21139 for <[e-mail]>; Wed, 2 Jun 1999 09:38:57 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <LSH85PR3>; Wed, 2 Jun 1999 12:42:05 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F94C@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Do we need to authenticate error status and nonce information in  TSA responses?
Date: Wed, 2 Jun 1999 12:42:03 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert,

> > How do other protocols such as OCSP handle
> > this issue?  
> > 
> Whether or not other drafts containing other protocols 
> decided to protect
> signed messages is not really relevant to whether or not this protocol
> should use signed or unsigned error messages.

The OCSP case is absolutely relevant to this discussion. It also returns
a signed token when successful and an (unsigned) error message when
unsuccessful. The OCSP token is also long-lived exactly like the
TSAToken. The OCSP document, just like the TSA document, is an Intenet
Draft and is undergoing review.

As a group, PKIX should be able to justify design decisions it has made
in various I-Ds that are currently being reviewed. Decisions made should
be consistent for documents that are in parallel paths (at the very
least). I don't see how or why OCSP should be treated differently with
respect to error messages being signed or unsigned. The fundamental
characteristics are identical! 


> > If an attacker were changing the error type, what could
> > the attacker gain from that action that they couldn't 
> achieve by simply
> > deleting the entire (signed or unsigned) error response?
> > 
> They could change "time not available for the next week" with 
> "malformed
> request" which would cause me to repeatedly try and fix my 
> request for a
> week.  Or, they could change "malformed request" with "time 
> not available"
> which may cause me not to get the document timestamped until 
> next week.  

All of the above scenarios are examples of denial-of-service attacks,
whereby the attacker is preventing the client from obtaining a valid
TSAToken. 

> Or,
> they could change any error with "TSA XXX down, please try 
> TSA YYY" where
> TSA YYY is a competitor.  There are many possibilities.

This is not a valid example. The TSA client trusts the TSA for
timestamping. A TSA is not supposed to offer referral services, and even
if it does, the TSA client is under no obligation to use that referral
unless it has reason to trust TSA YYY through a valid certificate chain.
In that case, the referral is immaterial, the TSA client trusts TSA YYY
anyway, and would probably have used TSA YYY if TSA XXX were not
responding. 

I will send you a separate note on the issue of removing the statuscode
from the TSA Token.

- Sarbari

> 
> 	Robert.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21118 for ietf-pkix-bks; Wed, 2 Jun 1999 09:37:30 -0700 (PDT)
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 JAA21114 for <[e-mail]>; Wed, 2 Jun 1999 09:37:28 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <LSH85PRN>; Wed, 2 Jun 1999 12:40:12 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F94B@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: Inclusion of a Status code within a TSAToken
Date: Wed, 2 Jun 1999 12:40:09 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert, 

> > Looking at the problem from another angle, the TSA protocol needs to
> > change in some way to get the status info out of the TSA 
> token. I have
> > seldom seen a design where error codes get packaged into long-term
> > objects - this problem needs to be fixed whether or not the error
> > response gets signed or not. 
> > 
> Error codes are not packaged with long-term objects.  If an error is
> present, the response is an error message, not a valid token. 
>  If no error
> is present, a status code indicating that a valid token was 
> produced does
> appear within the token.  

The status code is relevant only to the protocol between the TSA client
and the TSA. The TSA Token, on the other hand, has a much longer
life-span and may be processed by many, many, other entities. I would
strongly recommend that the status info not be included  the TSA Token.


> But this is so that we do not have 
> to produce
> responses that consist of a signed token inside of another 
> signed object
> which contains the error codes (assuming that the status codes must be
> signed).  

This is not an adequate reason to justify a design decision. It just
implies that we need to think about other possibilities. I had presented
a proposal to achieve exactly this purpose in a previous note. In this
proposal, the TSAToken does not contain status info, but the error
messages were signed. Did you get a chance to review this proposal? I
repeat it (modified slightly to not exclude the nonce from the TSAToken)
here for your convenience.

[modified proposal from my 5/20/99 note]
>>Define TSAResponse as the response from a TSA:
>>
>>TSAResponse ::= CHOICE {
>>	errorInfo		SignedData,  
>>	tokenInfo		TokenInformation}
>>
>>For an error information message (of type SignedData) the eContentType
is defined as:
>>id-ct-TSTerrorInfo	OBJECT IDENTIFIER	 ::= {id-ct 5}
>>
>>and the eContent shall be of the ASN.1 type TSTErrorInfo.
>>
>>TSTErrorInfo ::= SEQUENCE {
>>	status 	PKIStatusInfo,
>>	nonce 	Integer OPTIONAL}
>>
>>TokenInformation is an unsigned data structure as follows.
>>
>>TokenInformation ::= SEQUENCE {
>>	status	PKIStatusInfo,
>>	token 	SignedData }

> Until I see a convincing reason why they should be 
> contained in a
> separate layer, I think we should leave things as they are and keep
> everything simple.

I think I have already presented a convincing reason for why the status
info should be excluded from the TSA token. You need to be able to
justify the presence of every single field in a long-term and broadly
distributed object. The status info field just does not cut the mark.

- Sarbari

> 
> 	Robert.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA20845 for ietf-pkix-bks; Wed, 2 Jun 1999 09:13:28 -0700 (PDT)
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 JAA20841 for <[e-mail]>; Wed, 2 Jun 1999 09:13:27 -0700 (PDT)
Received: from [128.33.238.73] (TC073.BBN.COM [128.33.238.73]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA00680; Wed, 2 Jun 1999 12:14:39 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a06b37b072ac3e9@[128.33.238.93]>
In-Reply-To: <[e-mail]>
References: <v04020a0bb379c4cb94d8@[128.89.0.110]> <[e-mail]>
Date: Wed, 2 Jun 1999 12:07:10 -0400
To: Stefan Santesson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: How do software products handle policy qualifiers?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

I don't think it is appropriate to cast the question in terms of a "typical
client.'  Most clients today do not process policies, much less policies
with qualifiers.  But, those clients also are not representative of the
sort of sophisticated applications that we are talking about.

steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA20839 for ietf-pkix-bks; Wed, 2 Jun 1999 09:13:14 -0700 (PDT)
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 JAA20835 for <[e-mail]>; Wed, 2 Jun 1999 09:13:13 -0700 (PDT)
Received: from [128.33.238.73] (TC073.BBN.COM [128.33.238.73]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA00632; Wed, 2 Jun 1999 12:14:24 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a00b37b01837009@[128.33.238.93]>
In-Reply-To: <007901beac79$207c4d30$[e-mail]>
References: <v04020a0bb379c4cb94d8@[128.89.0.110]>
Date: Wed, 2 Jun 1999 11:45:49 -0400
To: "Peter Williams" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: X.509 ACs vs. SPKI?
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

I am not familiar with the other examples you cite, but for RFC 1422, I
know that the author considered the hash lookup to be the best thing
available at the time, absent a ubiquitous directory mechanism.  Also, in
hindsight, while we do have some examples of PKI structures that look a lot
like the one proposed in 1422, that aspect of 1422 didn't pan out, and it
is clear that it would have had scaling problems over time.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA19320 for ietf-pkix-bks; Wed, 2 Jun 1999 07:17:24 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA19316 for <[e-mail]>; Wed, 2 Jun 1999 07:17:20 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id QAA28153 for <[e-mail]>; Wed, 2 Jun 1999 16:18:33 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 02 Jun 1999 16:18:40 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: How do software products handle policy qualifiers?
In-Reply-To: <v04020a0bb379c4cb94d8@[128.89.0.110]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA19317
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

We have had a long discussion about how to include support for "reliance
limit" in Qualified Certificates.

My understanding is that this should be handled by a policy qualifier and a
qualifier could easily be defined using an existing ISO defined ASN.1
structure for monetary value.

But before deciding this we have to understand how the installed base of
software react if they encounter a policy OID with a qualifier. Will they
just ignore the qualifier if they are set up to accept the policy but don't
understand the qualifier, or will they reject the certificate.

And what is the situation if the policy extension is set to critical.

X.509 defines the policy qualifier as an extension of the policy. i.e. the
policy defines the use and meaning of the qualifier. No criticality bit
change that fact.

So my understanding is that if a policy is defined as accepted, then that
includes any qualifier value  unless it's explicitly defined that some
qualifier values are not accepted.

Is this also how it works out there in practical implementations????

Any comment on this is highly welcomed.

/Stefan
 
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA18744 for ietf-pkix-bks; Wed, 2 Jun 1999 06:36:33 -0700 (PDT)
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 GAA18738 for <[e-mail]>; Wed, 2 Jun 1999 06:36:32 -0700 (PDT)
Received: 	id JAA29620; Wed, 2 Jun 1999 09:33:47 -0400
Received: by gateway id <LMML0832>; Wed, 2 Jun 1999 09:36:15 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Do we need to authenticate error status and nonce information in  TSA responses?
Date: Wed, 2 Jun 1999 09:36:14 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter;

How about if I add something like the following to Section 3.4:
"Upon receiving a valid request, the server must respond with either a valid
response with content type application/timestamp or with an HTTP error."

	Robert.

> ----------
> From: 	Peter Sylvester[SMTP:[e-mail]]
> Sent: 	Wednesday, June 02, 1999 3:01 AM
> To: 	[e-mail]
> Cc: 	[e-mail]
> Subject: 	RE: Do we need to authenticate error status and nonce
> information in  TSA responses?
> 
> I have asked the question about how to react using http as a transport
> in the case where the TSA cannot produce a signed response.
> 
> I would like to see how an http server should react (just drop
> the http session, the tcp connection, keep it alive forever, or
> create an http error.)
> 
> 
> > 
> > Therefore, in the absence of a good reason to allow unsigned error
> messages,
> > I am opposed to them.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA08302 for ietf-pkix-bks; Wed, 2 Jun 1999 00:13:09 -0700 (PDT)
Received: from selva.dit.upm.es (selva-gw.dit.upm.es [138.4.2.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA08298 for <[e-mail]>; Wed, 2 Jun 1999 00:13:02 -0700 (PDT)
Received: from dit.upm.es (toro-3.dit.upm.es [138.4.21.3]) by selva.dit.upm.es (8.9.1a/8.9.1) with ESMTP id JAA15155; Wed, 2 Jun 1999 09:13:43 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Wed, 02 Jun 1999 07:56:36 +0200
From: "Jose A. Manas" <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: The purpose of time stamping
References: <[e-mail]><[e-mail]> <v04020a0fb37336bc9254@[128.89.0.110]> <03d501bea898$dd96b750$930aff0c@brick> <[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 AAA08299
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas wrote:

> 2° We are defining a Time Stamping Protocol that can be used in many dfferent
> contexts. We do not claim that it is usable in all the contexts. 

Sure you cannot, but nevertheless I think it is interesting to try
to cover as many scenarios as possible, or to be as general as feasible.

However,

> We have made a
> few *simple* extensions that were beyond the original goal, in particular to be
> able to answer to the simple question "What time is it ?" when the requester has
> no local time available. 

I don't see the point of using a TS protocol for any purpose that
excludes stamping. There are excellent protocols for finding out the
time
if you are on-line (e.g. NTP). An the point sounds very strange if your
were using the TSP off-line (e.g. batch time-stamping, e-mail exchanges,
etc).

> The primary need is only to prove that a digital
> signature was created before a given date. That digital signature may be any
> signature; e.g. from a user; from a CA for a user certificate,
> cross-certificate, CRL, ARL; from an Attribute Authority for an Attribute
> Certificate ... As there are too many examples of use, only a few are mentioned
> in the annex.

But when the protocol is restricted to signing a hash, the only thing
you
can directly prove is that the hash value exists when the time is
stamped.
I may infer that the hash value was generated before, as far as the
hash algorithm is not forgeable.
That sounds fine for building proofs of possesion of documents.

But with respect to signatures,
I find it strange that you carry along 2 tokens (e.g. the CRL itself and
its
detached time-stamp). If I were the user of the certificates, I'd ask
for a reliable time of issuance in the same pack.
In electronic commerce exchanges, I want the committments singed and
time-stamped, to be preferred in a single token.

> 3° The protocol is sufficient for our current needs. Thus I do not see the need
> to extend the terms of reference of our charter to cover more.

Shall I understand that if other business needs are identified for
time-stamping, a new protocol is needed?
I think it is a pity that standards are too focused towards current
needs.

> Regards,
> 
> Denis
> (co-author of the current draft)

pepe
[just thinking aloud]


-- --------------------------------------------------------
Prof. Jose A. Manas                     <[e-mail]>
Dpt. Telematica                 http://www.dit.upm.es/~pepe
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA07925 for ietf-pkix-bks; Wed, 2 Jun 1999 00:05:32 -0700 (PDT)
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA07863 for <[e-mail]>; Wed, 2 Jun 1999 00:04:17 -0700 (PDT)
From: [e-mail]
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id JAA65232 for <[e-mail]>; Wed, 2 Jun 1999 09:04:01 +0200
Received: from d12mta02.de.ibm.com (d12mta01 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.7m1/NCO v1.8) with SMTP id JAA22612 for <[e-mail]>; Wed, 2 Jun 1999 09:04:23 +0200
Received: by d12mta02.de.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id C1256784.0026D9CF ; Wed, 2 Jun 1999 09:04:21 +0200
X-Lotus-FromDomain: IBMIL@IBMDE
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 2 Jun 1999 10:03:59 +0300
Subject: Assigning Roles to Strangers
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

---------------------- Forwarded by Yosi Mass/Haifa/IBM on 06/02/99 09:55
AM ---------------------------


[e-mail] on 06/02/99 09:04:42 AM

To:   [e-mail], [e-mail], [e-mail]
cc:
Subject:  Assigning Roles to Strangers







We are investigating the use of public key certificates, either x509, SPKI
or other, to establish trust among two `strangers` (parties without a prior
long term relationship). We will appreciate any feedback, and are looking
forward to serious parties interested in pilot deployments. Please see our
site http://www.hrl.il.ibm.com/TrustEstablishment, and in particular the
paper: Access Control Meets Public Key Infrastructure, Or: Assigning Roles
to Strangers

Best Regards,
Amir Herzberg
Manager, E-Business and Security Technologies
IBM Research - Haifa Lab (Tel Aviv Office)
http://www.hrl.il.ibm.com
New e-mail: [e-mail]
New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA07824 for ietf-pkix-bks; Wed, 2 Jun 1999 00:00:48 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA07820 for <[e-mail]>; Wed, 2 Jun 1999 00:00:46 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id JAA07267; Wed, 2 Jun 1999 09:01:57 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 2 Jun 1999 09:01:57 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id JAA10139; Wed, 2 Jun 1999 09:01:56 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id JAA26285; Wed, 2 Jun 1999 09:01:56 +0200
Date: Wed, 2 Jun 1999 09:01:56 +0200
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: Do we need to authenticate error status and nonce information in  TSA responses?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have asked the question about how to react using http as a transport
in the case where the TSA cannot produce a signed response.

I would like to see how an http server should react (just drop
the http session, the tcp connection, keep it alive forever, or
create an http error.)


> 
> Therefore, in the absence of a good reason to allow unsigned error messages,
> I am opposed to them.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA07359 for ietf-pkix-bks; Tue, 1 Jun 1999 23:43:23 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA07355 for <[e-mail]>; Tue, 1 Jun 1999 23:43:19 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <MCLY4D78>; Wed, 2 Jun 1999 16:44:31 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC107794@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>
Cc: Bob Blakley <[e-mail]>, Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: RE: General formula
Date: Wed, 2 Jun 1999 16:44:31 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed I  still do not know how anyone on this planet - even if they
understand this Newton stuff - can predict the life time of a cert.

	snip the cosmic stuff :-)

> Likewise, when I say that "the lifetime of a certificate is inversely
> proportional to the number of its attributes" do I care what the
> application is? What are these attributes representing? About the
> authentication points of the subject, the management of the
> certificate,
> the validation policy environment for the certificate or some data
> that
> the Issuer is providing integrity over? Is it a question of
> application and
> use? NO -- I just care that the *same* situation is used when you vary
> the number of attributes.
> 
> Thus, for the *same* situation (Bible or ticket to Hell), the lifetime
> of a
> certificate will decrease to half if you double the number of
> attributes,
> to one-third if you triple, etc. In other words, it is inversely
> *proportional*.
> If it was 20 years for N attributes, it will be 10 years for 2N
> attributes;
> if it was 20 seconds for N attributes, it will be 10 seconds for 2N
> attributes;
> etc.
> 
	So if I put in certificate a lot more attributes that represent
colours and go from 256 to 1024  makes the certificate not last as long?
	It seems pointless to debate the lifetime of a certificate with
such exactness when its the attribute value, use and context that will
affect its lifetime - and no factual information is provided about this.

	ie I could add another attribute called "Additional Validity
Periods" a Multi valued extension with the summer months for 20 years
put in them.. Here is a clear case of piles of attributes being added
and extending the life of a certficate - not shortening it  - this
feature could even be implied with Policy Ids..

	Oh well :-)

	regards alan

> Of course, this is valid if all the attributes have similar values --
> otherwise,
> just apply the full equation:
> 
> 1/T = 1/T1 + 1/T2 +....1/TN
> 
> But, the usefulness of my comentary does not depend on its
> (inexisting)
> exactness for Ti <> Tj, but because it provides a correct designer
> feeling
> for the decrease of certificate lifetime with the number of attributes
> --
> double the number of attributes and certificate lifetime will likely
> decrease
> to about half of what it was. Not to about one-quarter, or one-tenth.
> 
> Cheers,
> 
> Ed Gerck
> ______________________________________________________________________
> Dr.rer.nat. E. Gerck                                 [e-mail]
>   ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA04131 for ietf-pkix-bks; Tue, 1 Jun 1999 23:16:50 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA04127 for <[e-mail]>; Tue, 1 Jun 1999 23:16:49 -0700 (PDT)
Received: from mcg.org.br (pm03-46.sac.verio.net [209.162.64.112]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id XAA09644; Tue, 1 Jun 1999 23:17:29 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 01 Jun 1999 23:07:38 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: Bob Blakley <[e-mail]>, Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: Re: General formula
References: <D1A949D4508DD1119C8100400533BEDC107792@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan Lloyd wrote:

> I still do not understand how anyone on this planet can predict this
> without the real application.

see below.

> > And, one of the predictions of the equation I derived is that "the
> > lifetime of a certificate is inversely proportional to the number of
> > its attributes".
> >
>         However, if the certificate has a validity period of 20 seconds
> - then it wont last long anyway. And if the certificate attributes are
> in fact all the paragraphs and pages of the bible that are digitally
> captured - at a certain time and the validy is set to 20 years then this
> certificate is a lot bigger and lasts a lot longer than the first case.

So, you conclude that the predicition is wrong because
20 seconds << 20 years? Well, aren't you just trying to compare
apples with speedboats? See, the prediction says "proportional"
-- so, you must compare like things.

Let me exemplify. The force of gravity is inversely proportional to the
square of the distance between two masses. So, if you take two masses
and they are atracted by a gravity force of 20 Newtons at distance X
and you take two other masses that are attracted by a gravity force of
20,000 Newtons even though they have a much larger distance of
1,000*X between  them -- what can you say? Was Newton wrong?
No, the masses are different.

Likewise, when I say that "the lifetime of a certificate is inversely
proportional to the number of its attributes" do I care what the
application is? What are these attributes representing? About the
authentication points of the subject, the management of the certificate,
the validation policy environment for the certificate or some data that
the Issuer is providing integrity over? Is it a question of application and
use? NO -- I just care that the *same* situation is used when you vary
the number of attributes.

Thus, for the *same* situation (Bible or ticket to Hell), the lifetime of a
certificate will decrease to half if you double the number of attributes,
to one-third if you triple, etc. In other words, it is inversely *proportional*.
If it was 20 years for N attributes, it will be 10 years for 2N attributes;
if it was 20 seconds for N attributes, it will be 10 seconds for 2N attributes;
etc.

Of course, this is valid if all the attributes have similar values -- otherwise,
just apply the full equation:

1/T = 1/T1 + 1/T2 +....1/TN

But, the usefulness of my comentary does not depend on its (inexisting)
exactness for Ti <> Tj, but because it provides a correct designer feeling
for the decrease of certificate lifetime with the number of attributes --
double the number of attributes and certificate lifetime will likely decrease
to about half of what it was. Not to about one-quarter, or one-tenth.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA29736 for ietf-pkix-bks; Tue, 1 Jun 1999 22:10:41 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA29703 for <[e-mail]>; Tue, 1 Jun 1999 22:10:37 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <MCLY4D7D>; Wed, 2 Jun 1999 15:11:39 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC107792@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>, Bob Blakley <[e-mail]>
Cc: Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: RE: General formula
Date: Wed, 2 Jun 1999 15:11:38 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I still do not understand how anyone on this planet can predict this
without the real application. 

	snip.

> I never [yet ;-)] said that the equation I derived is "universal".
> But,
> that it is based on assumptions which are generally valid for PKIX
> certificates. In fact, I know no counter-examples.
> 
> And, one of the predictions of the equation I derived is that "the
> lifetime of a certificate is inversely proportional to the number of
> its attributes".
> 
	However, if the certificate has a validity period of 20 seconds
- then it wont last long anyway. And if the certificate attributes are
in fact all the paragraphs and pages of the bible that are digitally
captured - at a certain time and the validy is set to 20 years then this
certificate is a lot bigger and lasts a lot longer than the first case.

	What are these attributes representing? The authentication
points of the subject, the management of the certificate, the validation
policy environment for the certficate or some data that the Issuer is
providing integrity over. Its not a question of quantity - its a
question of application and use.


	regards alan

> Which means "good news" when compared with what was
> previously believed (though without proof) and which you first
> questioned on the list -- providing both a reason and an excuse
> for my posting with that equation. As I wrote last week,  my
> posting was  excerpted from a paper which I expect to be
> ready from review this week. I hope the paper will provide
> (at the expense of reading time) for a more comprehensive
> context.
> 
> Cheers,
> 
> Ed Gerck
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA17342 for ietf-pkix-bks; Tue, 1 Jun 1999 20:26:39 -0700 (PDT)
Received: from I1.pilgrim.com (i1.pilgrim.com [206.3.211.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA17331 for <[e-mail]>; Tue, 1 Jun 1999 20:26:38 -0700 (PDT)
Received: from BONK.pilgrim.com (bonk [206.3.211.31]) by I1.pilgrim.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id XAA13190 for <[e-mail]>; Tue, 1 Jun 1999 23:28:37 -0400
Date: Tue, 1 Jun 1999 23:28:37 -0400
Message-Id: <[e-mail]>
From: Christopher Stacy <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Russ Housley on Tue, 01 Jun 1999 13:22:22 -0400)
Subject: Re: X.509 ACs vs. SPKI?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> On Tue, 01 Jun 1999 13:22:22 -0400, Russ Housley ("Russ") writes:
 Russ> There are a few real needs for encrypted attributes.

Certainly in a military security context, there is a need for such secret
authorizations: classification compartment identifiers are themselves classified. 
(I don't know if anyone is actually planning to use certificate attributes in
such a direct mapping, but it would be very natural in a multi-mode environment.)



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA15692 for ietf-pkix-bks; Tue, 1 Jun 1999 20:10:11 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA15688 for <[e-mail]>; Tue, 1 Jun 1999 20:10:09 -0700 (PDT)
Received: from mcg.org.br (pm03-46.sac.verio.net [209.162.64.112]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id UAA08314; Tue, 1 Jun 1999 20:11:15 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 01 Jun 1999 20:01:50 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Blakley <[e-mail]>
CC: Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: Re: General formula
References: <026d01bea7be$a0166680$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob Blakley wrote:

> Ed,
>
> >Wait -- this is NOT the issue here. Bob Blakley wrote that equal lifetimes
> >would indicate a "property" -- that the corresponding attributes would
> >actually be dependent or at least have a tendency to be dependent. I replied
> >negatively -- such property or tendency does NOT exist. Lifetime distance
> >does not correlate with attribute independency -- much in the same way that
> >a pointer's value (lifetime) does not correlate with a pointer's address
> >(attribute).
> >They are two entirely different concepts, not only different values. Thus,
> >the fact that the lifetimes are equal or even similar for two attributes does not
> >authorize me to say anything about the attributes' dependencies.
>
> This may be the source of our apparent disagreement -- I say apparent because
> it does not now and has not yet appeared to me that we actually disagree
> on anything of substance.

Yes, I believe we are in substantial agreement  -- but certainly not on this
subject. And, IMO, this is a simple confusion which is hiding the forest --
but, only because of some trees so, let me help chop them down.

> I did NOT write that equal lifetimes indicate a property.  What I *did* write
> is that there are many real-world cases where there is *either* exact equivalence of
> lifetimes because of dependence, or dependence without exact equivalence
> of lifetimes.  I gave an example of the former.

IMO, the problem is a simple confusion. You said in your former e-mail
that you are using the word "lifetime" to designate the origin of a period in
time, but such use is not warranted as I extensively commented and
exemplified in my e-mail right before this reply. The lifetime of an object
designates "the duration of the existence of the object" -- "attribute lifetime",
"star lifetime", "certificate lifetime", "battery lifetime".  All, the same concept.
In Engineering and Physics, it is usually a stochastic variable that represents
the expected duration of an object's existence -- quite in accordance with
the linguistic use.

So, there are NO "real-world cases where there is *either* "exact equivalence
of lifetimes because of dependence", or "dependence without exact equivalence
of lifetimes", as you wrote above.  Your example does not apply. As I wrote
above, "Lifetime distance does not correlate with attribute independency" --
so "lifetime equivalence" (ie, equivalent values) has nothing to do with "lifetime
dependence". The numerical values of a set of lifetimes CANNOT be used
to infer anything about their dependencies, or lack of.

> I noted that your formula does not *and is not intended* to cover these cases
> if you treat the dependent attributes as separate and plug their lifetimes into
> the formula as if they were independent.

The equation I derived neither makes nor depends on such assumptions. The
equation does not depend on the attributes being independent. Please see
my example in reply to Tony -- the one where he used his own name to
exemplify strong dependency.

> In this sense, the formula is not "general" in the sense that gravitation is
> "universal".

I never [yet ;-)] said that the equation I derived is "universal". But,
that it is based on assumptions which are generally valid for PKIX
certificates. In fact, I know no counter-examples.

And, one of the predictions of the equation I derived is that "the
lifetime of a certificate is inversely proportional to the number of
its attributes".

Which means "good news" when compared with what was
previously believed (though without proof) and which you first
questioned on the list -- providing both a reason and an excuse
for my posting with that equation. As I wrote last week,  my
posting was  excerpted from a paper which I expect to be
ready from review this week. I hope the paper will provide
(at the expense of reading time) for a more comprehensive
context.

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA07057 for ietf-pkix-bks; Tue, 1 Jun 1999 19:21:29 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA07051 for <[e-mail]>; Tue, 1 Jun 1999 19:21:28 -0700 (PDT)
Received: from mcg.org.br (pm03-46.sac.verio.net [209.162.64.112]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id TAA29004; Tue, 1 Jun 1999 19:22:30 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 01 Jun 1999 19:13:05 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Blakley <[e-mail]>
CC: Graham Klyne <[e-mail]>, PKIX <[e-mail]>
Subject: Linguistics, was Re: General formula, was Re: Attribute certificate  lifetimes:way too much  math, but getting closer to correct
References: <028001bea7bf$eec606e0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob Blakley wrote:

> Ed,
>
> Here's the other source of apparent disagreement: you're using the word
> "lifetime" in a way I consider unnatural, and it may strike others oddly also:
>
> >> >I disagree. And, there are billions of counter-examples. For example,
> >> >if men's biological lifetime is 70 years this does not mean that all men
> >> >were born at the same time -- and yet they all have the same lifetime.
>
> The word normally used in English to capture this concept is lifeSPAN, not
> lifeTIME. "The span of a man's years is threescore and ten", etc....

Now, we may have gone full circle! ;-)

No, in the above and before I used the noun "lifetime" in the exact standard
English and technical usage that you can find in Engineering, Physics, etc.
As Webster says for its *first* meaning, as a noun:

lifetime (noun): the duration of the existence of a living being or a thing
                       (as a star or a subatomic particle).

Of course, "lifetime" as a "duration of existence" is primarily a statistical
concept -- since there is no certainty about the value it denotes, which
lies in the future. So, when I said that men's biological lifetime (as a noun)
is 70 years this indeed does not mean that all men were born at the same
time -- and yet they all have the same [expected] lifetime (as a noun).

Quite different, however, is to use "lifetime" as an adjective, for which
Webster also quotes:

lifetime (adjective):  measured or achieved over the span of a career
                               <a baseball player's lifetime batting average>

So, if I mention my lifetime struggle to make meaning clearer this has
nothing to do with the lifetime of my struggles to make meaning
clearer ;-)

Thus, when I speak of "attribute lifetime", "radiative lifetime", "biological
lifetime", "certificate lifetime", "star lifetime", "particle lifetime"  I am
certainly referring to the duration of the existence of that object. In very
precise and usual linguistic terms -- using the noun "lifetime".

I am sorry to beat this issue to death (and, to further stomp it next) but
I hope this will clear one of  (perhaps, the only one) item I feel we were
in disagreement -- but, which spawned a series of other disagreements,
including your contention about the application domain of the equation I
derived, which I again assert to be quite general and to make no
assumption whatosever of attribute independency.

> If I'm lucky, I will have the same lifespan (102 years) as my
> great-grandmother, but it's already too late for us to have the same lifetime.

No, you may have the same "duration of the existence" as her -- in other
words and according to standard English, you may have the same lifetime
as her. Here, "lifetime" is a noun. In fact, you can calculate the probability
that you will have the same lifetime as her, within a confidence level -- where
"lifetime" is still a noun and still means "duration of the existence".

However, if you want to use "lifetime" as an adjective then you *need*
to use it as a modifier of a noun -- for example, to denote a quality of
the thing named. Then, you may say that it is already too late for you
to have the same lifetime radio listening experience as your grandmother.
Of course, since you may not expect to have the same lifetime (noun)
as her and you are already into perhaps 50% of your lifetime (noun).
In fact, with so little radio listening experience so far and so few
opportunities ahead (the Internet does not count ;-) )  I say that your
lifetime (adjective) radio listening experience will almost certainly be
less than hers -- though (and I sure hope so) your lifetime (noun)
may the same or even longer than hers ;-) but, such prognosis neither
of us know with certainty since your lifetime (noun) is an stochastic
variable.

>  In the course of her
> lifetime,

(as a noun)

> Soviet communism rose and fell, there were two world wars, the United States
> was electrified, private automobiles came into use, refrigeration and then
> air-conditioning became common, homes got telephones, radio and then
> television became popular, and so on.
>
> These usages are completely natural, but using lifetime to designate the
> length of the interval but NOT (also) its origin is not common.

Lifetime NEVER designates its origin. It may designate:

1. (noun) the duration of the existence of an object, as star lifetime,
particle lifetime, attribute lifetime, certificate lifetime, etc. In Physics
and Engineering, it is usually used to denote a non-deterministic
variable which may be treated by statistical methods -- since there
is no certainty about the value it denotes, which lies in the future.

2. (noun) an amount accumulated or experienced in a lifetime,  as
a lifetime of regrets. In this case, "lifetime" is udes to refer to a
past acquires a deterministic value, as "Alice could not walk in her
entire lifetime of 85 years".

3. (adjective) lifelong, lasting or continuing through life. As
"John's lifetime struggle to make meaning clearer".

4. (adjective)  measured or achieved over the span of a career, as
a baseball player's lifetime batting average.

So, we see that, linguistically, "lifetime" either designates a *duration* of
time or what is collected or effected in it-- NEVER, however, the origin
of it.

I think the problem here is thus a simple confusion.  Justifiedly, I
used "lifetime" as in (1) above, following standard linguistic and
technical usage.

German is even clearer in this aspect, since one uses the word
"Lebensdauer" for "lifetime" in the sense of (1) -- which is, literally,
"the duration of life", but uses "Lebenszeit" for "lifetime" in the sense
of (2) -- which is , literally, "the time of life". However, neither
meaning the origin of the time period.

Thus, in German, we speak of " Lebensdauer" and, of course,
of "Batterie-Lebensdauer" or "Zertifikat-Lebensdauer",  meaning
the expected "duration of battery life" or "duration of certificate life".
In English, likewise, battery lifetime or certificate lifetime.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA26727 for ietf-pkix-bks; Tue, 1 Jun 1999 16:45:09 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26723 for <[e-mail]>; Tue, 1 Jun 1999 16:45:08 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id QAA05333; Tue, 1 Jun 1999 16:44:49 -0700 (PDT)
Received: from peternt (static-3-26.engineering.valicert.com [192.168.3.26] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id QAA27133; Tue, 1 Jun 1999 16:45:47 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Aram Perez" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: X.509 ACs vs. SPKI?
Date: Tue, 1 Jun 1999 16:53:04 -0500
Message-ID: <007901beac79$207c4d30$[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 V5.00.2314.1300
Importance: Normal
In-Reply-To: <v04020a0bb379c4cb94d8@[128.89.0.110]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I saw Moshe's message, and it does not address this issue I
> raised.  Local;
> searching for a cert based on a hash is fine, but searching for someone's
> cert in a large, distributed database environment is different, and not so
> easily supported.  I have a private message from someone
> suggesting that it
> is not so hard as I suggest, but I'll have to think about the proposal
> before I am convinced that it is feasible.  Even if feasible, it
> may not be
> especially attractive, vs. use of structured names as search keys.
>
> Steve
>
>

As I remember, RFC 1422, authored by one Steve Kent, used a hash-
based list mechanism to perform a DN membership test, as used by a (small
number of) authorities who were required to perform a distributed,
security-critical, uniqueness test.

There is also a hash-based http-proxying specification making
its way through the IETF - a version allows for distributed/segmented
http page caching.  Its deployed world-wide in Netscape and Microsoft
products - so its seems to work, in practice, world-wide, in
interoperable fashion, and largely documented by IETF.

http://search.ietf.org/internet-drafts/draft-melve-clientcache-com-00.txt

Another approach is to use URL caching, where the URL
value is composed of the URL-encoded hash value of the
entire cert.

http://search.ietf.org/internet-drafts/draft-lovric-icp-ext-01.txt

The ICP technique now works in combination with
PKIX ftp://ftp.isi.edu/in-notes/rfc2585.txt as part of
the id field.


Id say, PKIX related hash-based distributed searching for
certs is already a reality. It comes free with the
already deployed (ssl-ised) web infrastructure. RFC 2585 nicely
profiles the web to suit PKIX cert discovery/searching/caching.

   "This specification is part of a multi-part standard for the Internet
   Public Key Infrastructure (PKI) using X.509 certificates and
   certificate revocation lists (CRLs).  This document specifies the
   conventions for using the File Transfer Protocol (FTP) and the
   Hypertext Transfer Protocol (HTTP) to obtain certificates and CRLs
   from PKI repositories.  Additional mechanisms addressing PKI
   repository access are specified in separate documents."

Profiling CARP (see melve) and RFC 2585 means today one
can use http to not only access certificates from
a PKI repository, but that repository can be highly
distributed - where the resource (cert) id is a hash.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA26319 for ietf-pkix-bks; Tue, 1 Jun 1999 16:30:32 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26315 for <[e-mail]>; Tue, 1 Jun 1999 16:30:31 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (swf-caw1.spyrus.com [207.212.34.211]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id QAA01463; Tue, 1 Jun 1999 16:27:43 -0700 (PDT)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 01 Jun 1999 13:22:22 -0400
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: Stephen Farrell <[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
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

I disagree.  There are a few real needs for encrypted attributes.  When a
user is granted certain authorizations, even briefly, they may become a
prime target.  I would hate for plaintext authorizations to flag these
particular users.

Encryption of these attributes is not the whole solution, but it is an
important aspect of the solution.  If one AA issues all of these highly
valuable authorizations, then the AA must also issue other less valuable
(and encrypted) authorizations.  Otherwise, any recipient of an AC from
that AA becomes a target.

In summary:  encryption is necessary but not sufficient.

Russ


At 12:40 PM 5/28/99 +0200, Denis Pinkas wrote:
>Stephen,
>
>I don't want to get into deep discussion here but ...
>
>> Aram,
>>
>> > Does either path offer the ability to grant a permission without revealing
>> > the identity of who is being granted the permission? I was talking with 
>some
>> > folks yesterday who want to implement a very large PKI system used to 
>access
>> > control but they have legal requirements in certain cases to keep the
>> > identity of the user private.
>>
>> Can't recall for spki, but the ACs I-D does have support
>> for encrypted attributes,
>
>I would not recommend to support encrypted attributes even if the ISO 
>document and
>the current draft allow for it. It is an extra level of complexity and we 
>can live
>without it for the moment (and maybe for ever).
>
>
>> but this is more a case
>> of concealing the permissions, rather than the identity
>> which is presumably visible in a public key cert anyway.
>
>Pseudonyms can be used in a public key certificate and thus the name of the 
>signer
>maybe be reasonably cancelled.
>
>Regards,
>
>Denis
>
>>
>> Regards,
>> Stephen.
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA25422 for ietf-pkix-bks; Tue, 1 Jun 1999 16:05:57 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA25418 for <[e-mail]>; Tue, 1 Jun 1999 16:05:56 -0700 (PDT)
Received: from mcg.org.br (pm04-15.sac.verio.net [209.162.64.128]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id QAA17014; Tue, 1 Jun 1999 16:06:57 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 01 Jun 1999 15:57:28 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>, PKIX <[e-mail]>
Subject: identifying and indexing certs, was Re: X.509 ACs ...
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>
> "Aram Perez" <[e-mail]> on 05/28/99 01:12:30 PM
>
> To:   [e-mail], [e-mail]
> Subject:  Re: X.509 ACs vs. SPKI?
>
> This also begs the question "Why the hash and not just the IssuerSerial?" It
> might be my misunderstanding of X.509, but I was under the
> impression/assumption that the Issuer and Serial Number uniquely identified
> an X.509 certificate.
>

Aram:

If you are willing to restrict yourself to X.509 certs and: (1) trust the issuer
to always use unambiguous SNs; (2) trust the issuer name to be unambiguous;
(3) trust the issuer name to be correct and authoritative; etc. -- fine. Otherwise,
since these previous items are not under my control and I may receive certs
that are not X.509 issued, I prefer to consider that a cert is equal to another
iff their cryptographic hashes are equal.

Of course, *afterwards* (and I guess this answers Steve's concerns about
easy of indexing) I can perfectly well use the cert's Issuer and Serial Number
for indexing purposes or any other non-X.509 index it may have.

However, for security reasons, I may wish to self-sign that cert first -- in
other to prove to myself at a later time that I indeed approved that cert
into my trusted basis. At the same time, I can designate a trust level to
that cert -- so that, later on, my software can automatically use that cert within
my pre-defined reliance limits. And, of course, I will also at the same time
assign a lifetime to my signature -- so that my software can later on also
decide when my assigned trust on that cert needs to be renewed. And yet,
all this can still be reliably indexed by the original cert's Serial Number and
Issuer name.

Thus, exactly because of my distrust on (1), (2), (3), etc. above, I am
able to actually improve my trust on certificate uniqueness -- while not
losing and also improving my trust on the indexing benefits of its Serial
Number in a hierarchical tree. And, at the same time, providing for
interoperation with other standards or special needs even in X.509.

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22266 for ietf-pkix-bks; Tue, 1 Jun 1999 14:46:29 -0700 (PDT)
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 OAA22262 for <[e-mail]>; Tue, 1 Jun 1999 14:46:27 -0700 (PDT)
Received: 	id RAA06432; Tue, 1 Jun 1999 17:43:14 -0400
Received: by gateway id <LMML06CA>; Tue, 1 Jun 1999 17:45:41 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Sarbari Gupta'" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Do we need to authenticate error status and nonce information in  TSA responses?
Date: Tue, 1 Jun 1999 17:45:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari;

> ----------
> From: 	Sarbari Gupta[SMTP:[e-mail]]
> Sent: 	Tuesday, June 01, 1999 3:24 PM
> To: 	'Robert Zuccherato'; 'Denis Pinkas'
> Cc: 	PKIX (E-mail)
> Subject: 	RE: Do we need to authenticate error status and nonce
> information in  TSA responses?
> 
> You cite David Kurn's note as a justification for signed error messages
> - however, the argument does not sound very convincing to me. Why does
> an unsigned error leave the "verifier" unable to act? 
> 
Because it has no way of determining who that unsigned error message came
from.

> [BTW, what
> verifier are we talking about? I believe the entity receiving the error
> message is the TSA client.] 
> 
Yes, the "verifier" here is the verifier of the signed error message, or the
requester of the time stamp token.

> How do other protocols such as OCSP handle
> this issue?  
> 
Whether or not other drafts containing other protocols decided to protect
signed messages is not really relevant to whether or not this protocol
should use signed or unsigned error messages.

> We must be careful to distinguish between an "unsigned result" and an
> "unsigned error result". I agree that an unsigned SUCCESSFUL result is
> meaningless. However, in the case of the TSA protocols, I would still
> claim that an unsigned ERROR result need not be signed. 
> 
> In order to determine whether a signed error response is necessary or
> overkill, we need to consider the type of attacks that are possible in
> either case. The statement "an unsigned result leaves the verifier
> unable to act" is somewhat vague. What would the "verifier" do if the
> attacker deleted the signed error response - would the "verifier" now be
> able to act? 
> 
If the verifier knew that the TSA would always respond with a signed error
message when it could and it didn't receive one, then one of two possible
things happened.  Either the server is completely down, or the response was
deleted somehow in transit.  In either situation, the verifier would
probably want to contact the server in some other method to find out what is
going on and resolve the situation.

> Conversely, why can't the recipient act on an unsigned
> error message? 
> 
Because, if I get an error message saying "request not properly formed" then
I have no reason to trust it.  That message could just as easily have been
returned by any attacker.  Since I should not trust that message, I am
reduced to the same situation as above.  I should contact the server through
some other method to find out what is really going on.

> If an attacker were changing the error type, what could
> the attacker gain from that action that they couldn't achieve by simply
> deleting the entire (signed or unsigned) error response?
> 
They could change "time not available for the next week" with "malformed
request" which would cause me to repeatedly try and fix my request for a
week.  Or, they could change "malformed request" with "time not available"
which may cause me not to get the document timestamped until next week.  Or,
they could change any error with "TSA XXX down, please try TSA YYY" where
TSA YYY is a competitor.  There are many possibilities.

> The bottom line is that the only attack possible on an unsigned error
> message is denial-of-service. 
> 
No, they can cause the person requesting the service to change their actions
based on the contents of the error message.

> However, the same attack is also possible
> on a signed error message. So, I would agree with Denis that an unsigned
> error response is adequate in this protocol.
> 
> Looking at the problem from another angle, the TSA protocol needs to
> change in some way to get the status info out of the TSA token. I have
> seldom seen a design where error codes get packaged into long-term
> objects - this problem needs to be fixed whether or not the error
> response gets signed or not. 
> 
Error codes are not packaged with long-term objects.  If an error is
present, the response is an error message, not a valid token.  If no error
is present, a status code indicating that a valid token was produced does
appear within the token.  But this is so that we do not have to produce
responses that consist of a signed token inside of another signed object
which contains the error codes (assuming that the status codes must be
signed).  Until I see a convincing reason why they should be contained in a
separate layer, I think we should leave things as they are and keep
everything simple.

	Robert.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19985 for ietf-pkix-bks; Tue, 1 Jun 1999 13:07:03 -0700 (PDT)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19977 for <[e-mail]>; Tue, 1 Jun 1999 13:07:00 -0700 (PDT)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA29784; Tue, 1 Jun 1999 16:08:07 -0400
Received: from erols.com ([9.14.4.66]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA25118; Tue, 1 Jun 1999 16:08:07 -0400
Message-ID: <[e-mail]>
Date: Tue, 01 Jun 1999 16:07:06 -0400
From: Shabnam Erfani <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sarbari Gupta <[e-mail]>
CC: "'Robert Zuccherato'" <[e-mail]>, "PKIX (E-mail)" <[e-mail]>
Subject: Re: Do we need to authenticate error status and nonce informationin  TSA  responses?
References: <51BF55C30B4FD1118B4900207812701E38F948@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari,
	We should differentiate between denial of service attacks vs. integrity
attacks. In case of denial of service, the attacker simply deletes the
error message. In this case the client will timeout and probably retry,
so an action is taken. Anyway, a denial of service attack can go on
forever, and there is not much that we can do about it. The attacker can
also delete a SUCCESSFUL result, or the request itself.

In case of integrity attacks, it still is beneficial for the receiver to
detect them. First, some error codes may be handled by clients. For
example, if one TSA is not available, the client can decide to use a
backup, or just wait and resend the request later. A corrupted message
can send the client to another TSA for sure. Another point is that the
error information may be logged and used for auditing in the system, and
if corruption is detected, this information can be used to detect
possible intrusion attempts in the system if the pattern persists. For
auditing purposes we need accurate information, and signed error message
help build the assurance needed for auditing.

Regards,

Shabnam

Sarbari Gupta wrote:
> 
> > As David Kurn said
> > (in his May 20
> > message to the list), "A signed result lets the verifier
> > conclude something
> > and act upon it.  An unsigned result leaves the verifier
> > unable to act."
> 
> Robert,
> 
> You cite David Kurn's note as a justification for signed error messages
> - however, the argument does not sound very convincing to me. Why does
> an unsigned error leave the "verifier" unable to act? [BTW, what
> verifier are we talking about? I believe the entity receiving the error
> message is the TSA client.] How do other protocols such as OCSP handle
> this issue?
> 
> We must be careful to distinguish between an "unsigned result" and an
> "unsigned error result". I agree that an unsigned SUCCESSFUL result is
> meaningless. However, in the case of the TSA protocols, I would still
> claim that an unsigned ERROR result need not be signed.
> 
> In order to determine whether a signed error response is necessary or
> overkill, we need to consider the type of attacks that are possible in
> either case. The statement "an unsigned result leaves the verifier
> unable to act" is somewhat vague. What would the "verifier" do if the
> attacker deleted the signed error response - would the "verifier" now be
> able to act? Conversely, why can't the recipient act on an unsigned
> error message? If an attacker were changing the error type, what could
> the attacker gain from that action that they couldn't achieve by simply
> deleting the entire (signed or unsigned) error response?
> 
> The bottom line is that the only attack possible on an unsigned error
> message is denial-of-service. However, the same attack is also possible
> on a signed error message. So, I would agree with Denis that an unsigned
> error response is adequate in this protocol.
> 
> Looking at the problem from another angle, the TSA protocol needs to
> change in some way to get the status info out of the TSA token. I have
> seldom seen a design where error codes get packaged into long-term
> objects - this problem needs to be fixed whether or not the error
> response gets signed or not.
> 
> - Sarbari
> =================================
> Sarbari Gupta
> CygnaCom Solutions
> [phone] (voice)
> [phone](FAX)
> [e-mail]
> =================================
> 
> > -----Original Message-----
> > From: Robert Zuccherato [mailto:[e-mail]]
> > Sent: Tuesday, June 01, 1999 2:39 PM
> > To: Sarbari Gupta; 'Denis Pinkas'
> > Cc: PKIX (E-mail)
> > Subject: RE: Do we need to authenticate error status and nonce
> > information in TSA responses?
> >
> >
> > Denis;
> >
> > > ----------
> > > From:       Denis Pinkas[SMTP:[e-mail]]
> > > Sent:       Tuesday, June 01, 1999 7:03 AM
> > > To:         Sarbari Gupta
> > > Cc:         Robert Zuccherato (E-mail); PKIX (E-mail)
> > > Subject:    Re: Do we need to authenticate error status and nonce
> > > information in  TSA responses?
> > >
> > > You proposed the following:
> > >
> > > TSAResponse ::= SEQUENCE {
> > >         status  PKIStatusInfo,
> > >         nonce   Integer OPTIONAL,
> > >         timeStampToken  SignedData }
> > >
> > > I strongly support the separation of the PKIStatusIngfo
> > from the TST.
> > > There
> > > are other supporters for this (e.g. Michael Zolotarev).
> > >
> > As I have stated previously on this list, there is a good
> > reason for not
> > having unsigned error messages.  You cannot trust an unsigned
> > error message,
> > but you can trust a signed error message.  As David Kurn said
> > (in his May 20
> > message to the list), "A signed result lets the verifier
> > conclude something
> > and act upon it.  An unsigned result leaves the verifier
> > unable to act."
> >
> > Therefore, in the absence of a good reason to allow unsigned
> > error messages,
> > I am opposed to them.
> >
> >       Robert.
> >
> >
> >
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18859 for ietf-pkix-bks; Tue, 1 Jun 1999 12:39:37 -0700 (PDT)
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 MAA18855 for <[e-mail]>; Tue, 1 Jun 1999 12:39:35 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <LSH85PC8>; Tue, 1 Jun 1999 15:42:11 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F949@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "Robert Zuccherato (E-mail)" <[e-mail]>, "PKIX (E-mail)" <[e-mail]>
Subject: RE: Do we need to authenticate error status and nonce information in 	TSA responses?
Date: Tue, 1 Jun 1999 15:42:08 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

I recognize your point with respect to the nonce needing to be signed
when the messageImprint included in the TSAToken is either absent or
non-unique. Basically, in those cases, you are using the "nonce" as a
reference/identifier to enable the pairing between the TSA request and
response. I guess in my mind the term "nonce" came with associated
connotations that imply some kind of transient information. However, I
think in the usage model you illustrated, the nonce is not really
transient info - it may be the ONLY way to establish the association
between a request and a response. 

Perhaps the "nonce" field can be renamed to "requestIdentifier" or
something similar? This renaming may help to avoid the misinterpretation
that the nonce field is transient info that is non-essential to the
verification and usage of the TSAToken.

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Tuesday, June 01, 1999 7:03 AM
> To: Sarbari Gupta
> Cc: Robert Zuccherato (E-mail); PKIX (E-mail)
> Subject: Re: Do we need to authenticate error status and nonce
> information in TSA responses?
> 
> 
> Sarbari,
> 
> There has ben an avalanche of messages from you on May the 20 
> th and since
> then I have had no time to reply and apparently Robert has not replied
> either.
> 
> You proposed the following:
> 
> TSAResponse ::= SEQUENCE {
>         status  PKIStatusInfo,
>         nonce   Integer OPTIONAL,
>         timeStampToken  SignedData }
> 
> I strongly support the separation of the PKIStatusIngfo from 
> the TST. There
> are other supporters for this (e.g. Michael Zolotarev).
> 
> The nonce CANNOT be outside the TST for security reasons. 
> When the client
> has no local time refrence, it picks a nonce at random and 
> sends it. The
> fact that the same nonce is sent back and that the response 
> is within its
> allowed time frame  (replay is only possible within that time 
> window) allows
> to make sure of the timeliness of the response. If the nonce 
> were outside
> the signed structure then it could be substituted then no 
> guarantee about
> timeliness could be given. The hash cannot be used as a 
> substitute for the
> nonce for two reasons:
> 
> 1) a requester could have the need to time-stamp the same 
> information (hence
> the same hash) at two different instants of time, and thus a 
> replay would be
> possible in that situation.
> 
> 2) the hash is now optional, if someone simply wants to get 
> the time back.
> 
> I thought these explanations were pretty obvious. Apparently, 
> there are
> not.   :-)
> 
> I thus propose something along the following
> 
> TSAResponse ::= SEQUENCE {
>         status  PKIStatusInfo,
>         timeStampToken  SignedData }
> 
> Regards,
> 
> Denis
> 
> 
> > Robert,
> >
> > I have been thinking some more about the actual need to 
> authenticate the
> > error messages that come back from the TSA. The conclusion 
> I came to,
> > is, that it buys us very little or nothing. Information is 
> only worth
> > securing if there is a way for someone to profit from it when the
> > information is not secured. So, Denis' proposal for unsigned error
> > returns seems adequate.
> >
> > Let's think about it from the point of view of an attacker. 
> What happens
> > if we don't sign an error message from the TSA? An attacker can
> > substitute the actual error code with a different error 
> code and make
> > the TSA client think that their request failed for a 
> different reason.
> > The only gain for the attacker is thus denial-of-service 
> against the TSA
> > client. Now consider the opposite scenario where signed 
> error messages
> > are sent out by the TSA. Even in this case, the attacker can mount a
> > denial-of-service attack by simply deleting the signed 
> error message and
> > not letting the TSA client receive it.
> >
> > My feeling is that the only item that a TSA can return that 
> requires to
> > be authenticated is a time stamp token (TST), which, of 
> course, needs to
> > be signed.
> >
> > I would claim that the protocols in the timestamp I-D can 
> be simplified
> > by using the SignedData structure to hold the TST (without 
> status and
> > nonce) while the status and nonce are passed back 
> (unsigned). Thus, the
> > response from a TSA can be defined as a TSAResponse structure as
> > follows.
> >
> > TSAResponse ::= SEQUENCE {
> >         status  PKIStatusInfo,
> >         nonce   Integer OPTIONAL,
> >         timeStampToken  SignedData }
> >
> > In spite of the above, if someone wants to add 
> authentication to the TSA
> > response, they can make use of a secure transport mechanism.
> >
> > Comments? Thoughts?
> >
> > - Sarbari
> >
> > =================================
> > Sarbari Gupta
> > CygnaCom Solutions
> > [phone] (voice)
> > [phone](FAX)
> > [e-mail]
> > =================================
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18474 for ietf-pkix-bks; Tue, 1 Jun 1999 12:21:56 -0700 (PDT)
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 MAA18470 for <[e-mail]>; Tue, 1 Jun 1999 12:21:54 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <LSH85PC2>; Tue, 1 Jun 1999 15:24:26 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F948@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Do we need to authenticate error status and nonce information in  TSA responses?
Date: Tue, 1 Jun 1999 15:24:23 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> As David Kurn said 
> (in his May 20
> message to the list), "A signed result lets the verifier 
> conclude something
> and act upon it.  An unsigned result leaves the verifier 
> unable to act."  

Robert, 

You cite David Kurn's note as a justification for signed error messages
- however, the argument does not sound very convincing to me. Why does
an unsigned error leave the "verifier" unable to act? [BTW, what
verifier are we talking about? I believe the entity receiving the error
message is the TSA client.] How do other protocols such as OCSP handle
this issue?  

We must be careful to distinguish between an "unsigned result" and an
"unsigned error result". I agree that an unsigned SUCCESSFUL result is
meaningless. However, in the case of the TSA protocols, I would still
claim that an unsigned ERROR result need not be signed. 

In order to determine whether a signed error response is necessary or
overkill, we need to consider the type of attacks that are possible in
either case. The statement "an unsigned result leaves the verifier
unable to act" is somewhat vague. What would the "verifier" do if the
attacker deleted the signed error response - would the "verifier" now be
able to act? Conversely, why can't the recipient act on an unsigned
error message? If an attacker were changing the error type, what could
the attacker gain from that action that they couldn't achieve by simply
deleting the entire (signed or unsigned) error response?

The bottom line is that the only attack possible on an unsigned error
message is denial-of-service. However, the same attack is also possible
on a signed error message. So, I would agree with Denis that an unsigned
error response is adequate in this protocol.

Looking at the problem from another angle, the TSA protocol needs to
change in some way to get the status info out of the TSA token. I have
seldom seen a design where error codes get packaged into long-term
objects - this problem needs to be fixed whether or not the error
response gets signed or not. 

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================

> -----Original Message-----
> From: Robert Zuccherato [mailto:[e-mail]]
> Sent: Tuesday, June 01, 1999 2:39 PM
> To: Sarbari Gupta; 'Denis Pinkas'
> Cc: PKIX (E-mail)
> Subject: RE: Do we need to authenticate error status and nonce
> information in TSA responses?
> 
> 
> Denis;
> 
> > ----------
> > From: 	Denis Pinkas[SMTP:[e-mail]]
> > Sent: 	Tuesday, June 01, 1999 7:03 AM
> > To: 	Sarbari Gupta
> > Cc: 	Robert Zuccherato (E-mail); PKIX (E-mail)
> > Subject: 	Re: Do we need to authenticate error status and nonce
> > information in  TSA responses?
> > 
> > You proposed the following:
> > 
> > TSAResponse ::= SEQUENCE {
> >         status  PKIStatusInfo,
> >         nonce   Integer OPTIONAL,
> >         timeStampToken  SignedData }
> > 
> > I strongly support the separation of the PKIStatusIngfo 
> from the TST.
> > There
> > are other supporters for this (e.g. Michael Zolotarev).
> > 
> As I have stated previously on this list, there is a good 
> reason for not
> having unsigned error messages.  You cannot trust an unsigned 
> error message,
> but you can trust a signed error message.  As David Kurn said 
> (in his May 20
> message to the list), "A signed result lets the verifier 
> conclude something
> and act upon it.  An unsigned result leaves the verifier 
> unable to act."  
> 
> Therefore, in the absence of a good reason to allow unsigned 
> error messages,
> I am opposed to them.
> 
> 	Robert.
> 
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA17072 for ietf-pkix-bks; Tue, 1 Jun 1999 11:38:08 -0700 (PDT)
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 LAA17067 for <[e-mail]>; Tue, 1 Jun 1999 11:38:07 -0700 (PDT)
Received: 	id OAA11461; Tue, 1 Jun 1999 14:36:11 -0400
Received: by gateway id <LMML0ZVJ>; Tue, 1 Jun 1999 14:38:38 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: Sarbari Gupta <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Do we need to authenticate error status and nonce information in  TSA responses?
Date: Tue, 1 Jun 1999 14:38:37 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis;

> ----------
> From: 	Denis Pinkas[SMTP:[e-mail]]
> Sent: 	Tuesday, June 01, 1999 7:03 AM
> To: 	Sarbari Gupta
> Cc: 	Robert Zuccherato (E-mail); PKIX (E-mail)
> Subject: 	Re: Do we need to authenticate error status and nonce
> information in  TSA responses?
> 
> You proposed the following:
> 
> TSAResponse ::= SEQUENCE {
>         status  PKIStatusInfo,
>         nonce   Integer OPTIONAL,
>         timeStampToken  SignedData }
> 
> I strongly support the separation of the PKIStatusIngfo from the TST.
> There
> are other supporters for this (e.g. Michael Zolotarev).
> 
As I have stated previously on this list, there is a good reason for not
having unsigned error messages.  You cannot trust an unsigned error message,
but you can trust a signed error message.  As David Kurn said (in his May 20
message to the list), "A signed result lets the verifier conclude something
and act upon it.  An unsigned result leaves the verifier unable to act."  

Therefore, in the absence of a good reason to allow unsigned error messages,
I am opposed to them.

	Robert.






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA14606 for ietf-pkix-bks; Tue, 1 Jun 1999 10:18:26 -0700 (PDT)
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 KAA14602 for <[e-mail]>; Tue, 1 Jun 1999 10:18:25 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA15083; Tue, 1 Jun 1999 13:19:34 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0bb379c4cb94d8@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Tue, 1 Jun 1999 13:20:55 -0400
To: "Aram Perez" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aram,

>Its been a while since I read "the larger context in S/MIME". I'm just
>basing my comments on what Denis Pinkas wrote. He stated "there is the
>following structure which unambigously references an certificate" and then
>provided the ASN.1 definition of ESSCertID. This is the context that I'm
>making my contents: how to identify a certificate.

I may have misspoken here, if I interpret Russ's message correctly.
Generally we try to ensure that our protocols are algorithm independent,
but it may be that S/MIME was not so careful in this case.  Nonetheless,
that one exception does not detract from the general theme of algorithm
independence.

>>
>>>>  Clearly it has been important in the
>>>> encryption algorithm arena, where independence is making it possible to
>>>> transition from DES to 3DES or AES, or whatever.  Similar arguments apply
>>>> to hash algorithms as well.
>>>
>>>Believe me, I'm a strong believer is algorithm independence but only where
>>>it makes sense. And in the case of using the hash to identify a certificate
>>>I don't believe it makes sense. I agree with the current definition of
>>>ESSCertID. My objection was to Denis Pinkas comment about allowing more hash
>>>algorithms to be used as the identifier of a certificate.
>>
>> I would find it most convenient to use the same hash here as the one used
>> in signing the cert, since that hash alg is, by definition, one that both
>> the CA and any relying party must implement.  But, since we don't mandate
>> any single algorithm for that purpose, why do so for this hash?
>>
>
>I disagree that "we don't mandate any single algorithm" (and I'm assuming
>'we' refers to IETF). S/MIME Version 3 Message Specification
>(draft-ietf-smime-msg-06.txt) states in Section 2.1: "Sending and receiving
>agents MUST support SHA-1."

Again, I apologize for not being clear enough.  We do sometimes mandate a
set of MUST implement algorithms as defaults for interoperability, but we
try not to  design protocols to depend on these.  IPsec and SSL and S/MIME
do this. PKIX has not yet gone so far as to mandate specific algorithms,
hence my comment should hav been that "in the context we are discussing,
PKIX standards, we have not chosen to go this route so far."

>>>>
>>>> Finally, an Issuer name and serial number SHOULD uniquely identify a cert,
>>>> but in reality there is insufficient control over Issuer names to
>>>>guarantee
>>>> uniqueness.  Use of the hash as a backpointer is more secure, though by
>>>> itself a hash is not a great way to ID a cert, due to searching
>>>> limitations, as discussed previously.
>>>
>>>You seem to agree that there will be "searching limitations" by having
>>>algorithm independence. So why should PKIX impose these "searching
>>>limitations" if there is no security risk/extra cost/Y10K/etc issue with
>>>having one hash algorithm used to help identify a certificate?
>>
>> No, the seacrching problem I refer to is due to the use of ANY hash as
>>an ID.
>
>I'm confused by what you mean the the searching problem. I didn't get a
>chance to finish this response on Friday and today I read Moshe Letvin's
>posting on the uses for unique certficate ID. I think he very clearly
>summarizes what I see as a problem when searching for a certificate.

I saw Moshe's message, and it does not address this issue I raised.  Local;
searching for a cert based on a hash is fine, but searching for someone's
cert in a large, distributed database environment is different, and not so
easily supported.  I have a private message from someone suggesting that it
is not so hard as I suggest, but I'll have to think about the proposal
before I am convinced that it is feasible.  Even if feasible, it may not be
especially attractive, vs. use of structured names as search keys.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13479 for ietf-pkix-bks; Tue, 1 Jun 1999 09:50:44 -0700 (PDT)
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 JAA13475 for <[e-mail]>; Tue, 1 Jun 1999 09:50:44 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id JAA37672 for <[e-mail]>; Tue, 1 Jun 1999 09:51:56 -0700
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (mailgate2.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 01 Jun 1999 09:51:50 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id JAA30944; Tue, 1 Jun 1999 09:51:49 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 01 Jun 1999 09:51:48 -0700
Subject: Re: X.509 ACs vs. SPKI?
From: "Aram Perez" <[e-mail]>
To: [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
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Steve,

>>> I see the structure that raised your concern, and we'll clearly have to do
>>> something in our context to ensure that the ambiguity does not persist.  (I
>>> assume that this was not an issue in the context where the structure was
>>> used initially, due to the hash alg being identified elsewhere.)
>>>
>>> We relly love algorithm independence here in the IETF, so I will not try to
>>> spend time on the list justifying it.
>>
>>If I'm not mistaken, the definition for ESSCertID came from *IETF's S/MIME*
>>effort, so is appears that someone else at IETF does not "love algorithm
>>independence".
>
> Have you looked at the larger context in S/MIME where it is used?  if not,
> then this statement seems premature.

Its been a while since I read "the larger context in S/MIME". I'm just
basing my comments on what Denis Pinkas wrote. He stated "there is the
following structure which unambigously references an certificate" and then
provided the ASN.1 definition of ESSCertID. This is the context that I'm
making my contents: how to identify a certificate.

>
>>>  Clearly it has been important in the
>>> encryption algorithm arena, where independence is making it possible to
>>> transition from DES to 3DES or AES, or whatever.  Similar arguments apply
>>> to hash algorithms as well.
>>
>>Believe me, I'm a strong believer is algorithm independence but only where
>>it makes sense. And in the case of using the hash to identify a certificate
>>I don't believe it makes sense. I agree with the current definition of
>>ESSCertID. My objection was to Denis Pinkas comment about allowing more hash
>>algorithms to be used as the identifier of a certificate.
>
> I would find it most convenient to use the same hash here as the one used
> in signing the cert, since that hash alg is, by definition, one that both
> the CA and any relying party must implement.  But, since we don't mandate
> any single algorithm for that purpose, why do so for this hash?
>

I disagree that "we don't mandate any single algorithm" (and I'm assuming
'we' refers to IETF). S/MIME Version 3 Message Specification
(draft-ietf-smime-msg-06.txt) states in Section 2.1: "Sending and receiving
agents MUST support SHA-1."

>>>
>>> Finally, an Issuer name and serial number SHOULD uniquely identify a cert,
>>> but in reality there is insufficient control over Issuer names to guarantee
>>> uniqueness.  Use of the hash as a backpointer is more secure, though by
>>> itself a hash is not a great way to ID a cert, due to searching
>>> limitations, as discussed previously.
>>
>>You seem to agree that there will be "searching limitations" by having
>>algorithm independence. So why should PKIX impose these "searching
>>limitations" if there is no security risk/extra cost/Y10K/etc issue with
>>having one hash algorithm used to help identify a certificate?
>
> No, the seacrching problem I refer to is due to the use of ANY hash as an ID.

I'm confused by what you mean the the searching problem. I didn't get a
chance to finish this response on Friday and today I read Moshe Letvin's
posting on the uses for unique certficate ID. I think he very clearly
summarizes what I see as a problem when searching for a certificate.

Regards,
Aram


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA08442 for ietf-pkix-bks; Tue, 1 Jun 1999 07:34:19 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA08438 for <[e-mail]>; Tue, 1 Jun 1999 07:34:17 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA25036 for <[e-mail]>; Tue, 1 Jun 1999 10:35:27 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA25028 for <[e-mail]>; Tue, 1 Jun 1999 10:35:27 -0400 (EDT)
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 KAA28608 for <[e-mail]>; Tue, 1 Jun 1999 10:35:30 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (avenger53.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 01 Jun 1999 10:33:14 -0400
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <LX8NS6NB>; Tue, 1 Jun 1999 10:34:07 -0400
Message-Id: <[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: "'IETF'" <[e-mail]>
Subject: RE: X.509 ACs vs. SPKI?
Date: Tue, 1 Jun 1999 10:34:06 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BEAC3B.CD5AA8D2"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEAC3B.CD5AA8D2
Content-Type: text/plain

Steve:

Thanks for the response!

I think the security concern you mention, that CAs might assert names in
authentication certificates that overlap with names independently asserted
by Attribute Authorities in Attribute Certificates is also a concern for
implementations of access control lists (I think your response more or less
acknowledges this).  It seems to me that the situation of many separate
organizations independently building access control lists is very similar to
that of many Attribute Authorities independently issuing attribute
certificates.  I think it would be difficult to find a vulnerability
associated with the use of distinguished names to link subscribers to
attribute certificates that would not also apply to the use of distinguished
names to link subscribers with access control list entries.

I am concerned that managing attribute certificates bound to specific keys
or certificates may be difficult in large, distributed systems.  After all,
one of the reasons for separating authorizations from authentication
certificates is that the authorization managers may be different from the
identity managers.  If one is not careful, one could find that every time an
authentication certificate is renewed or rekeyed, the subscriber's attribute
certificates all become invalid all at once.  Binding attribute certificates
to specific certificates or public keys requires a management interaction
between Certification Authorities and Attribute Authorities that may be
difficult to establish and maintain.

So I hope the IETF does not come down too hard against using names to link
authentication certificates and attribute certificates.

Dave

> ----------
> From: 	Stephen Kent[SMTP:[e-mail]]
> Sent: 	Thursday, May 27, 1999 11:34 AM
> To: 	Fillingham,  David W.
> Cc: 	[e-mail]
> Subject: 	RE: X.509 ACs vs. SPKI?
> 
> Dave,
> 
> Good point.  One really needs to check the name from an identity cert in
> context, e.g., after making sure that the whole cert chain is acceptable
> for the context in question.  if we made more use of nameConstraints, this
> would be easier to manage and less error/attack prone.  I suspect that
> part
> of the alarm cited here arises from a concern that imeplementations of
> access controllers will fail to impose the necessary constrain checks and
> thus will open up new avenues of attack.  For example, say you receive an
> attribute cert and identity cert from a user. The module for identity cert
> validation is invoked and it returns OK, because the user in question is
> authorized to do something in your system.  However, the attribute cert
> was
> really bound to another user with the same subject name, due to inadeqaute
> controls over name spaces, or due to malicious behavior on the part of a
> CA
> in some other administrative domain.  The result might be a granting of
> inappropriate access to the user.  While it is true that the same thing
> could happen based solely upon subject name mismanagement, the
> opportunities for these sorts of errors may be even greater when we add
> the
> additional complexity of processing ACs.  I won't claim that this is an
> airtight argument, but I think it captures the flavor of the concerns that
> motivate soem fo the discussion you are seeing on the list.
> 
> Steve
> 

------_=_NextPart_001_01BEAC3B.CD5AA8D2
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: X.509 ACs vs. SPKI?</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Steve:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Thanks for the =
response!</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I think the security =
concern you mention, that CAs might assert names in authentication =
certificates that overlap with names independently asserted by =
Attribute Authorities in Attribute Certificates is also a concern for =
implementations of access control lists (I think your response more or =
less acknowledges this).&nbsp; It seems to me that the situation of =
many separate organizations independently building access control lists =
is very similar to that of many Attribute Authorities independently =
issuing attribute certificates.&nbsp; I think it would be difficult to =
find a vulnerability associated with the use of distinguished names to =
link subscribers to attribute certificates that would not also apply to =
the use of distinguished names to link subscribers with access control =
list entries.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I am concerned that =
managing attribute certificates bound to specific keys or certificates =
may be difficult in large, distributed systems.&nbsp; After all, one of =
the reasons for separating authorizations from authentication =
certificates is that the authorization managers may be different from =
the identity managers.&nbsp; If one is not careful, one could find that =
every time an authentication certificate is renewed or rekeyed, the =
subscriber's attribute certificates all become invalid all at =
once.&nbsp; Binding attribute certificates to specific certificates or =
public keys requires a management interaction between Certification =
Authorities and Attribute Authorities that may be difficult to =
establish and maintain.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">So I hope the IETF =
does not come down too hard against using names to link authentication =
certificates and attribute certificates.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D1 FACE=3D"MS Sans Serif">Stephen =
Kent[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D1 FACE=3D"MS Sans Serif">Thursday, May 27, 1999 11:34 =
AM</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans =
Serif">Fillingham,&nbsp; David W.</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans =
Serif">RE: X.509 ACs vs. SPKI?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Dave,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Good point.&nbsp; One really needs to =
check the name from an identity cert in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">context, e.g., after making sure that =
the whole cert chain is acceptable</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for the context in question.&nbsp; if =
we made more use of nameConstraints, this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">would be easier to manage and less =
error/attack prone.&nbsp; I suspect that part</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of the alarm cited here arises from a =
concern that imeplementations of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">access controllers will fail to =
impose the necessary constrain checks and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">thus will open up new avenues of =
attack.&nbsp; For example, say you receive an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">attribute cert and identity cert from =
a user. The module for identity cert</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">validation is invoked and it returns =
OK, because the user in question is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">authorized to do something in your =
system.&nbsp; However, the attribute cert was</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">really bound to another user with the =
same subject name, due to inadeqaute</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">controls over name spaces, or due to =
malicious behavior on the part of a CA</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in some other administrative =
domain.&nbsp; The result might be a granting of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">inappropriate access to the =
user.&nbsp; While it is true that the same thing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">could happen based solely upon =
subject name mismanagement, the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">opportunities for these sorts of =
errors may be even greater when we add the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">additional complexity of processing =
ACs.&nbsp; I won't claim that this is an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">airtight argument, but I think it =
captures the flavor of the concerns that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">motivate soem fo the discussion you =
are seeing on the list.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Steve</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BEAC3B.CD5AA8D2--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA07915 for ietf-pkix-bks; Tue, 1 Jun 1999 07:18:26 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA07911 for <[e-mail]>; Tue, 1 Jun 1999 07:18:22 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Tue, 1 Jun 1999 15:18:20 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id PAA20977; Tue, 1 Jun 1999 15:18:18 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id PAA08259; Tue, 1 Jun 1999 15:18:16 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: Denis Pinkas <[e-mail]>
cc: Stephen Farrell <[e-mail]>, [e-mail]
Subject: Re: attribute encryption (was: Re: X.509 ACs vs. SPKI?) 
In-reply-to: Your message of "Tue, 01 Jun 1999 09:33:38 +0200." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 01 Jun 1999 15:18:16 +0100
From: Stephen Farrell <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

The I-D specifies two levels of conformance:

   "Basic conformance for an AC issuer means support for
   production of ACs which:
	...
   7.   MUST NOT contain encrypted attributes"

Does that solve your problems? If not, lets talk in Oslo,
I'm sure I can convince even you that attribute encryption
is desirable.

> This is not a standard feature of SESAME and not in the SESAME spirit. So please, do not
> refer to SESAME for that case.

It wasn't part of SESAME, we had to add it since our customers
needed it! Whether or not its in the "SESAME spirit" is 
IMHO immaterial to the discussion at hand.

Regards,
Stephen.


 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA04141 for ietf-pkix-bks; Tue, 1 Jun 1999 04:26:15 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA04136 for <[e-mail]>; Tue, 1 Jun 1999 04:26:14 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26272; Tue, 1 Jun 1999 07:26:54 -0400 (EDT)
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-extend-trust-non-repudiation-token-00.txt
Date: Tue, 01 Jun 1999 07:26:54 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Extending trust in non repudiation tokens in time
	Author(s)	: P. Namjoshi
	Filename	: draft-ietf-pkix-extend-trust-non-repudiation-token-00.txt
	Pages		: 7
	Date		: 28-May-99
	
This document describes a way to maintain the trust in a token issued
by a non-repudiation Trusted Third Party (NR TTP) ( DCS/TSA/TDA ) 
after the key initially used to establish trust in the token expires.
The document describes a general format for storage of DCS / TS / TDA
tokens for this purpose .

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-extend-trust-non-repudiation-token-00.txt

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-extend-trust-non-repudiation-token-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-extend-trust-non-repudiation-token-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA03261 for ietf-pkix-bks; Tue, 1 Jun 1999 04:02:20 -0700 (PDT)
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 EAA03257 for <[e-mail]>; Tue, 1 Jun 1999 04:02:17 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id NAA23378; Tue, 1 Jun 1999 13:02:18 +0200
Message-ID: <[e-mail]>
Date: Tue, 01 Jun 1999 13:03:04 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Sarbari Gupta <[e-mail]>
CC: "Robert Zuccherato (E-mail)" <[e-mail]>, "PKIX (E-mail)" <[e-mail]>
Subject: Re: Do we need to authenticate error status and nonce information in  TSA responses?
References: <51BF55C30B4FD1118B4900207812701E38F8FC@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari,

There has ben an avalanche of messages from you on May the 20 th and since
then I have had no time to reply and apparently Robert has not replied
either.

You proposed the following:

TSAResponse ::= SEQUENCE {
        status  PKIStatusInfo,
        nonce   Integer OPTIONAL,
        timeStampToken  SignedData }

I strongly support the separation of the PKIStatusIngfo from the TST. There
are other supporters for this (e.g. Michael Zolotarev).

The nonce CANNOT be outside the TST for security reasons. When the client
has no local time refrence, it picks a nonce at random and sends it. The
fact that the same nonce is sent back and that the response is within its
allowed time frame  (replay is only possible within that time window) allows
to make sure of the timeliness of the response. If the nonce were outside
the signed structure then it could be substituted then no guarantee about
timeliness could be given. The hash cannot be used as a substitute for the
nonce for two reasons:

1) a requester could have the need to time-stamp the same information (hence
the same hash) at two different instants of time, and thus a replay would be
possible in that situation.

2) the hash is now optional, if someone simply wants to get the time back.

I thought these explanations were pretty obvious. Apparently, there are
not.   :-)

I thus propose something along the following

TSAResponse ::= SEQUENCE {
        status  PKIStatusInfo,
        timeStampToken  SignedData }

Regards,

Denis


> Robert,
>
> I have been thinking some more about the actual need to authenticate the
> error messages that come back from the TSA. The conclusion I came to,
> is, that it buys us very little or nothing. Information is only worth
> securing if there is a way for someone to profit from it when the
> information is not secured. So, Denis' proposal for unsigned error
> returns seems adequate.
>
> Let's think about it from the point of view of an attacker. What happens
> if we don't sign an error message from the TSA? An attacker can
> substitute the actual error code with a different error code and make
> the TSA client think that their request failed for a different reason.
> The only gain for the attacker is thus denial-of-service against the TSA
> client. Now consider the opposite scenario where signed error messages
> are sent out by the TSA. Even in this case, the attacker can mount a
> denial-of-service attack by simply deleting the signed error message and
> not letting the TSA client receive it.
>
> My feeling is that the only item that a TSA can return that requires to
> be authenticated is a time stamp token (TST), which, of course, needs to
> be signed.
>
> I would claim that the protocols in the timestamp I-D can be simplified
> by using the SignedData structure to hold the TST (without status and
> nonce) while the status and nonce are passed back (unsigned). Thus, the
> response from a TSA can be defined as a TSAResponse structure as
> follows.
>
> TSAResponse ::= SEQUENCE {
>         status  PKIStatusInfo,
>         nonce   Integer OPTIONAL,
>         timeStampToken  SignedData }
>
> In spite of the above, if someone wants to add authentication to the TSA
> response, they can make use of a secure transport mechanism.
>
> Comments? Thoughts?
>
> - Sarbari
>
> =================================
> Sarbari Gupta
> CygnaCom Solutions
> [phone] (voice)
> [phone](FAX)
> [e-mail]
> =================================



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA26591 for ietf-pkix-bks; Tue, 1 Jun 1999 01:13:53 -0700 (PDT)
Received: from hinge.mistral.co.uk (hinge.mistral.co.uk [195.184.228.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA26587 for <[e-mail]>; Tue, 1 Jun 1999 01:13:51 -0700 (PDT)
Received: from DHARTER (d3-s25-185-telehouse.mistral.co.uk [195.184.228.185]) by hinge.mistral.co.uk (8.8.5/8.6.9) with SMTP id IAA05853; Tue, 1 Jun 1999 08:13:30 +0100
Received: by DHARTER with Microsoft Mail id <01BEAC0F.14021400@DHARTER>; Tue, 1 Jun 1999 09:13:57 +0100
Message-ID: <01BEAC0F.14021400@DHARTER>
From: Darren Harter <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, Aram Perez <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: X.509 ACs vs. SPKI?
Date: Tue, 1 Jun 1999 09:12:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA26588
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Looks good to me.  Also, this would allow for easy searching when multiple hash algorithms are deployed by indexing with the ESSCertId encoding rather than the HashValue - after all they're both streams of octets.

I have one suggestion though. Having id-sha1 as the default in the otherHash seems at odds with the structure's naming.  I think the following would be better:

  HashAlgAndValue ::= SEQUENCE {
     hashAlgorithm AlgorithmIdentier DEFAULT (id-md5),
     hashValue HashValue }

Regards,

Darren

------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions Corp
http://www.entegrity.co.uk
http://www.entegrity.com
Tel:  [phone]
Fax: [phone]
Cell: [phone]
Email: mailto:[e-mail]


-----Original Message-----
From:	Russ Housley [SMTP:[e-mail]]
Sent:	Friday, May 28, 1999 10:39 PM
To:	Aram Perez
Cc:	[e-mail]; [e-mail]
Subject:	Re: X.509 ACs vs. SPKI?

I aggree that including the hash algirith identifier would be preferable.
For ESS, it is too late, but we can do it in a backward compatible way:

  ESSCertID ::=  SEQUENCE {
     certHash  Hash,
     issuerSerial  IssuerSerial OPTIONAL }

  Hash ::= CHOICE {
     sha1Hash  HashValue,
     otherHash  HashAlgAndValue }

  HashAlgAndValue ::= SEQUENCE {
     hashAlgorithm AlgorithmIdentier DEFAULT (id-sha1),
     hashValue HashValue }

  HashValue ::= OCTET STRING

Russ

At 10:12 AM 5/28/99 -0700, Aram Perez wrote:
>Hi Steve,
>
>> Aram,
>> 
>> We need to remain algotihm independent, and thus we cannot insist on just
>> one hash function.  Our data structures that rely on hashes also specify
>> which hash was employed, to prevent ambiguity.
>
>The ASN.1 that Denis Pinkas wrote is:
>
>ESSCertID ::=  SEQUENCE {
>     certHash                 Hash,
>     issuerSerial             IssuerSerial OPTIONAL
>}
>
>Hash ::= OCTET STRING -- SHA1 hash of entire certificate
>
>I'm not an ASN.1 expert, but where is the hash specified (other than in the
>comment)? Is the definition of "Hash" wrong? Should it be something like:
>
>Hash ::= SEQUENCE {
>    hashAlgorithm AlgorithmIdentier,
>    hashValue HashValue
>}
>
>HashValue ::= OCTET STRING
>
>
>If I can paraphrase Solomon: "There is a time to be algorithm independent
>and there is a time to be algorithm dependent." Why complicate and decrease
>the performance of the software that has to look up a certificate. I doubt
>that the data store/directory/database where the certificates are kept wants
>to have a field/attribute for any and every possible hash we allow.
>
>This also begs the question "Why the hash and not just the IssuerSerial?" It
>might be my misunderstanding of X.509, but I was under the
>impression/assumption that the Issuer and Serial Number uniquely identified
>an X.509 certificate.
>
>> The use of hashes as
>> fingerprints for self-signed certs, to facilitate out of band verification
>> has not been a subject of standardization so far, and that is the cause of
>> some of the problems you cite.  We can try to encourage vendors to do the
>> right thing, but if we don't standardize it, ...
>
>Well I believe we should standardize it (i.e. pick 1 hash algorithm).
>
>Regards,
>Aram
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA26585 for ietf-pkix-bks; Tue, 1 Jun 1999 01:13:41 -0700 (PDT)
Received: from hinge.mistral.co.uk (hinge.mistral.co.uk [195.184.228.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA26581 for <[e-mail]>; Tue, 1 Jun 1999 01:13:39 -0700 (PDT)
Received: from DHARTER (d3-s25-185-telehouse.mistral.co.uk [195.184.228.185]) by hinge.mistral.co.uk (8.8.5/8.6.9) with SMTP id IAA05842; Tue, 1 Jun 1999 08:13:28 +0100
Received: by DHARTER with Microsoft Mail id <01BEAC0F.10A135C0@DHARTER>; Tue, 1 Jun 1999 09:13:51 +0100
Message-ID: <01BEAC0F.10A135C0@DHARTER>
From: Darren Harter <[e-mail]>
To: "'Ilan Shacham'" <[e-mail]>, "Ietf-Pkix (E-mail)" <[e-mail]>
Subject: RE: Error in encoding of DSA signature in RFC 2459?
Date: Tue, 1 Jun 1999 08:47:49 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA26582
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ilan,

You are correct.  The examples in RFC 2459 are incorrect in a number of places with respect to integer encodings - always with the leading 00 octet missing.  Several postings have been made to the working group about this, but as far as I am aware the authors have not yet acknowledged the error.

They do get it right in D.3 though where the public key starts as follows:

0319 03 6b        107: . . . BIT STRING
                     : 00   (0 unused bits)
                     : 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f
                     : b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e

Regards,

Darren

------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions Corp
http://www.entegrity.co.uk
http://www.entegrity.com
Tel:  [phone]
Fax: [phone]
Cell: [phone]
Email: mailto:[e-mail]


-----Original Message-----
From:	Ilan Shacham [SMTP:[e-mail]]
Sent:	Sunday, May 30, 1999 3:58 PM
To:	Ietf-Pkix (E-mail)
Subject:	Error in encoding of DSA signature in RFC 2459?

The DSA signature is defined in rfc 2459 as

           Dss-Sig-Value  ::=  SEQUENCE  {
                   r       INTEGER,
                   s       INTEGER  }

where r and s are positive integers (according to the mathematics).
The signature in the first example (D.1) is encoded like this:

0650 03 2f         47: . BIT STRING  (0 unused bits)
                     : 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f
                     : ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a
                     : bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68

integers are encoded in DER in two's compliment, which means a 
positive value with the MSB on, should be encoded with a leading 0
octet, and so the signature sould look like this:

                    : 30 2d 02 15 00 a0 66 c1 76 33 99 13 51 8d 93 64 2f
                     : ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a
                     : bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68

This is repeated in the next examples too.
Am I missing anything here?

Ilan

------------------------------------------------------------------------
Ilan Shacham				mailto:[e-mail]
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA24471 for ietf-pkix-bks; Tue, 1 Jun 1999 00:33:16 -0700 (PDT)
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 AAA24458 for <[e-mail]>; Tue, 1 Jun 1999 00:33:12 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id JAA15550; Tue, 1 Jun 1999 09:32:52 +0200
Message-ID: <[e-mail]>
Date: Tue, 01 Jun 1999 09:33:38 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stephen Farrell <[e-mail]>
CC: [e-mail]
Subject: Re: attribute encryption (was: Re: X.509 ACs vs. SPKI?)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen,

I still do not want to get into deep discussion. :-)

> Denis,
>
> > I don't want to get into deep discussion here but ...
>
> On this one, I'm happy to:-)
>
> > I would not recommend to support encrypted attributes even if the ISO document and
> > the current draft allow for it. It is an extra level of complexity and we can live
> > without it for the moment (and maybe for ever).
>
> I guess you know that we have a kind of Pre-AC based product
> (based on a thing called SESAME:-). One of the most useful
> features we've deployed (as opposed to implemented) is support
> for passing application username/password pairs as encrypted
> attributes (this is the service authentication info in the I-D).

This is not a standard feature of SESAME and not in the SESAME spirit. So please, do not
refer to SESAME for that case.


> There may also be many situations where the fact that I
> possess a privilege is sensitive and attribute encryption
> is a nice way to handle this rather than having to
> produce and manage many ACs and carefully control access
> to the ACs themselves.
>
> Finally, when proxying an AC, (aka delegation in SESAME terms),
> there are cases where I don't want each AC verifier in the
> chain to know all of the privileges; again encrypted
> attributes help here.
>
> In terms of complexity, its pretty easy as long as you have
> a CMS/PKCS#7 EnvelopedData handler already, we've implemented
> it, and I also know of one other implementation supporting
> this. It didn't take long in either case.

The complexity lies in the fact that to encrypt a field the public key of the target is
needed. This places an additional constraint in terms of key management: this mandates
targets to possess public encryption keys while ACs may work without the target to have
such keys and certificates. This "doubles" the complexity. I would like AC to be
deployable without the need for targets to possess any private key, which is possible as
long as attributes are in clear text.

To be very precise, I would like a basic document NOT supporting encrypted attributes.
If you think it is very important, then make a *separate* document so that I can refer
to one (simple) RFC and so that I comply with it without any need/requirement for
supporting encrypted attributes and the related infrastructure.

Regards,

Denis

> Regards,
> Stephen.