RE: ASN.1 question on 2459

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

> From: "Salter, Thomas A" <[e-mail]>
>  > 
>  > But wait ... there are more ways to represent nothing!  Some people
>  > encode an OPTIONAL item that is not used as a BER NULL (0x05 0x00)
>  > instead of just leaving it out.  I understand that there is a
>  > legitimate semantic difference between a sequence of zero 
>  > elements and
>  > a sequence that is absent.  But as far as I know there is no semantic
>  > distinction between a NULL that is present and an element that is
>  > absent; the only reason to encode an optional element as a NULL would
>  > be, as Peter says, to bulk up your certificates.
>  > 
> 
> If they do that, then some people are wrong.  A NULL can only be used if it
> is allowed by the ASN.1 definition.  Some people might write the ASN.1 so
> that an item is a CHOICE of some element or NULL, but otherwise you cannot
> do what you describe.


The RFC 2459 definition of Algorithm Identifier is:

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

AlgorithmIdentifier ::= SEQUENCE {
  algorithm   ALGORITHM-ID.&id({SupportedAlgorithms}),
  parameters  ALGORITHM-ID.&Type({SupportedAlgorithms}
                                 { @algorithm} ) OPTIONAL )
                                 
ALGORITHM-ID ::= CLASS {
  &id  OBJECT IDENTIFIER UNIQUE,
  &Type OPTIONAL }
  WITH SYNTAX { OID &id [PARMS &Type] }
  
SupportedAlgorithms ALGORITHM-ID ::= { ..., --extensible
  rsaMD2 |
  dsaSHA-1 |
      -- and others
}

rsaMD2    ALGORITHM-ID ::= { OID md2WithRSAEncryption PARMS NULL }
dsaSHA-1  ALGORITHM-ID ::= { OID id-dsa-with-sha1     PARMS Dss-Parms }

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

The RFC 2459 examples show an RSA certificate with explicit NULL
parameters (example D3) and DSA certificates with absent
parameters in the two signature fields (examples D1 and D2).

The use of an explicit NULL is allowed by the ASN.1 definitions of the
RSA algorithms, but there seems to be no semantic associated with a
present NULL as opposed to an absent NULL.  The only apparent effect of
encoding three NULLs in example D3 is to increase the size of the
certificate by six octets.




Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA27255 for <[e-mail]>; Thu, 30 Sep 1999 17:36:50 -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 RAA11844 for <[e-mail]>; Thu, 30 Sep 1999 17:37:09 -0700 (PDT)
Received: from netscape.com ([205.217.239.122]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP id FIWF1W00.NAW for <[e-mail]>; Thu, 30 Sep 1999 17:37:08 -0700 
Message-ID: <[e-mail]>
Date: Thu, 30 Sep 1999 17:41:47 -0700
From: [e-mail] (Karen Horwitz)
X-Mailer: Mozilla 4.61 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA23759 for <[e-mail]>; Thu, 30 Sep 1999 13:35:23 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA24139; Thu, 30 Sep 1999 16:36:42 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA24135; Thu, 30 Sep 1999 16:36:42 -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 QAA17436; Thu, 30 Sep 1999 16:36:02 -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 QAA13381; Thu, 30 Sep 1999 16:33:27 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 30 Sep 1999 16:33:27 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: ASN.1 question on 2459
To: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: aq6vl0Ctcmzn83+rPa6HhQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Salter, Thomas A" <[e-mail]>
>  > 
>  > But wait ... there are more ways to represent nothing!  Some people
>  > encode an OPTIONAL item that is not used as a BER NULL (0x05 0x00)
>  > instead of just leaving it out.  I understand that there is a
>  > legitimate semantic difference between a sequence of zero 
>  > elements and
>  > a sequence that is absent.  But as far as I know there is no semantic
>  > distinction between a NULL that is present and an element that is
>  > absent; the only reason to encode an optional element as a NULL would
>  > be, as Peter says, to bulk up your certificates.
>  > 
> 
> If they do that, then some people are wrong.  A NULL can only be used if it
> is allowed by the ASN.1 definition.  Some people might write the ASN.1 so
> that an item is a CHOICE of some element or NULL, but otherwise you cannot
> do what you describe.


The RFC 2459 definition of Algorithm Identifier is:

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

AlgorithmIdentifier ::= SEQUENCE {
  algorithm   ALGORITHM-ID.&id({SupportedAlgorithms}),
  parameters  ALGORITHM-ID.&Type({SupportedAlgorithms}
                                 { @algorithm} ) OPTIONAL )
                                 
ALGORITHM-ID ::= CLASS {
  &id  OBJECT IDENTIFIER UNIQUE,
  &Type OPTIONAL }
  WITH SYNTAX { OID &id [PARMS &Type] }
  
SupportedAlgorithms ALGORITHM-ID ::= { ..., --extensible
  rsaMD2 |
  dsaSHA-1 |
      -- and others
}

rsaMD2    ALGORITHM-ID ::= { OID md2WithRSAEncryption PARMS NULL }
dsaSHA-1  ALGORITHM-ID ::= { OID id-dsa-with-sha1     PARMS Dss-Parms }

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

The RFC 2459 examples show an RSA certificate with explicit NULL
parameters (example D3) and DSA certificates with absent
parameters in the two signature fields (examples D1 and D2).

The use of an explicit NULL is allowed by the ASN.1 definitions of the
RSA algorithms, but there seems to be no semantic associated with a
present NULL as opposed to an absent NULL.  The only apparent effect of
encoding three NULLs in example D3 is to increase the size of the
certificate by six octets.



Received: from bbmail1.unisys.com (bbmail1.unisys.com [192.63.108.35]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA22871 for <[e-mail]>; Thu, 30 Sep 1999 12:49:58 -0700 (PDT)
Received: from trsvrbk.tr.unisys.com (trsvrbk.tr.unisys.com [192.63.236.1]) by bbmail1.unisys.com (8.8.5/8.8.5) with ESMTP id TAA14623 for <[e-mail]>; Thu, 30 Sep 1999 19:50:21 GMT
Received: from us-tr-exch-2.tr.unisys.com by trsvrbk.tr.unisys.com (8.8.5/8.8.5) id TAA04804 ; Thu, 30 Sep 1999 19:50:29 GMT
Received: by us-tr-exch-2.tr.unisys.com with Internet Mail Service (5.5.2448.0) id <T91NCY44>; Thu, 30 Sep 1999 15:49:58 -0400
Message-ID: <[e-mail]>
From: "Salter, Thomas A" <[e-mail]>
To: [e-mail]
Subject: RE: ASN.1 question on 2459
Date: Thu, 30 Sep 1999 15:50:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

 > -----Original Message-----
 > From: David P. Kemp [mailto:[e-mail]]
 > Sent: Thursday, September 30, 1999 12:34 PM
 > To: [e-mail]
 > Subject: Re: ASN.1 question on 2459
...

 > > Some of this stuff is wicked.
 > 
 > But wait ... there are more ways to represent nothing!  Some people
 > encode an OPTIONAL item that is not used as a BER NULL (0x05 0x00)
 > instead of just leaving it out.  I understand that there is a
 > legitimate semantic difference between a sequence of zero 
 > elements and
 > a sequence that is absent.  But as far as I know there is no semantic
 > distinction between a NULL that is present and an element that is
 > absent; the only reason to encode an optional element as a NULL would
 > be, as Peter says, to bulk up your certificates.
 > 

If they do that, then some people are wrong.  A NULL can only be used if it
is allowed by the ASN.1 definition.  Some people might write the ASN.1 so
that an item is a CHOICE of some element or NULL, but otherwise you cannot
do what you describe.

The most likely reason for using NULLs is when the mere presence of an
element is enough to convey the appropriate meaning.  A BOOLEAN could also
be used, but a NULL would take only 2 bytes if present (true) and 0 if
absent (false), whereas a BOOLEAN would always be 3 bytes.

A reason for encoding empty SETs and SEQUENCEs is to serve as placeholders
when there are several untagged but similar constructs in a row. For
example,
	SEQUENCE { a SET OF xxx,
                  b SET OF xxx,
                  c SET OF xxx }
If a, b, c were optional you received a sequence containing only 1 SET, you
couldn't tell whether it was supposed to be a, b, or c.



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA22230 for <[e-mail]>; Thu, 30 Sep 1999 12:08:07 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id MAA07068; Thu, 30 Sep 1999 12:09:02 -0700 (PDT)
Received: from rsalaptop ([192.168.3.229]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id MAA16357; Thu, 30 Sep 1999 12:09:01 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Phillip M Hallam-Baker" <[e-mail]>, "Trevor Freeman" <[e-mail]>, "Pkix List (E-mail)" <[e-mail]>
Subject: RE: Delta CRL Distribution Points
Date: Thu, 30 Sep 1999 12:11:43 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <000901bf0b57$e3130cc0$[e-mail]>

> As I said earlier, delta CRLs are problematic and managing them is
> intrinsically complex. Scope CRLs offer considerably more flexibility,
> are intrinsically simpler and in many cases address the same need.

Delta CRLs are one mechanism that enable availability security
services for validation and other PKI status services. There are
several emerging security services that
address the availability requirements of PKI validation
services. One can expect a range of application of the delta-CRL technology,
in support of those sevices, much as digital signature mechanisms
supports a range of integrity services. I disagree that they
are intrinsically complex; that's VeriSign marketing hogwash, to use
a term from American-English.

The literature has much recorded know-how on delta handling, appropriate
data structures, and at one level, the PKIX problem is no different
to secure directory replication techniques, that also feature delta-based
synchronization schemes. For example, ValiCert's CRT technologies
uses much of that know-how, with careful security design; so the use
of delta-CRL technology is a good path to follow-up for next generation
validation services using open technology.

What we perhaps need to do as a group is understand the technical
interworking and security properties of proposed schemes. Microsoft has
taken the lead to get the work going, and is to be commended for
that step. I know ValiCert has a certain expertise based on
operating practical availability schemes for PKI status services
(based, in part, on delta-schemes tuned to PKI threats) which can
be fed in via the usual commenting process.


> What I am not prepared to accept is any suggestion that because
> delta CRL + scope CRL appears complex the answer is to exclude the
> scope CRL entirely.


Tact, please!

There seems no reason why several delta-CRL schemes cannot support
multiple PKIX-specified availability services tuned to the
status distribution problem, where the proponent can justify the
distinctive properties of each.

Now that the agenda item is up for comment, each party that wishes
to suggest a use of CRL delta scheme can go write an ID. Then, the WG
and list can compare, reuse, discard, or reframe the contributions
into this evolving area of the PKIX architecture.

We can await the complex-scheme ID from VeriSign, I trust.

I am sure you can justify the benefits of your approach
in writing, as can others for their approaches. Once we have
some detailed specifications, we can see what would most
benefit the standard architecture: 1 single solution, or a
range of solutions fitting different requirements addressing
distinct Internet needs.

A minimal technical requirement for delta-CRL syntax handling
(common to all PKIX schemes) may be required; its identification
would be valuable, ...

I suggest.







Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA18810 for <[e-mail]>; Thu, 30 Sep 1999 09:35:34 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA08397 for <[e-mail]>; Thu, 30 Sep 1999 12:36:54 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA08393 for <[e-mail]>; Thu, 30 Sep 1999 12:36:54 -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 MAA14550 for <[e-mail]>; Thu, 30 Sep 1999 12:36: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 MAA12942 for <[e-mail]>; Thu, 30 Sep 1999 12:33:40 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 30 Sep 1999 12:33:40 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: ASN.1 question on 2459
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: vI71H7RiO32WrREfFDwYBg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> Thank you all of you that answered.
> 
> In 2459, SET seems to be used only in Name things.  SEQUENCE SIZE is used
> most of the time, and it always starts with 1..
> 
> But some of them are 'optional':
> 
>         policyQualifiers   SEQUENCE SIZE (1..MAX) OF
>                                 PolicyQualifierInfo OPTIONAL }
> 
> 
> Again this is a bit confusing to the casual reader.  The only LOGICAL
> interpretation is a SEQUENCE of SIZE 0 is different in the cert than not
> present and this is desireable.  OK.

Yes, the BER encoding of an OPTIONAL item that is absent takes up 0 bytes,
whereas the encoding of a SEQUENCE of zero elements takes up 2 bytes
(the tag for SEQUENCE, 0x30, and a length of 0x00).

> Some of this stuff is wicked.

But wait ... there are more ways to represent nothing!  Some people
encode an OPTIONAL item that is not used as a BER NULL (0x05 0x00)
instead of just leaving it out.  I understand that there is a
legitimate semantic difference between a sequence of zero elements and
a sequence that is absent.  But as far as I know there is no semantic
distinction between a NULL that is present and an element that is
absent; the only reason to encode an optional element as a NULL would
be, as Peter says, to bulk up your certificates.

The reason for the SIZE(1..MAX) on OPTIONAL elements is to eliminate
one of the possible encodings - if you have no list members to encode,
you must make the list absent instead of present and empty.



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA17426 for <[e-mail]>; Thu, 30 Sep 1999 08:22:50 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA20843; Thu, 30 Sep 1999 08:21:30 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA14462; Thu, 30 Sep 1999 08:23:12 -0700 (PDT)
Received: from pbaker-pc.verisign.com (VERISIGN [172.16.1.246]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SF5SLPR9; Thu, 30 Sep 1999 08:23:11 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, "Pkix List (E-mail)" <[e-mail]>
Subject: RE: Delta CRL Distribution Points
Date: Thu, 30 Sep 1999 11:24:28 -0400
Message-ID: <000901bf0b57$e3130cc0$[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: <2F2DC5CE035DD1118C8E00805FFE354C0F5266F0@RED-MSG-56>

I think I have it now, perhaps an example will help clarify things.

Let the initial cert population be {1, 2, 3, 4, 5, 6}

You propose that we allow this to be partitioned into two CDPs, X and Y.
	X = {2, 4 , 5, 6}
	Y = {1, 3}

There are two base CRLs, one per CDP partition.

What you are proposing it appears is that we do not allow someone to
then use the scopes to further partition the delta CRLs. In other
words we would forbid scope partitioning X into {2, 4} and {5, 6}.
Similarly it would be right out to partition the base CRLs as X, Y
and then define scope partitions {1, 2, 3} and {4, 5, 6}.

It seems to me that it is reasonable to advise folk to partition
their delta CRLs in the same manner as their base CRLs. I am not
sure it is possible to require this however.


A CA might issue two separate sets of CRL data for the same cert
population. For example there might be a CDP partitioned CRL
issued for one set of users and a scope partition for another set.

I think it is entirely reasonable for a CA to do this, and prohibiting
a CA from doing so on the grounds of 'simplicity' seems wrong to
me (not to say almost certain to be ignored).

I certainly don't think that a security spec can make any profile
restriction that an application would be wise to rely upon as a
security issue. PKIX applications must be able to tolerate information
produced that is not PKIX profile without disaster. So a PKIX app.
MUST be able to recognise that it has mismatched partitions even if
it is not REQUIRED to understand how to use them.


As I said earlier, delta CRLs are problematic and managing them is
intrinsically complex. Scope CRLs offer considerably more flexibility,
are intrinsically simpler and in many cases address the same need.

What I am not prepared to accept is any suggestion that because
delta CRL + scope CRL appears complex the answer is to exclude the
scope CRL entirely.


		Phill

> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Wednesday, September 29, 1999 7:04 PM
> To: 'Phillip M Hallam-Baker'; Pkix List (E-mail)
> Subject: RE: Delta CRL Distribution Points
>
>
> Having modest aspirations initially does not exclude the standard evolving
> to encompass new features so we can revisit later and add more features. I
> am just proposing one level of simplification, that is partition the base
> CRL as per 2459, then have a single delta for that partition. If
> experience
> shows we need to partition the delta CRL as well then we can add
> that later.
> We are revising 2459 and delta CRLs are included in 2459,
> therefore we need
> the discussion now.
>
> -----Original Message-----
> From: Phillip M Hallam-Baker [mailto:[e-mail]]
> Sent: Wednesday, September 29, 1999 1:13 PM
> To: Trevor Freeman; Pkix List (E-mail)
> Subject: RE: Delta CRL Distribution Points
>
>
> This is a good point. The FPDAM provides a lot of rope in the CRL area,
> it is probably inadvisable to use all of it. On the other hand I see
> considerable disadvantages to forbidding use of all of it!
>
>
> As I see it delta CRLs, and the various scope mechanisms (serial numbers,
> CDPs) have a certain degree of overlap. Certainly scopes and delta CRLs
> are both a means of keeping the size of the CRL manageable.
>
> I agree that using these mechanisms in conjunction would be complex in
> practice. I am not sure that using scopes and delta CRLs is considerably
> more complex than delta CRLs alone but it would certainly be a defensible
> implementation decision to allow use of one mechanism or the other but
> not both.
>
> On the other hand some folk might argue that prohibiting use of both
> mechanisms together would introduce complexity. This was the reason
> why I raised no objection to the extension of OCDP to cover delta
> CRLs.
>
> [Note: in order to avoid starting another CRL arguing match I should
> frame the discussion bellow by pointing out that the issues of scale
> which I refer to are on the order of 1 million to 1 billion certs.]
>
> I believe that the root of the complexity in this case is attempting to
> manage a situation where multiple signed documents issued at different
> times must be combined to validate a certificate. This is an intrinsic
> problem with both Delta CRLs and Paul Kocher's CRTs. If the voulme of
> updates becomes large there is a scalability problem which manifests
> itself as a reliability issue as opposed to a performance issue.
>
> [Similar objections were raised when I proposed that the meta-CRLs of
> OCDP be infinitely recursive, a proposal which was sensibly reduced
> to a comment made for prior art purposes in the public OCDP draft. This
> is why the stacking depth of OCDP CRLs was limited to 2!]
>
>
> Given this intrinsic complexity issue one might well regard the use of
> scopes as essential if a large system were to be deployed using delta
> CRLs.
>
> I don't see that we need to take a decision on this in PKIX at this point
> however. Certainly not until the FPDAM is voted on.
>
>
> 		Phill
>
>
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[e-mail]]
> > Sent: Wednesday, September 29, 1999 3:17 PM
> > To: Pkix List (E-mail)
> > Subject: Delta CRL Distribution Points
> >
> >
> > I have been looking at the Delta CRL section of 2459 as well as
> the latest
> > X.509 FPDAM, and have a number of issues. So the mail threads don't get
> > confusing, I will try to confine each mail to a single topic.
> > To implement Delta CRL's, you would need to add a mechanism to
> 2459 as to
> > how\where a client finds a delta CRL. The PDAM defines two
> mechanisms, one
> > of which (Freshest CRL) has the same ASN as an existing 2459 extension
> > (CDP). I propose we include the Freshest CRL in the revised 2459 as the
> > method to defining the Delta CRL distribution point. This
> > extension could be
> > used in both the certificate and the CRL itself. My view is
> that we should
> > recommend that the extension be used in the CRL itself and that the
> > extension should only contain the list of general names i.e. no other
> > qualifiers. This gives a very simple relationship between the
> > base and delta
> > CRL. If you have already partitioned the base CRL, I don't see much
> > advantage in partitioning the delta as well.
> > Trevor
> >
>



Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.imc.org (8.9.3/8.9.3) with SMTP id GAA15112 for <[e-mail]>; Thu, 30 Sep 1999 06:24:29 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Thu, 30 Sep 1999 09:25:18 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 30 Sep 1999 09:24:49 -0400
To: [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: ASN.1 question on 2459
In-Reply-To: <[e-mail]>
References: <[e-mail]> <006d01bf0925$64c64aa0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 05:10 PM 9/29/1999 -0400, Robert Moskowitz wrote:
>What is the difference between the following two structures:
>
>::= SEQUENCE SIZE (1..MAX) OF
>
>::= SET OF
>
Thank you all of you that answered.

In 2459, SET seems to be used only in Name things.  SEQUENCE SIZE is used
most of the time, and it always starts with 1..

But some of them are 'optional':

        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                PolicyQualifierInfo OPTIONAL }


Again this is a bit confusing to the casual reader.  The only LOGICAL
interpretation is a SEQUENCE of SIZE 0 is different in the cert than not
present and this is desireable.  OK.

Some of this stuff is wicked.


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


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA13255 for <[e-mail]>; Thu, 30 Sep 1999 05:07:22 -0700 (PDT)
Received: from edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA24173 for <[e-mail]>; Thu, 30 Sep 1999 14:08:10 +0200 (MET DST)
Received: from edelweb.fr (budweiser.edelweb.fr [193.51.14.120]) by edelweb.fr (nospam/1.1); Thu, 30 Sep 1999 14:08:09 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 30 Sep 1999 13:56:43 +0200
From: DECOOL =?iso-8859-1?Q?j=E9r=F4me?= <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: fr,en
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe



Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA09928 for <[e-mail]>; Thu, 30 Sep 1999 03:22:27 -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 KAA06099; Thu, 30 Sep 1999 10:22:52 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 LAA14770; Thu, 30 Sep 1999 11:23:03 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Sep 1999 11:22:51 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.6 [en-gb] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: ASN.1 question on 2459
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:
> Originally SET of was a collection where order didn't matter and SEQUENCE was
> one where it did, however SET has some really ugly encoding requirements under
> the DER (you have to sort the elements of the set by encoded value and then
> build the set in sorted order), current practice seems to be to use SEQUENCE
> even where you really mean SET.

Arg. No, it isn't. This is one of the first bugs I fixed in OpenSSL.

Unless you mean current practice is to write the ASN.1 to use a SEQUENCE
(rather than encode SET incorrectly)?

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 mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mail.imc.org (8.9.3/8.9.3) with SMTP id QAA04161 for <[e-mail]>; Wed, 29 Sep 1999 16:16:15 -0700 (PDT)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Sep 1999 16:03:39 -0700 (Pacific Daylight Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id <TYZTVDY8>; Wed, 29 Sep 1999 16:03:39 -0700
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0F5266F0@RED-MSG-56>
From: Trevor Freeman <[e-mail]>
To: "'Phillip M Hallam-Baker'" <[e-mail]>, "Pkix List (E-mail)" <[e-mail]>
Subject: RE: Delta CRL Distribution Points
Date: Wed, 29 Sep 1999 16:03:37 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)

Having modest aspirations initially does not exclude the standard evolving
to encompass new features so we can revisit later and add more features. I
am just proposing one level of simplification, that is partition the base
CRL as per 2459, then have a single delta for that partition. If experience
shows we need to partition the delta CRL as well then we can add that later.
We are revising 2459 and delta CRLs are included in 2459, therefore we need
the discussion now.

-----Original Message-----
From: Phillip M Hallam-Baker [mailto:[e-mail]]
Sent: Wednesday, September 29, 1999 1:13 PM
To: Trevor Freeman; Pkix List (E-mail)
Subject: RE: Delta CRL Distribution Points


This is a good point. The FPDAM provides a lot of rope in the CRL area,
it is probably inadvisable to use all of it. On the other hand I see
considerable disadvantages to forbidding use of all of it!


As I see it delta CRLs, and the various scope mechanisms (serial numbers,
CDPs) have a certain degree of overlap. Certainly scopes and delta CRLs
are both a means of keeping the size of the CRL manageable.

I agree that using these mechanisms in conjunction would be complex in
practice. I am not sure that using scopes and delta CRLs is considerably
more complex than delta CRLs alone but it would certainly be a defensible
implementation decision to allow use of one mechanism or the other but
not both.

On the other hand some folk might argue that prohibiting use of both
mechanisms together would introduce complexity. This was the reason
why I raised no objection to the extension of OCDP to cover delta
CRLs.

[Note: in order to avoid starting another CRL arguing match I should
frame the discussion bellow by pointing out that the issues of scale
which I refer to are on the order of 1 million to 1 billion certs.]

I believe that the root of the complexity in this case is attempting to
manage a situation where multiple signed documents issued at different
times must be combined to validate a certificate. This is an intrinsic
problem with both Delta CRLs and Paul Kocher's CRTs. If the voulme of
updates becomes large there is a scalability problem which manifests
itself as a reliability issue as opposed to a performance issue.

[Similar objections were raised when I proposed that the meta-CRLs of
OCDP be infinitely recursive, a proposal which was sensibly reduced
to a comment made for prior art purposes in the public OCDP draft. This
is why the stacking depth of OCDP CRLs was limited to 2!]


Given this intrinsic complexity issue one might well regard the use of
scopes as essential if a large system were to be deployed using delta
CRLs.

I don't see that we need to take a decision on this in PKIX at this point
however. Certainly not until the FPDAM is voted on.


		Phill


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Wednesday, September 29, 1999 3:17 PM
> To: Pkix List (E-mail)
> Subject: Delta CRL Distribution Points
>
>
> I have been looking at the Delta CRL section of 2459 as well as the latest
> X.509 FPDAM, and have a number of issues. So the mail threads don't get
> confusing, I will try to confine each mail to a single topic.
> To implement Delta CRL's, you would need to add a mechanism to 2459 as to
> how\where a client finds a delta CRL. The PDAM defines two mechanisms, one
> of which (Freshest CRL) has the same ASN as an existing 2459 extension
> (CDP). I propose we include the Freshest CRL in the revised 2459 as the
> method to defining the Delta CRL distribution point. This
> extension could be
> used in both the certificate and the CRL itself. My view is that we should
> recommend that the extension be used in the CRL itself and that the
> extension should only contain the list of general names i.e. no other
> qualifiers. This gives a very simple relationship between the
> base and delta
> CRL. If you have already partitioned the base CRL, I don't see much
> advantage in partitioning the delta as well.
> Trevor
>


Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mail.imc.org (8.9.3/8.9.3) with SMTP id PAA03518 for <[e-mail]>; Wed, 29 Sep 1999 15:32:44 -0700 (PDT)
Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Sep 1999 15:33:05 -0700 (Pacific Daylight Time)
Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id <TM4C06VB>; Wed, 29 Sep 1999 15:33:05 -0700
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0F5266EE@RED-MSG-56>
From: Trevor Freeman <[e-mail]>
To: "Pkix List (E-mail)" <[e-mail]>
Subject: Delta CRL's and Publication Replication Latency
Date: Wed, 29 Sep 1999 15:33:00 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)

If it fairly common to have publication mechanism for CRL's such as file
systems, LDAP directories etc, which use replication. This introduces a
delay between publication and the new version being available to at
replicas.  Similarly inter-directory synchronisation also introduces a delay
between publication and availability. The proven solution for these
situations is to extend the next update time of the CRL, e.g. publish every
week, mark the next update time as 8 days after the this update time of  the
CRL. In doing so you loose an interesting piece of information that is the
true publication period of the CRL. This is OK for full CRL's where
typically you would expect the replication time << publication period so the
difference between the apparent and true publication period is small. Delta
CRL are different in that it is far more likely for the replication time to
be > publication period, therefore the difference between the apparent and
true publication period will be large. Publishing every week and adding on 8
hours for replication has a much smaller proportionate impact to publishing
every hour and adding 8 hours. 
It would be very useful for the CA to include a hint of the publication
period so the client can make an informed judgment when to look for a new
CRL. An integer representing the number of minutes for the publication
period or a Generalised time value for the expected publication time would
be a good candidates.


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA03202 for <[e-mail]>; Wed, 29 Sep 1999 15:15:37 -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 KAA18657 for <[e-mail]>; Thu, 30 Sep 1999 10:16:22 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <93864338216455>; Thu, 30 Sep 1999 10:16:22 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: ASN.1 question on 2459
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 30 Sep 1999 10:16:22 (NZST)
Message-ID: <[e-mail]>

Re: ASN.1 question on 2459
Robert Moskowitz <[e-mail]> writes:

>What is the difference between the following two structures:
>
>::= SEQUENCE SIZE (1..MAX) OF
>
>::= SET OF
>
>To the casual reader they are both a collection of one or more thingees.

Originally SET of was a collection where order didn't matter and SEQUENCE was
one where it did, however SET has some really ugly encoding requirements under
the DER (you have to sort the elements of the set by encoded value and then
build the set in sorted order), current practice seems to be to use SEQUENCE
even where you really mean SET.

Peter.



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.imc.org (8.9.3/8.9.3) with SMTP id OAA02776 for <[e-mail]>; Wed, 29 Sep 1999 14:52:36 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 29 Sep 1999 15:52:47 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Wed, 29 Sep 1999 15:52:41 -0600
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: ASN.1 question on 2459
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_184ED03F.9CFD9D16"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_184ED03F.9CFD9D16
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

SET is an unordered set of "items", whereas SEQUENCE is ordered as =
prescribed in the definition of that SEQUENCE, and the order is significant=
 contrary to SET.

- Tolga

>>> Robert Moskowitz <[e-mail]> 9/29/99 15:10:58 >>>
What is the difference between the following two structures:

::=3D SEQUENCE SIZE (1..MAX) OF

::=3D SET OF

To the casual reader they are both a collection of one or more thingees.

Unless SET implies an empty set so that=20

SET =3D=3D SEQUENCE SIZE (0..MAX) OF


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

--=_184ED03F.9CFD9D16
Content-Type: text/plain
Content-Disposition: attachment; filename="TEXT.htm"

<!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.2314.1000" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff 
style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
<DIV>SET is an unordered set of "items", whereas SEQUENCE is ordered as 
prescribed in the definition of that SEQUENCE, and the order is significant 
contrary to SET.</DIV>
<DIV>&nbsp;</DIV>
<DIV>- Tolga<BR><BR>&gt;&gt;&gt; Robert Moskowitz 
&lt;[e-mail]&gt; 9/29/99 15:10:58 &gt;&gt;&gt;<BR>What is the 
difference between the following two structures:<BR><BR>::= SEQUENCE SIZE 
(1..MAX) OF<BR><BR>::= SET OF<BR><BR>To the casual reader they are both a 
collection of one or more thingees.<BR><BR>Unless SET implies an empty set so 
that <BR><BR>SET == SEQUENCE SIZE (0..MAX) OF<BR><BR><BR>Robert 
Moskowitz<BR>ICSA<BR>Security Interest EMail: 
[e-mail]<BR></DIV></BODY></HTML>
--=_184ED03F.9CFD9D16--


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA02494 for <[e-mail]>; Wed, 29 Sep 1999 14:39:37 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id OAA01472; Wed, 29 Sep 1999 14:40:28 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id OAA27709; Wed, 29 Sep 1999 14:40:27 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Robert Moskowitz'" <[e-mail]>, <[e-mail]>
Subject: RE: ASN.1 question on 2459
Date: Wed, 29 Sep 1999 14:44:02 -0700
Message-ID: <014d01bf0ac3$bf931090$[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]>

Hi Bob,
    Not sure if I am stating the obvious, but SEQUENCEs and
SETs are slightly different things in ASN.1, where a sequence
is an ordered bag of things, while a set is unordered (also, their
encoding is different).

In practice, I am not sure people in PKIX-land distinguish
between the two other than to make sure the DER/BER encoding is
correct.

A

---------------------------------------------------------------------
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: Robert Moskowitz [mailto:[e-mail]]
> Sent: Wednesday, September 29, 1999 2:11 PM
> To: [e-mail]
> Subject: ASN.1 question on 2459
> 
> 
> What is the difference between the following two structures:
> 
> ::= SEQUENCE SIZE (1..MAX) OF
> 
> ::= SET OF
> 
> To the casual reader they are both a collection of one or 
> more thingees.
> 
> Unless SET implies an empty set so that 
> 
> SET == SEQUENCE SIZE (0..MAX) OF
> 
> 
> Robert Moskowitz
> ICSA
> Security Interest EMail: [e-mail]
> 


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.imc.org (8.9.3/8.9.3) with SMTP id OAA02047 for <[e-mail]>; Wed, 29 Sep 1999 14:10:49 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Wed, 29 Sep 1999 17:11:23 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 29 Sep 1999 17:10:58 -0400
To: [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: ASN.1 question on 2459
In-Reply-To: <[e-mail]>
References: <006d01bf0925$64c64aa0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

What is the difference between the following two structures:

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

::= SET OF

To the casual reader they are both a collection of one or more thingees.

Unless SET implies an empty set so that 

SET == SEQUENCE SIZE (0..MAX) OF


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


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA01388 for <[e-mail]>; Wed, 29 Sep 1999 13:11:28 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id NAA22982; Wed, 29 Sep 1999 13:09:59 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id NAA21243; Wed, 29 Sep 1999 13:11:24 -0700 (PDT)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SF5SLK44; Wed, 29 Sep 1999 13:11:24 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, "Pkix List (E-mail)" <[e-mail]>
Subject: RE: Delta CRL Distribution Points
Date: Wed, 29 Sep 1999 16:12:45 -0400
Message-ID: <004701bf0ab6$fe092100$[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: <2F2DC5CE035DD1118C8E00805FFE354C0F5266EC@RED-MSG-56>

This is a good point. The FPDAM provides a lot of rope in the CRL area,
it is probably inadvisable to use all of it. On the other hand I see
considerable disadvantages to forbidding use of all of it!


As I see it delta CRLs, and the various scope mechanisms (serial numbers,
CDPs) have a certain degree of overlap. Certainly scopes and delta CRLs
are both a means of keeping the size of the CRL manageable.

I agree that using these mechanisms in conjunction would be complex in
practice. I am not sure that using scopes and delta CRLs is considerably
more complex than delta CRLs alone but it would certainly be a defensible
implementation decision to allow use of one mechanism or the other but
not both.

On the other hand some folk might argue that prohibiting use of both
mechanisms together would introduce complexity. This was the reason
why I raised no objection to the extension of OCDP to cover delta
CRLs.

[Note: in order to avoid starting another CRL arguing match I should
frame the discussion bellow by pointing out that the issues of scale
which I refer to are on the order of 1 million to 1 billion certs.]

I believe that the root of the complexity in this case is attempting to
manage a situation where multiple signed documents issued at different
times must be combined to validate a certificate. This is an intrinsic
problem with both Delta CRLs and Paul Kocher's CRTs. If the voulme of
updates becomes large there is a scalability problem which manifests
itself as a reliability issue as opposed to a performance issue.

[Similar objections were raised when I proposed that the meta-CRLs of
OCDP be infinitely recursive, a proposal which was sensibly reduced
to a comment made for prior art purposes in the public OCDP draft. This
is why the stacking depth of OCDP CRLs was limited to 2!]


Given this intrinsic complexity issue one might well regard the use of
scopes as essential if a large system were to be deployed using delta
CRLs.

I don't see that we need to take a decision on this in PKIX at this point
however. Certainly not until the FPDAM is voted on.


		Phill


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Wednesday, September 29, 1999 3:17 PM
> To: Pkix List (E-mail)
> Subject: Delta CRL Distribution Points
>
>
> I have been looking at the Delta CRL section of 2459 as well as the latest
> X.509 FPDAM, and have a number of issues. So the mail threads don't get
> confusing, I will try to confine each mail to a single topic.
> To implement Delta CRL's, you would need to add a mechanism to 2459 as to
> how\where a client finds a delta CRL. The PDAM defines two mechanisms, one
> of which (Freshest CRL) has the same ASN as an existing 2459 extension
> (CDP). I propose we include the Freshest CRL in the revised 2459 as the
> method to defining the Delta CRL distribution point. This
> extension could be
> used in both the certificate and the CRL itself. My view is that we should
> recommend that the extension be used in the CRL itself and that the
> extension should only contain the list of general names i.e. no other
> qualifiers. This gives a very simple relationship between the
> base and delta
> CRL. If you have already partitioned the base CRL, I don't see much
> advantage in partitioning the delta as well.
> Trevor
>



Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA00704 for <[e-mail]>; Wed, 29 Sep 1999 12:21:09 -0700 (PDT)
Received: from mobile (mobile [192.168.42.7]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id MAA06025; Wed, 29 Sep 1999 12:21:42 -0700
From: "Amit Kapoor" <[e-mail]>
To: "Peter Biltzinger" <[e-mail]>, <[e-mail]>
Subject: RE: CMP-polling
Date: Wed, 29 Sep 1999 12:20:18 -0700
MIME-Version: 1.0
Message-ID: <005901bf0aaf$aa2bb950$[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0054_01BF0A74.FD698BA0"
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

This is a multi-part message in MIME format.

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


Hi Peter,

	Comments inline:
 
> Couldn't it be possible to start a denial-of-service attack
> when using the current polling mechanism without SSL? Aren't
> the following protocols conceivable?
> 
> a)
> 
> 1. The RA sends a signed pkiMsg to the CA and the CA sends
>    a unsigned pollRep to the RA.
> 
> 2. The Attacker snoops the pollingReferenceNumber and
>    sends the unsigned pollReq to the CA (before the RA
>    does this) and the CA sends the signed pkiMsg or
>    the unsigned pollRep (with new pollingReferenceNumber)
>    to the attacker.
> 
>    In the case of sending a new pollingReferenceNumber by the
>    CA the RA never gets this number and cannot send a pollReq
>    which includes this new number in order to get the
>    certificates. The communication between RA and CA is interrupt.
>    In the case of sending a signed pkiMsg by the CA to the
>    attacker the CA couldn't recognize the attack until
>    the CA administrator is missing the PKIConfirmation.
>    In both cases manual activity would be necessary to
>    recognize and handle this attack.

	Yes, this is possible.  But manual activity is not
	necessary.  The CA/RA can time out on a stored request
	for which no signed confirm has been received.

> 
> b) Even worse, if the man in the middle intercepts a RA-pollReq,
>    he would get the signed CA-pkiMsg and could forward a
>    new unsigned CA-pollRep with a new pollingReferenceNumber
>    and a new 'time-to-ckeck-back' parameter to the RA.
>    Both parties (RA and CA) would be satisfied until the
>    CA administrator is missing the PKIConfirmation. Again,
>    manual activity would be necessary to recognize and handle
>    this attack.

	Yes, but again no manual intervention is necessary.

> 
> c) The attacker sends unsigned pollReq with snooped
>    old pollingReferenceNumbers or with random numbers to
>    the CA and the CA sends signed pkiMsg or unsigned
>    pollRep to the attacker. In the case of a hard attack
>    of this kind the CA can be overloaded which is equal
>    to a denial-of-service attack. (A signed pollReq would have
>    the advantage, that the verification of the RSA signature
>    is very much faster than the generation of the
>    RSA signature regarding the CA-pkiMsg to be generated
>    and perhaps to be encrypted.)
>    Nevertheless, in the case of signed pollReq (PKIMessages which
>    should contain the pollingReferenceNumber) the attacker can
>    snoop a signed RA-pollReq and send this one to the CA. But in
>    this case, the CA can verify the recipNonce in this kind of
>    PKIMessage and would be able to recognize a replay attack.
> 
> Are these attacks not conceivable?
> 

	The end entity not getting the new polling reference number
	is feasible without a attack also.  Say, I send a IR, get
	back a poll response, send a poll request, and the poll
	response (with a new poll reference) is lost on the
	network.  Both sides, client and server, have to be
	aware of this and be ready to take suitable action.

	You are completely correct in that all the above attacks
	are feasible.  However, these are denial of service attacks
	and if someone wants to really do that, they do not have
	to go to such pains as snooping, trying to get in the
	middle.  I would just send tons of signed certificate
	requests and let the server verify them and realize it
	does not know me, wasting lots of processor bandwidth.
	Or even send incorrectly encoded PKIMessages or even
	signed poll requests or create TCP connections or ...

	My point in my earlier message was to see if I had understood
	your concern on sending certificates with sensitive information
	in the clear.

	regards

Amit

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIID1DCCA9Aw
ggM7oAMCAQICFEQ41iugpRpD1VzRmFQZQnkJUk6OMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1T
TWVtZSBSb290IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwNjI4MDAzMDE3
WhcNMDQwNjI4MDAzMDE3WjBPMRMwEQYDVQQKEwpUcnVzdHBvaW50MRQwEgYDVQQDEwtBbWl0IEth
cG9vcjEiMCAGCSqGSIb3DQEJARYTYW1pdEB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAs/M5RIk9+UTqdrpG/UaFOjxTfCs7S9kCJtHroRgDS3Ss+eKt+Re+6NLnxm3S
+pszODOrglLwn19+Zbp3yeVXMsaYLy9+9Jwcm0l+wQGDk8Kh8xUA1MQssVaW9rWamtAvQY+Mje4S
HBjXayCIPyIMJ29Ypk49P1vKbuqgLB/ZQFECAwEAAaOCAcUwggHBMB0GA1UdDgQWBBRo1B8wQ8Kj
E90aF8xiyBKsdXMc3zAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB
/wQEAwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG
+EIBAQQEAwIAsDAeBgNVHREEFzAVgRNhbWl0QHRydXN0cG9pbnQuY29tME8GA1UdIARIMEYwRAYI
KwYEAZhUHgEwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5zbWVtZS5jb20vc2VydmljZWFncmVl
bWVudC5odG1sMEMGCWCGSAGG+EIBAwQ2FjRodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0cy9z
bWVtZV9jYS9jaGVja19yZXZva2VkMEAGCWCGSAGG+EIBBwQzFjFodHRwOi8vd3d3LnNtZW1lLmNv
bS9zZXJ2bGV0cy9zbWVtZV9jYS9yZW5ld19jZXJ0MDkGCWCGSAGG+EIBCAQsFipodHRwOi8vd3d3
LnNtZW1lLmNvbS9zZXJ2aWNlYWdyZWVtZW50Lmh0bWwwCwYJKoZIhvcNAQEFA4GBAFS76N1D2ogo
AEAUBV8b6/skJBuju82MnaKh9RlJ7elFikwwPGe9SEblPtbp/+QbDtAVIiwmOIE1XPEZi0cWfLTi
P8pa0BRBl5H419aoIfeoZTsZz4R7E7eGd7rsK37dyBzKbnqio2nzJNhx7FJJDkA7VajJbhk8tdkW
RL6IjymQMYIB/TCCAfkCAQEwTTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT
TWVtZTELMAkGA1UEBhMCVVMCFEQ41iugpRpD1VzRmFQZQnkJUk6OMAkGBSsOAwIaBQCgggEGMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MDkyOTE5MjAxN1owIwYJ
KoZIhvcNAQkEMRYEFJqTdt+qNVisKaucUaQ7+ItCWTxQMEkGCSqGSIb3DQEJDzE8MDowCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcGBSsOAwIaMAoGCCqGSIb3DQIFMFwGCSsG
AQQBgjcQBDFPME0wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJ
BgNVBAYTAlVTAhREONYroKUaQ9Vc0ZhUGUJ5CVJOjjANBgkqhkiG9w0BAQEFAASBgGgyDsvrFi+s
gndw7Atwfo8C094cNdwo2rMRp/6LwInvopTHi3JvbJKdywk7hjggJY8lijb2+wOX0pURufZLsqhe
myEmHCbwwBy3WXjq8qcZ6fi59VzUruGfjgwrKQkBZF+2p5ZL4si4VfWbGigdFgHfEKJC2i21vDVe
98P/feVrAAAAAAAA

------=_NextPart_000_0054_01BF0A74.FD698BA0--



Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mail.imc.org (8.9.3/8.9.3) with SMTP id MAA00585 for <[e-mail]>; Wed, 29 Sep 1999 12:16:49 -0700 (PDT)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Sep 1999 12:17:09 -0700 (Pacific Daylight Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id <TYZT41RD>; Wed, 29 Sep 1999 12:17:08 -0700
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0F5266EC@RED-MSG-56>
From: Trevor Freeman <[e-mail]>
To: "Pkix List (E-mail)" <[e-mail]>
Subject: Delta CRL Distribution Points
Date: Wed, 29 Sep 1999 12:17:06 -0700
X-Mailer: Internet Mail Service (5.5.2650.21)

I have been looking at the Delta CRL section of 2459 as well as the latest
X.509 FPDAM, and have a number of issues. So the mail threads don't get
confusing, I will try to confine each mail to a single topic.
To implement Delta CRL's, you would need to add a mechanism to 2459 as to
how\where a client finds a delta CRL. The PDAM defines two mechanisms, one
of which (Freshest CRL) has the same ASN as an existing 2459 extension
(CDP). I propose we include the Freshest CRL in the revised 2459 as the
method to defining the Delta CRL distribution point. This extension could be
used in both the certificate and the CRL itself. My view is that we should
recommend that the extension be used in the CRL itself and that the
extension should only contain the list of general names i.e. no other
qualifiers. This gives a very simple relationship between the base and delta
CRL. If you have already partitioned the base CRL, I don't see much
advantage in partitioning the delta as well.
Trevor


Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA28190 for <[e-mail]>; Wed, 29 Sep 1999 09:12:43 -0700 (PDT)
Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id MAA13385 for <[e-mail]>; Wed, 29 Sep 1999 12:14:09 GMT
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2448.0) id <S3P2XFNC>; Wed, 29 Sep 1999 09:13:27 -0700
Message-ID: <[e-mail]>
From: "Evans, Jason W" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: 
Date: Wed, 29 Sep 1999 09:13:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

subscribe
end

Jason W. Evans
Principal Software Engineer

Intel Corporation
Network Systems Division
28 Crosby Drive
Bedford, MA  01730-1437


Tel:       [phone]
FAX:      [phone]

E-mail:  [e-mail]



Received: from mystic.trustcenter.de (mystic.trustcenter.de [194.64.226.89]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA27564 for <[e-mail]>; Wed, 29 Sep 1999 08:31:25 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 29 Sep 1999 17:29:05 +0200
From: Peter Biltzinger <[e-mail]>
Organization: TC TrustCenter for Security in Data Networks GmbH
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: CMP-polling
References: <006d01bf0925$64c64aa0$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDE24BD69253CA916A504D07D"

This is a cryptographically signed message in MIME format.

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

Dear Amit,

thanks for your mail.

Couldn't it be possible to start a denial-of-service attack
when using the current polling mechanism without SSL? Aren't
the following protocols conceivable?

a)

1. The RA sends a signed pkiMsg to the CA and the CA sends
   a unsigned pollRep to the RA.

2. The Attacker snoops the pollingReferenceNumber and
   sends the unsigned pollReq to the CA (before the RA
   does this) and the CA sends the signed pkiMsg or
   the unsigned pollRep (with new pollingReferenceNumber)
   to the attacker.

   In the case of sending a new pollingReferenceNumber by the
   CA the RA never gets this number and cannot send a pollReq
   which includes this new number in order to get the
   certificates. The communication between RA and CA is interrupt.
   In the case of sending a signed pkiMsg by the CA to the
   attacker the CA couldn't recognize the attack until
   the CA administrator is missing the PKIConfirmation.
   In both cases manual activity would be necessary to
   recognize and handle this attack.

b) Even worse, if the man in the middle intercepts a RA-pollReq,
   he would get the signed CA-pkiMsg and could forward a
   new unsigned CA-pollRep with a new pollingReferenceNumber
   and a new 'time-to-ckeck-back' parameter to the RA.
   Both parties (RA and CA) would be satisfied until the
   CA administrator is missing the PKIConfirmation. Again,
   manual activity would be necessary to recognize and handle
   this attack.

c) The attacker sends unsigned pollReq with snooped
   old pollingReferenceNumbers or with random numbers to
   the CA and the CA sends signed pkiMsg or unsigned
   pollRep to the attacker. In the case of a hard attack
   of this kind the CA can be overloaded which is equal
   to a denial-of-service attack. (A signed pollReq would have
   the advantage, that the verification of the RSA signature
   is very much faster than the generation of the
   RSA signature regarding the CA-pkiMsg to be generated
   and perhaps to be encrypted.)
   Nevertheless, in the case of signed pollReq (PKIMessages which
   should contain the pollingReferenceNumber) the attacker can
   snoop a signed RA-pollReq and send this one to the CA. But in
   this case, the CA can verify the recipNonce in this kind of
   PKIMessage and would be able to recognize a replay attack.

Are these attacks not conceivable?

Regards,

         Peter


--
Peter Biltzinger                      mailto:[e-mail]
TC TrustCenter                         http://www.trustcenter.de
for Security in Data Networks GmbH     Phone: [phone]
Am Werder 1, 22073 Hamburg, Germany    Fax:   [phone]
--


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

MIIFjAYJKoZIhvcNAQcCoIIFfTCCBXkCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
A3YwggNyMIIC26ADAgECAgMB87YwDQYJKoZIhvcNAQEEBQAwgbwxCzAJBgNVBAYTAkRFMRAw
DgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVzdENl
bnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBU
cnVzdENlbnRlciBDbGFzcyAzIENBMSkwJwYJKoZIhvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVz
dGNlbnRlci5kZTAeFw05OTAzMjkxMzI4MzZaFw0wMDAzMjgxMzI4MzZaMHoxCzAJBgNVBAYT
AkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMR0wGwYDVQQDExREci4g
UGV0ZXIgQmlsdHppbmdlcjEoMCYGCSqGSIb3DQEJARYZYmlsdHppbmdlckB0cnVzdGNlbnRl
ci5kZTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC1d3+m63a2oLTklvmyIPKB5XkkvD9pDBTl
gS9E2iyeYX2Fp1DrpLLxP/6PXzZEChor3OSLFuK3DSOH/i9T9dsTAgMBAAGjggEFMIIBATBH
BglghkgBhvhCAQMEOhY4aHR0cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVj
ay1yZXYuY2dpLzAxRjNCNj8wPAYJYIZIAYb4QgEHBC8WLWh0dHBzOi8vd3d3LnRydXN0Y2Vu
dGVyLmRlL2NnaS1iaW4vUmVuZXcuY2dpPzA+BglghkgBhvhCAQgEMRYvaHR0cDovL3d3dy50
cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzL2luZGV4Lmh0bWwwJQYJYIZIAYb4QgENBBgWFlRD
IFRydXN0Q2VudGVyIENsYXNzIDMwEQYJYIZIAYb4QgEBBAQDAgCgMA0GCSqGSIb3DQEBBAUA
A4GBABwEQcJSlH7tVvqWUcYga2NVq/bgDhGUxftFvCSSZcaBGDy1X4wyKcWNoof5lKKhkOy4
9oMuV9EmWX0UVyUnlwSGpz7PzbtoukbZgOfj4h3kyQkMgpVHVj2NkVzvzHj4AIkP6AEP+Xpv
q/md7e3hKInG3RooximeyVTJ2dcaumNkMYIB3jCCAdoCAQEwgcQwgbwxCzAJBgNVBAYTAkRF
MRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVz
dENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlU
QyBUcnVzdENlbnRlciBDbGFzcyAzIENBMSkwJwYJKoZIhvcNAQkBFhpjZXJ0aWZpY2F0ZUB0
cnVzdGNlbnRlci5kZQIDAfO2MAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkwOTI5MTUyOTA2WjAjBgkqhkiG9w0BCQQxFgQUFFNs
7gsuzpbQKYafNCgqqzCOX/MwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG
9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZI
hvcNAQEBBQAEQKl/bFF1vavWkuXfpCbN0Nd01Hq/kGRLgoy6PCSiD9FS0e5jvluZq+zCe4Tg
2Y+CAJlogUEt0aFZzv2hJgwEA1A=
--------------msDE24BD69253CA916A504D07D--



Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA26833 for <[e-mail]>; Wed, 29 Sep 1999 08:00:15 -0700 (PDT)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA23101 for <[e-mail]>; Wed, 29 Sep 1999 08:01:03 -0700 (PDT)
Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA08081; Wed, 29 Sep 1999 11:00:59 -0400 (EDT)
Received: from sun.com (bubinga [129.148.75.129]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id LAA24872; Wed, 29 Sep 1999 11:00:55 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 29 Sep 1999 11:00:50 -0400
From: Sean Mullan <[e-mail]>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Storage of ARLs in directory
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

RFC2587 (LDAPv2 Schema) notes that "the authorityRevocationList
attribute, if present in a particular CA's entry, includes 
revocation information regarding certificates issued to other CAs."

However, just above that it notes that "The certificateRevocationList
attribute, if present in a particular CA's entry, contains CRL(s)
as defined in RFC 2459."

CRLs as defined in RFC 2459 can be created to contain only
revocation information regarding certificates issued to other CAs.
Does this imply that a CA MAY then choose to store an ARL in
either the authorityRevocationList attribute or the 
certificateRevocationList attribute? 

Furthermore, how does a client know which attribute the CA 
stored the ARL in? Must it check both attributes to be sure?

Thanks for any clarification.
--Sean


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id CAA21366; Wed, 29 Sep 1999 02:41:09 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id JAA16424; Mon, 27 Sep 1999 09:56:34 +0200
Message-ID: <[e-mail]>
Date: Mon, 27 Sep 1999 09:56:16 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: S-MIME / IETF <[e-mail]>, IETF-PXIX <[e-mail]>, [e-mail]
Subject: Call for Comments on draft ETSI Electronic Signature Standard
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Call for Comments on draft ETSI Electronic Signature Standard

Note: This message is posted to the following IETF mailing lists:

PKIX: [e-mail]
S-MIME: [e-mail]
XML DIG-SIG: [e-mail]

If you subscribed to these mailing lists, you will receive the
message for each of them. Sorry for the inconvenience.

ETSI has issued the draft "Electronic signature standardisation 
for business transactions", ETSI ES 201 733 for a last round of 
comments, before asking its members to vote on the document.

The draft standard (108 pages - 428 ko) is available from:
http://docbox.etsi.org/tech-org/security/open/el-sign/Draft_ES_201733_v-1-1-3.pdf

The document has been developed by the ETSI SEC working group on
Electronic Signature and Infrastructures, as part of the European
Electronic Signature Standardisation Initiative (EESSI). It is
issued as a draft ETSI standard for a last round of comments. 

Scope and contents of the draft

The aim of the document is to provide specifications so as to allow
for full compatibility of secure business transactions with regard
to electronic signatures. It covers all types of business
transactions, between an individual and a company, between two
companies, between an individual and a governmental body, etc...
Being independent of any platform, it can be applied to any
environment, such as smart cards, GSM SIM cards, etc.

Business actors, using different products, will be able to complete
secure transactions by relying on the standard in order to create,
read, interpret and validate electronic signatures. The standard
offers simple and more advanced forms of signatures according to the
signature policy, the latter in order to meet requirements of
long-term validity.

The document defines:

· Formats for various forms of Electronic Signatures,
· An experimental format for Signature Policies.

The format of Electronic Signatures uses the existing Cryptographic
Message Syntax (CMS), as defined in RFC 2630, and Enhanced Security
Services (ESS), as defined in RFC 2634. It uses signed and unsigned
attributes defined in CMS, ESS and the present document. 

The signature policy is a set of rules for the creation and
validation of an electronic signature, under which the signature can
be determined to be valid. It may be defined in free text or using
formal syntax and semantic. In the first case the validation of an
Electronic Signature may be done using a specific validation box
that must conform to the description of the signature policy while
in the second case the validation may be done using a generic
validation box able to process any signature policy. 

Informative annexes describe:

· an example structured content,
· the relationship between the present document and the European 
  draft directive on electronic signature and associated 
  standardisation initiatives,
· APIs to support the generation and the verification of 
  electronic signatures,
· Cryptographic algorithms that may be used,
· Guidance on naming.

In order to get a broader feedback from the technical and business
communities ETSI has chosen to place the document in the public
domain for comments rather than to limit it to its membership. 

Comments are welcome until October 31, 1999. After processing the
comments the document will be placed on vote to become an ETSI
standard, with the future option to seek acceptance by other
standard bodies.

Comments may be sent to the EL-SIGN mailing list.
Before sending a message to the list, you need to subcribe
to that mailing list: copy and paste the following command 
in the body of a message:

SUBSCRIBE EL-SIGN (First and Last name)
replace "first and last name" with your name and send it to:
[e-mail]

Then you may send a message to the list at : [e-mail]

Mail archive are available at: http://list.etsi.fr/el-sign.html

The web page from ETSI on Electronic Signature (ES) Standardisation
is: http://www.etsi.org/sec/el-sign.htm

About ETSI SEC

ETSI SEC is the technical body within ETSI carrying the main
responsibility for security infrastructures and services in the
telecom environment. As such, ETSI SEC devotes special interest to
interoperability issues at the communication and transaction levels
as well as to relevant aspects of trust relationships. One of the
ETSI SEC working groups, the Electronic Signature and
Infrastructures (ESI) WG is in charge of present and future ETSI
activities related to the EESSI work program.


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA03045 for <[e-mail]>; Tue, 28 Sep 1999 16:42:01 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id QAA23481; Tue, 28 Sep 1999 16:42:47 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id QAA07336; Tue, 28 Sep 1999 16:42:45 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Salz, Rich'" <[e-mail]>, <[e-mail]>
Subject: RE: Huge CRLs
Date: Tue, 28 Sep 1999 16:46:18 -0700
Message-ID: <009601bf0a0b$a9822560$[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]>

Hi Rich,
    Yes, you could, but the original topic was, Huge CRLs, so I
think size is very much the issue here! Remember - the assertion
was about CRTs being more secure and more scalable than OCSP. You
can always use CRLs if they meet your needs - don't really need
OCSP to support that.

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: Salz, Rich [mailto:[e-mail]]
> Sent: Tuesday, September 28, 1999 7:09 AM
> To: 'Ambarish Malpani'; [e-mail]
> Subject: RE: Huge CRLs
> 
> 
> >In short, when you get an OCSP request, you set the response-type
> >as a CRT based response and then include the CRT slice in the
> >response. This means that you don't sign the specific response,
> >so the creator of the CRT and the provider of the response can
> >be different entities - one with a private key (to sign the CRT)
> >and the other without any private key (since it is just doling
> >out responses based on a trusted CRT).
> 
> Thanks very much, it does.  Now, I can just replace "crt" with "crl"
> above and get the exact same security feature, right?  (Granted the
> CRT is smaller than the CRL, but that's not what the issue here.)
> 
> 	/r$
> 


Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA27495 for <[e-mail]>; Tue, 28 Sep 1999 07:08:39 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 70FBC15533; Tue, 28 Sep 1999 10:08:47 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id E43927C051; Tue, 28 Sep 1999 10:08:46 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2232.9) id <TX297TSL>; Tue, 28 Sep 1999 10:08:47 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, [e-mail]
Subject: RE: Huge CRLs
Date: Tue, 28 Sep 1999 10:08:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

>In short, when you get an OCSP request, you set the response-type
>as a CRT based response and then include the CRT slice in the
>response. This means that you don't sign the specific response,
>so the creator of the CRT and the provider of the response can
>be different entities - one with a private key (to sign the CRT)
>and the other without any private key (since it is just doling
>out responses based on a trusted CRT).

Thanks very much, it does.  Now, I can just replace "crt" with "crl"
above and get the exact same security feature, right?  (Granted the
CRT is smaller than the CRL, but that's not what the issue here.)

	/r$


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA22959 for <[e-mail]>; Tue, 28 Sep 1999 03:08:32 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id MAA14980 for <[e-mail]>; Tue, 28 Sep 1999 12:08:57 +0200
Message-ID: <[e-mail]>
Date: Tue, 28 Sep 1999 12:08:37 +0100
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: Call for Comments on draft ETSI Electronic Signature Standard
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Call for Comments on draft ETSI Electronic Signature Standard

Note: This message is posted to the following IETF mailing lists:

PKIX: [e-mail]
S-MIME: [e-mail]
XML DIG-SIG: [e-mail]

If you subscribed to these mailing lists, you will receive the
message for each of them. Sorry for the inconvenience.

ETSI has issued the draft "Electronic signature standardisation for
business transactions", ETSI ES 201 733 for a last round of
comments, before asking its members to vote on the document.

The draft standard (108 pages - 428 ko) is available from:
http://docbox.etsi.org/tech-org/security/open/el-sign/Draft_ES_201733_v-1-1-3.pdf

The document has been developed by the ETSI SEC working group on
Electronic Signature and Infrastructures, as part of the European
Electronic Signature Standardisation Initiative (EESSI). It is
issued as a draft ETSI standard for a last round of comments. 

Scope and contents of the draft

The aim of the document is to provide specifications so as to allow
for full compatibility of secure business transactions with regard
to electronic signatures. It covers all types of business
transactions, between an individual and a company, between two
companies, between an individual and a governmental body, etc...
Being independent of any platform, it can be applied to any
environment, such as smart cards, GSM SIM cards, etc.

Business actors, using different products, will be able to complete
secure transactions by relying on the standard in order to create,
read, interpret and validate electronic signatures. The standard
offers simple and more advanced forms of signatures according to the
signature policy, the latter in order to meet requirements of
long-term validity.

The document defines:

· Formats for various forms of Electronic Signatures,
· An experimental format for Signature Policies.

The format of Electronic Signatures uses the existing Cryptographic
Message Syntax (CMS), as defined in RFC 2630, and Enhanced Security
Services (ESS), as defined in RFC 2634. It uses signed and unsigned
attributes defined in CMS, ESS and the present document. 

The signature policy is a set of rules for the creation and
validation of an electronic signature, under which the signature can
be determined to be valid. It may be defined in free text or using
formal syntax and semantic. In the first case the validation of an
Electronic Signature may be done using a specific validation box
that must conform to the description of the signature policy while
in the second case the validation may be done using a generic
validation box able to process any signature policy. 

Informative annexes describe:

· an example structured content,
· the relationship between the present document and the European
draft directive on electronic signature and associated
standardisation initiatives,
· APIs to support the generation and the verification of electronic
signatures,
· Cryptographic algorithms that may be used,
· Guidance on naming.

In order to get a broader feedback from the technical and business
communities ETSI has chosen to place the document in the public
domain for comments rather than to limit it to its membership. 

Comments are welcome until October 31, 1999. After processing the
comments the document will be placed on vote to become an ETSI
standard, with the future option to seek acceptance by other
standard bodies.

Comments may be sent to the EL-SIGN mailing list.
Before sending a message to the list, you need to subcribe
to that mailing list: copy and paste the following command 
in the body of a message:

SUBSCRIBE EL-SIGN (First and Last name)
replace "first and last name" with your name and send it to:
[e-mail]

Then you may send a message to the list at : [e-mail]

Mail archive are available at: http://list.etsi.fr/el-sign.html

The web page from ETSI on Electronic Signature (ES) Standardisation
is:
http://www.etsi.org/sec/el-sign.htm

About ETSI SEC

ETSI SEC is the technical body within ETSI carrying the main
responsibility for security infrastructures and services in the
telecom environment. As such, ETSI SEC devotes special interest to
interoperability issues at the communication and transaction levels
as well as to relevant aspects of trust relationships. One of the
ETSI SEC working groups, the Electronic Signature and
Infrastructures (ESI) WG is in charge of present and future ETSI
activities related to the EESSI work program.


Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA08263 for <[e-mail]>; Mon, 27 Sep 1999 13:18:31 -0700 (PDT)
Received: from mobile (mobile [192.168.42.7]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id NAA29949; Mon, 27 Sep 1999 13:19:05 -0700
From: "Amit Kapoor" <[e-mail]>
To: "Peter Biltzinger" <[e-mail]>, <[e-mail]>
Subject: RE: CMP-polling
Date: Mon, 27 Sep 1999 13:17:59 -0700
MIME-Version: 1.0
Message-ID: <006d01bf0925$64c64aa0$[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0068_01BF08EA.B7E26420"
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

This is a multi-part message in MIME format.

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

Hi Peter,

>
> Regarding the  RFC 2510 (CMP) arises a question on the
> polling-mechanism. As I understand the RFC 2510, there
> is no possibility to sign the TCP/IP messages, which contain
> the pollingReferenceNumbers - special the polling-request (pollReq).

	Please take a look at the draft CMP-over-TCP as there
	have been some changes due to interoperablility testing
	done by some implementors.

>
> The consequence of this polling-mechanism is that an attacker
> can send pollinReferenceNumbers (with random numbers or systematically)
> to the CA in order to get informations of the CA/RA customer. This is a
> problem in the context of closed user-groups and in the context of
customers,
> who have certificates, which are public for downloading but general are
> non-public. Furthermore it is possible to interrupt the CMP-protocol
between RA and
> CA. 32-bit polling-numbers are not really protect the RA/CA from this
> attacks.

	A closed-group CA can be shutout from the outside poll requests.

	A open/general CA issuing non-public certificates in the open
	has the general problem that the clear data can be snooped.  So
	you would have to encrypt the channel itself and that is different
	from having a signed poll request.  You have the choice of SSL or
	CMC etc. for that.  Would this work?

	In the case of a open/general CA, the the attacker can
	get the response to a certificate request, but it still needs
	to send a signed confirm/reject to change the state on the
	server side.  But this does bring up a good point and that
	is the CA/RA should not change the state of the request on
	pollReq and only on signed PKI messages.  We will add this
	clarification to the draft protocol document.

	regards

Amit

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIID1DCCA9Aw
ggM7oAMCAQICFEQ41iugpRpD1VzRmFQZQnkJUk6OMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1T
TWVtZSBSb290IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwNjI4MDAzMDE3
WhcNMDQwNjI4MDAzMDE3WjBPMRMwEQYDVQQKEwpUcnVzdHBvaW50MRQwEgYDVQQDEwtBbWl0IEth
cG9vcjEiMCAGCSqGSIb3DQEJARYTYW1pdEB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAs/M5RIk9+UTqdrpG/UaFOjxTfCs7S9kCJtHroRgDS3Ss+eKt+Re+6NLnxm3S
+pszODOrglLwn19+Zbp3yeVXMsaYLy9+9Jwcm0l+wQGDk8Kh8xUA1MQssVaW9rWamtAvQY+Mje4S
HBjXayCIPyIMJ29Ypk49P1vKbuqgLB/ZQFECAwEAAaOCAcUwggHBMB0GA1UdDgQWBBRo1B8wQ8Kj
E90aF8xiyBKsdXMc3zAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB
/wQEAwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG
+EIBAQQEAwIAsDAeBgNVHREEFzAVgRNhbWl0QHRydXN0cG9pbnQuY29tME8GA1UdIARIMEYwRAYI
KwYEAZhUHgEwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5zbWVtZS5jb20vc2VydmljZWFncmVl
bWVudC5odG1sMEMGCWCGSAGG+EIBAwQ2FjRodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0cy9z
bWVtZV9jYS9jaGVja19yZXZva2VkMEAGCWCGSAGG+EIBBwQzFjFodHRwOi8vd3d3LnNtZW1lLmNv
bS9zZXJ2bGV0cy9zbWVtZV9jYS9yZW5ld19jZXJ0MDkGCWCGSAGG+EIBCAQsFipodHRwOi8vd3d3
LnNtZW1lLmNvbS9zZXJ2aWNlYWdyZWVtZW50Lmh0bWwwCwYJKoZIhvcNAQEFA4GBAFS76N1D2ogo
AEAUBV8b6/skJBuju82MnaKh9RlJ7elFikwwPGe9SEblPtbp/+QbDtAVIiwmOIE1XPEZi0cWfLTi
P8pa0BRBl5H419aoIfeoZTsZz4R7E7eGd7rsK37dyBzKbnqio2nzJNhx7FJJDkA7VajJbhk8tdkW
RL6IjymQMYIB/TCCAfkCAQEwTTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT
TWVtZTELMAkGA1UEBhMCVVMCFEQ41iugpRpD1VzRmFQZQnkJUk6OMAkGBSsOAwIaBQCgggEGMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MDkyNzIwMTc1OVowIwYJ
KoZIhvcNAQkEMRYEFGTwLHqwqGuIHL0hKEyjyxWjj2xUMEkGCSqGSIb3DQEJDzE8MDowCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcGBSsOAwIaMAoGCCqGSIb3DQIFMFwGCSsG
AQQBgjcQBDFPME0wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJ
BgNVBAYTAlVTAhREONYroKUaQ9Vc0ZhUGUJ5CVJOjjANBgkqhkiG9w0BAQEFAASBgDsX3mGpVwFe
7wvSnOr2gFnTejuo4nOsYb4kv30qaQIv5mtHxc1Poc05V9QFDFCW9ktPXBvDEFQWaOTmHmuyVgzw
b5NluzhNdpsycSxPvXLtMlBSQVOhzbiR5o0kZd4UznD/TERH5zFCzg9JgOTHfeEtE2YvkVM2Yizv
S5dOzeSYAAAAAAAA

------=_NextPart_000_0068_01BF08EA.B7E26420--



Received: from mystic.trustcenter.de (mystic.trustcenter.de [194.64.226.89]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA04078 for <[e-mail]>; Mon, 27 Sep 1999 06:36:56 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 27 Sep 1999 15:34:21 +0200
From: Peter Biltzinger <[e-mail]>
Organization: TC TrustCenter for Security in Data Networks GmbH
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: CMP-polling
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msFAAB3920A0AD3CCFDCA338BB"

This is a cryptographically signed message in MIME format.

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

Regarding the  RFC 2510 (CMP) arises a question on the
polling-mechanism. As I understand the RFC 2510, there
is no possibility to sign the TCP/IP messages, which contain
the pollingReferenceNumbers - special the polling-request (pollReq).

The consequence of this polling-mechanism is that an attacker
can send pollinReferenceNumbers (with random numbers or systematically)
to the CA in order to get informations of the CA/RA customer. This is a
problem
in the context of closed user-groups and in the context of customers,
who have
certificates, which are public for downloading but general are
non-public.
Furthermore it is possible to interrupt the CMP-protocol between RA and
CA.
32-bit polling-numbers are not really protect the RA/CA from this
attacks.

Are there any mechanisms regarding the RFC 2510 to authenticate the
polling-requests, pollReq, (apart from a SSL-connection), or should
the RFC 2510 be modified in this point, perhaps by introducing a new
type
of  DER-encoded, signed CMP-Message (CMP-Polling-Requst)
to send the polling-request?

Regards,
                     Peter

--
Dr. Peter Biltzinger                   mailto:[e-mail]
TC TrustCenter                         http://www.trustcenter.de
for Security in Data Networks GmbH     Phone: [phone]
Am Werder 1, 22073 Hamburg, Germany    Fax:   [phone]
--


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

MIIFjAYJKoZIhvcNAQcCoIIFfTCCBXkCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
A3YwggNyMIIC26ADAgECAgMB87YwDQYJKoZIhvcNAQEEBQAwgbwxCzAJBgNVBAYTAkRFMRAw
DgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVzdENl
bnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBU
cnVzdENlbnRlciBDbGFzcyAzIENBMSkwJwYJKoZIhvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVz
dGNlbnRlci5kZTAeFw05OTAzMjkxMzI4MzZaFw0wMDAzMjgxMzI4MzZaMHoxCzAJBgNVBAYT
AkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMR0wGwYDVQQDExREci4g
UGV0ZXIgQmlsdHppbmdlcjEoMCYGCSqGSIb3DQEJARYZYmlsdHppbmdlckB0cnVzdGNlbnRl
ci5kZTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC1d3+m63a2oLTklvmyIPKB5XkkvD9pDBTl
gS9E2iyeYX2Fp1DrpLLxP/6PXzZEChor3OSLFuK3DSOH/i9T9dsTAgMBAAGjggEFMIIBATBH
BglghkgBhvhCAQMEOhY4aHR0cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVj
ay1yZXYuY2dpLzAxRjNCNj8wPAYJYIZIAYb4QgEHBC8WLWh0dHBzOi8vd3d3LnRydXN0Y2Vu
dGVyLmRlL2NnaS1iaW4vUmVuZXcuY2dpPzA+BglghkgBhvhCAQgEMRYvaHR0cDovL3d3dy50
cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzL2luZGV4Lmh0bWwwJQYJYIZIAYb4QgENBBgWFlRD
IFRydXN0Q2VudGVyIENsYXNzIDMwEQYJYIZIAYb4QgEBBAQDAgCgMA0GCSqGSIb3DQEBBAUA
A4GBABwEQcJSlH7tVvqWUcYga2NVq/bgDhGUxftFvCSSZcaBGDy1X4wyKcWNoof5lKKhkOy4
9oMuV9EmWX0UVyUnlwSGpz7PzbtoukbZgOfj4h3kyQkMgpVHVj2NkVzvzHj4AIkP6AEP+Xpv
q/md7e3hKInG3RooximeyVTJ2dcaumNkMYIB3jCCAdoCAQEwgcQwgbwxCzAJBgNVBAYTAkRF
MRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVz
dENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlU
QyBUcnVzdENlbnRlciBDbGFzcyAzIENBMSkwJwYJKoZIhvcNAQkBFhpjZXJ0aWZpY2F0ZUB0
cnVzdGNlbnRlci5kZQIDAfO2MAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkwOTI3MTMzNDIyWjAjBgkqhkiG9w0BCQQxFgQUuRFA
1Nj5UmT6tMvyKtZ16btGmoMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG
9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZI
hvcNAQEBBQAEQEsCELsPoXydplv6l3EYR+i5/ZX/EhQOuyt+Vxm563Y3uPMIXDbtFgdKenqe
VGTF+RhctKtaFC6XGIfU33+dKp0=
--------------msFAAB3920A0AD3CCFDCA338BB--



Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id VAA24298 for <[e-mail]>; Sun, 26 Sep 1999 21:28:46 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id OAA22121 for <[e-mail]>; Mon, 27 Sep 1999 14:28:52 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd083ngE; Mon Sep 27 14:28:34 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id OAA11384 for <[e-mail]>; Mon, 27 Sep 1999 14:28:33 +1000 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd43.XV_; Mon Sep 27 14:27:47 1999
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA25981 for <[e-mail]>; Mon, 27 Sep 1999 14:27:46 +1000 (EST)
Message-Id: <[e-mail]>
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <TQX3PM7S>; Mon, 27 Sep 1999 14:25:57 +1000
From: "Manger, James" <[e-mail]>
To: [e-mail], "Manger, James" <[e-mail]>
Subject: Timestamp: 03: extensions
Date: Mon, 27 Sep 1999 14:26:00 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF08A0.630D5170"

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_01BF08A0.630D5170
Content-Type: text/plain

Use Attribute, instead of Extension, to offer extensibility in the timestamp
token.
334c334
<      extensions                   [4] EXPLICIT Extensions OPTIONAL
---
>      attributes                   [4] SEQUENCE OF Attribute OPTIONAL


The PKIX community are familiar with the Extension type from dealing with
Certificate & CertificateList values, but are even more familiar with
Attribute from dealing with Name & CertificationRequest (PKCS#10) values,
the [un]authenticatedAttributes field of PKCS#7 [CMS] signed values and
other items.

A certificate can be quite a sophisticated trust statement.  It also deals
with complex issues such as naming & identity.  Consequently, an extension
can change the meaning of another field and the criticality feature is
required to indicate when this occurs.  A timestamp, on the other hand, has
one simple meaning - "this token was created at this time".  I doubt this
meaning can be altered by an extension so a critical flag per extension is
not required.  Note: a semantics identifier provides functionality like a
critical bit (& more) [See earlier e-mail titled "Timestamp: 03: semantic id
instead of version number"].

If Extension is retained, there needs to a description of what to do when an
unrecognized extension is marked critical.  A certificate with such a value
must be rejected.  A CRL with such a value is still useful but may be
incomplete (a certificate on the list should still be treated as revoked).
A timestamp with such a value ???.  Presumably the time field still
indicates when the token was created so the token still has some value (i.e.
"reject on unrecognized critical extension" is too harsh).


------_=_NextPart_000_01BF08A0.630D5170
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IjoEAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAaAAAAVGltZXN0YW1wOiAwMzogZXh0ZW5zaW9ucwAbCQEJ
gAEAIQAAAEY5QURDRDE2NkM3NEQzMTFCRDI1MDAxMDRCMDhEQkYxADgHASCAAwAOAAAAzwcJABsA
DgAZADUAAQBXAQEFgAMADgAAAM8HCQAbAA4AGgAAAAEAIwEBDYAEAAIAAAACAAIAAQOQBgDwBwAA
HQAAAAMALgAAAAAAQAA5AOB68magCL8BHgBwAAEAAAA+AAAAdGltZS1zdGFtcC0wMzogaW50ZXJh
Y3Rpb24gb2YgVFNUVGltZSBhbmQgc2VyaWFsTnVtYmVyIHZhbHVlcwAAAAIBcQABAAAAIAAAAAG/
BT8t+oSyAchxLRHTrlcACMckrdIAzzlv0wAFs4nYAgEJEAEAAACoBAAApAQAAOcHAABMWkZ1Yju7
KAMACgByY3BnMTI1/jIA/wIGAqQD5AXrAoMAUBMDVAIAY2gKwHNldP4yBgAGwwKDDlAD1QcTAoMy
MxPPZjQDxQIAcHJCcRLic3RlbQKAfX8KgAjPCdkCgAqBDnELYG5QZzMwOABQaAWweqhkb2MAACoS
VSACkT0bEGwbRQr7FOIB0CBVTxKwFDACQAUQYnUXMCwGIAuAFyFhZCBvZnggRXgXMACBAiAegHRK
bx8RZgSQIGUfZGKxAxBpdHkekR/waB3QpnQHcgGQbXAf8WsJ8MIuCoUzMzRjI1EKhXw8ICRDIJUC
IAQgJU8gCFs0XR9AWFBMSRhDSVQfSAQgT1BUoElPTkFMCoUtKOB1CoU+JERhHgYlPyZFU4BFUVVF
TkNFJ+AuRh3oJ+4t7FQhsVBLiElYIAWgbW11AwD3IUEKwB3QZiJAIREKwQPwzyGgIZMfVx/weXAw
gQNhriAOcAdAC4BnMSRDBJBdIeBmDeAp8B3QJjPKTNsEAAVAdgdAClBzHoAeQekwU2V2CfAgBGAw
fyzIHzK/B7AiQDR8H7FSZXELNeEFQCgvcENTIzEsMCk1pyGiWzAAXWHvHlAhsAIwNDNkHfcEIDQg
rGVsHwM7wzcmYEMF4HMmkACQZ24JgDWlKeBu3x8BIaEFwCEwF0BzItYKhd5BL7Az6TRAA6BiHdA7
UMdBsSngQCBvcGg1cT3EeR/wcnU1gSIhFzE9kS71JEBJNlFsRMAy8wQgMTP/L8ELUCCQHpAEEEDS
SJAScLsp4AQgbjCxM1E0kGkOcH89oSFARpEIUACAO0ICMGz+eR6AA5Ekp0PDEnEaECHB/yGxB4AA
cDNCHyEAcEFUPtT/QRIhogUBPbIhIyBQKfAIcPsd0AQAIBhgREEYYR/yC4B6ZDQ0dz2BIZFQkRrQ
Y/8IcEHwJEBC8CHnHoAyMiGx+0FUTKFkHoASgFKRQGBAIeNIEk03LSAiUmMigzEgf0kxBQBQIUBx
KfBSVCHiIvdGkjLwCGBiWGVNRkPVB0D7FzBREmIwQUuaRxFEoE9W/zCQC2AzYDKAIHcyMVCRTgHL
ULdGkU5BUGU6RJIXQH8AcD2xBCBJ9D7RBcAWsG/udknxPrEwAGM68k+0ISB/IqBcuiEAO5E0kDcC
PDBb3wZgNpEKwCEgIGItAMADEXdKMUgwHwAiB2MiMmAAMP4zYABgRknhHpo2wBKgMiJMbnUG0ASQ
Il1CDUn/HzlQhAGQC4AJgDyzNyFAYP8JgFcSRJFh4QUDMiIfIVIQ/1hSRyEgEFITA5EwABhgBaC5
QFBpekBxXgsAwHIioP8fAE9WUxNDGjEzSOQ1pDbwd0XCRBEYYGoFkD3xUxND3FJMc09Qc0URbAMg
RcD9DoB1Y+E2QQDAIVBEEQuA+0f0LTEoXMEz6VQVISBF0v8agHfwHwB3VEQRHhBX9VCicnYikWQp
Uxx1/x3QP/t/cEaRUBhgSJAAwAJgIVD/IaY+xXdUUYZHgVIkIcFXT39HEYLId1RVQkTAOhF0FCjo
aS5lRpAidPRUAm+7e1znJKciUIIgACAQEoJoF31QLewXgQCLYAMA/T9SAwAAAwAmAAAAAAADADYA
AAAAAB4AMUABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwADABpAAAAAAB4AMEABAAAAEAAAAEpNQU5H
RVIyOTI4OEVGMwADABlAAAAAAAIB+T8BAAAAZwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAYA
AAAvTz1URUxTVFJBL09VPVFMRCBLSU5HU0ZPUkQtU01JVEgvQ049TVMgTUFJTCBSRUNJUElFTlRT
L0NOPUpNQU5HRVIyOTI4OEVGMwAAHgD4PwEAAAAOAAAATWFuZ2VyLCBKYW1lcwAAAB4AOEABAAAA
EAAAAEpNQU5HRVIyOTI4OEVGMwACAfs/AQAAAGcAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAG
AAAAL089VEVMU1RSQS9PVT1RTEQgS0lOR1NGT1JELVNNSVRIL0NOPU1TIE1BSUwgUkVDSVBJRU5U
Uy9DTj1KTUFOR0VSMjkyODhFRjMAAB4A+j8BAAAADgAAAE1hbmdlciwgSmFtZXMAAAAeADlAAQAA
ABAAAABKTUFOR0VSMjkyODhFRjMAQAAHMEDM3eGSCL8BQAAIMHBRDWOgCL8BHgA9AAEAAAABAAAA
AAAAAB4AHQ4BAAAAGgAAAFRpbWVzdGFtcDogMDM6IGV4dGVuc2lvbnMAAAALACkAAAAAAAsAIwAA
AAAAAwAGEIuAq4wDAAcQMQUAAAMAEBAAAAAAAwAREAEAAAAeAAgQAQAAAGUAAABVU0VBVFRSSUJV
VEUsSU5TVEVBRE9GRVhURU5TSU9OLFRPT0ZGRVJFWFRFTlNJQklMSVRZSU5USEVUSU1FU1RBTVBU
T0tFTjMzNEMzMzQ8RVhURU5TSU9OUzRFWFBMSUNJVEVYAAAAAMxE

------_=_NextPart_000_01BF08A0.630D5170--


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id TAA20634 for <[e-mail]>; Sun, 26 Sep 1999 19:48:48 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA04913 for <[e-mail]>; Mon, 27 Sep 1999 12:48:52 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0u1_B6; Mon Sep 27 12:48:46 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA14075 for <[e-mail]>; Mon, 27 Sep 1999 12:48:45 +1000 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0T13bF; Mon Sep 27 12:48:07 1999
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA27090 for <[e-mail]>; Mon, 27 Sep 1999 12:48:07 +1000 (EST)
Message-Id: <[e-mail]>
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <TQX330YZ>; Mon, 27 Sep 1999 12:46:17 +1000
From: "Manger, James" <[e-mail]>
To: [e-mail]
Subject: Timestamp: 03: semantic id instead of version number
Date: Mon, 27 Sep 1999 12:47:55 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF0892.78175C2C"

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_01BF0892.78175C2C
Content-Type: text/plain

Replace the version field in TSTInfo with a semantics field.
<	version	INTEGER  { v1(0) },
---
>	semantics	OBJECT IDENTIFIER (id-semantics-timestamp),

"This standard defines a timestamp token syntax and the meaning of each
field in that syntax.  The value of the semantics field identifies the
meaning of the other fields.  The meanings defined in this standard shall be
identified by id-semantics-timestamp.  Future versions of this standard may
extend the timestamp token syntax in accordance with the ASN.1 extensibility
rules (e.g. may add optional fields to the end of the TSTInfo SEQUENCE).  If
and only if the changes alter meaning of existing fields will a new
semantics id be used."

"An implementation of this version of the standard may safely ignore any
extra fields at the end of the timestamp token (though they must be included
when verifying the signature on the token) as long as the semantics field is
id-semantics-timestamp.  A timestamp token with an unknown semantics value
must be rejected."


Explicitly identifying the semantics prevents any possible misinterpretation
of the token.  It is possible that a DER-encoded timestamp could be decoded
as a value of another ASN.1 type (with a compatible arrangement of tags).
However, no value of such a type can reasonable start with the object
identifier value used in a timestamp.  This is important as the TSA signs a
message imprint but makes absolutely no statement or promise about it, i.e.
the TSA signs a message but has no intention of being bound by the content
of that message.

[A semantics field performs a role similar to the critical field of a
certificate extension.]

------_=_NextPart_000_01BF0892.78175C2C
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IhICAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQA1AAAAVGltZXN0YW1wOiAwMzogc2VtYW50aWMgaWQgaW5z
dGVhZCBvZiB2ZXJzaW9uIG51bWJlcgDYEgEJgAEAIQAAAEVGQURDRDE2NkM3NEQzMTFCRDI1MDAx
MDRCMDhEQkYxAEQHASCAAwAOAAAAzwcJABsADAAuABAAAQBFAQEFgAMADgAAAM8HCQAbAAwALwA3
AAEAbQEBDYAEAAIAAAACAAIAAQOQBgA0CAAAHgAAAAMALgAAAAAAQAA5ABA+FrOSCL8BHgBwAAEA
AAA+AAAAdGltZS1zdGFtcC0wMzogaW50ZXJhY3Rpb24gb2YgVFNUVGltZSBhbmQgc2VyaWFsTnVt
YmVyIHZhbHVlcwAAAAIBcQABAAAAGwAAAAG/BT8t+oSyAchxLRHTrlcACMckrdIAzzlv0wACAQkQ
AQAAAKIEAACeBAAABAgAAExaRnXcmtk7AwAKAHJjcGcxMjX+MgD/AgYCpAPkBesCgwBQEwNUAgBj
aArAc2V0/jIGAAbDAoMOUAPVBxMCgzIzE89mNAPFAgBwckJxEuJzdGVtAoB9fwqACM8J2QKACoEO
cQtgblBnMzA4AFBoBbB6qGRvYwAAKhJVIAKRfRsQbBtFCvsTsgHQB/BlQQtRY2UgdGgeEHYnBJAA
kAIgIGYIkGxkAiALgCBUU1RJbo0CECAD8B4wIGEgErBdA4F0DeAEIB7zLgqFPAcMgh5mIfNJTlRF
RyhFUiADMHseYDEopDApAzB9LAqFLSTAHQqFPiHzIHch809CSkhFQ1Qi8ERFIxBJhEZJI1EoaWQt
IHeOLSDAB4EBkG1wKSRGcQqFIlRoBAAgYAGQbvpkCxEgDnELgAeRIFAop1keIG9rCfAgYHkCMGF+
eCBAKsAeIweAAHALgGfwIG9mIC3AEnAe6B4w9mEFQCzELiNwKkAeUQdA/wpQLiIeMiB9H0AOcCCx
HvF3BCAtfR4ybx4xBcAe83O/L/UttQQgKyQu9SpqcxKAOmwDIGIeEDI3HzBieb8K4QtkFOIdgSff
KOMuHM3xI3BGdXQIcB5XBCAww+cqagDAOLBleBcwLUUrz98s1B9RANAFoSrQbh4BIAPBHjJBU04u
MT6EAJCOYgMQIBA4sHJ1bAeRMChlLmcv8D5SYWT9HzBvBTAesQdANGUsUR4jhz7CMMUfhlNFUVUn
MOhDRSkv8UkuQC0yAiB+bDiwBpAeIxJxGhArcmz3FzAFwC26eAQAIMAuAUU1/wPwN5EgUCtgB+Ag
eDnAN7LWdRKwIVAiKV1BA6AHcP8LUBdAMlEvYB6yPUYedjDGMT3ac2FmHxBIoWdu7wWwHhAAcD5z
ciBQRTUvYdtF3T9OKB4wCGBnQcM4sP5tTXAFQDfCQVAKQA5wHzDedx5AA6AecQaQeS3yMPN/UpEv
YDxyHsFU8yxyJABh/wQgF/AuAVrBMP8fIkzyOe87OvIjcEFVLyAEA6B1bvprUrB3LKEghzBkVwYY
YJ5qBZAXME2vCoVFeAtQfw3gIBBIkjJEWLgghxawZc8ecAIwK4FTEXBvBBBC4P9DgC2gBAALgEnR
ZlFPelo1f0fSBUAqYWcnL0MgUCcgUv4tCfAFoFfSP0gFoENwTSP/BYJX0lrBIFAwZwBwNBRCJPVD
MHAeECggBQWgKRBPgb9ncgrAU3BJYU9CMLNhNaDNR8JIYFBmcXIsTCAf4LkwZ3N1LoEroW9iYwOR
fxhgWsBE4WdyKOEAIEGIb/5iYjIyKAXAMGRNckCjXoj/L/NcskzxKRAYASChWzYfgP9ecFlCK4IH
gVIgSXBO4gUQvXFhYjxQPkEsgCuBYnTA/wpAFzBIkXLRKOEXMXFTBcD/FrADcAQAUuEG4HxxIBBy
sPxpLkPQel97ZnxiEoAEIP9y0WfiILFPtDfALfJ/QS1B/zihSPMCIXFWL1J7ZSFmCoUuW4CBMU1v
cHICEHJt/yuCA2B1EgdwAxAKwUWlBQH/IMFFBm4zSSAEkDJydFAXMLNCdgIgLl0KhReBAI0wAAAD
AP0/UgMAAB4AQhABAAAAIQAAADwzN0U5NDU4My42RjNCNTYyN0BuZXRzY2FwZS5jb20+AAAAAAMA
JgAAAAAAAwA2AAAAAAAeADFAAQAAABAAAABKTUFOR0VSMjkyODhFRjMAAwAaQAAAAAAeADBAAQAA
ABAAAABKTUFOR0VSMjkyODhFRjMAAwAZQAAAAAACAfk/AQAAAGcAAAAAAAAA3KdAyMBCEBq0uQgA
Ky/hggEAAAAGAAAAL089VEVMU1RSQS9PVT1RTEQgS0lOR1NGT1JELVNNSVRIL0NOPU1TIE1BSUwg
UkVDSVBJRU5UUy9DTj1KTUFOR0VSMjkyODhFRjMAAB4A+D8BAAAADgAAAE1hbmdlciwgSmFtZXMA
AAAeADhAAQAAABAAAABKTUFOR0VSMjkyODhFRjMAAgH7PwEAAABnAAAAAAAAANynQMjAQhAatLkI
ACsv4YIBAAAABgAAAC9PPVRFTFNUUkEvT1U9UUxEIEtJTkdTRk9SRC1TTUlUSC9DTj1NUyBNQUlM
IFJFQ0lQSUVOVFMvQ049Sk1BTkdFUjI5Mjg4RUYzAAAeAPo/AQAAAA4AAABNYW5nZXIsIEphbWVz
AAAAHgA5QAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAEAABzBAXrgTfAi/AUAACDAsXBd4kgi/AR4A
PQABAAAAAQAAAAAAAAAeAB0OAQAAADUAAABUaW1lc3RhbXA6IDAzOiBzZW1hbnRpYyBpZCBpbnN0
ZWFkIG9mIHZlcnNpb24gbnVtYmVyAAAAAAsAKQAAAAAACwAjAAAAAAADAAYQJS3aeAMABxBEBQAA
AwAQEAAAAAADABEQAgAAAB4ACBABAAAAZQAAAFJFUExBQ0VUSEVWRVJTSU9ORklFTERJTlRTVElO
Rk9XSVRIQVNFTUFOVElDU0ZJRUxEPFZFUlNJT05JTlRFR0VSVjEoMCksLS0tU0VNQU5USUNTT0JK
RUNUSURFTlRJRklFUigAAAAALFE=

------_=_NextPart_000_01BF0892.78175C2C--


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA18471 for <[e-mail]>; Fri, 24 Sep 1999 08:05:06 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhibk23546 for <[e-mail]>; Fri, 24 Sep 1999 15:09:14 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26053; Fri, 24 Sep 99 11:07:31 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA26908; Fri, 24 Sep 1999 11:09:07 -0400
Date: Fri, 24 Sep 1999 11:09:07 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
To: [e-mail]
Subject: Re: TSP version 03
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA18472

>>>>> "Ronald" == Ronald Tschalär <[e-mail]> writes:

 >> Do you agree with Paul and me that a new version number is needed
 >> only if new data cannot be properly parsed by old software?

 Ronald> No. It all depends on how negotiation you want to allow. At
 Ronald> the one end you could say "If I can't parse it I'll just
 Ronald> abort" - this doesn't "need" any versioning.

I would consider that a rather bad idea; I don't think anyone proposed 
such a rule.

 Ronald> At the other end
 Ronald> you want to fully negotiate the capabilities of each side.
 Ronald> This can be done either with version numbers, extensible
 Ronald> options, or some combination thereof. 

No.  Version numbers are not the way to "fully negotiate the
capabilities of each side".  The reason is that version numbers are
scalars, while capabilities are sets.  If you actually want to
exchange information about the capabilities of the two ends (as
opposed to simply asking for something and observing the request isn't 
granted) then you must use an encoding that expresses for each
capability whether it's supported or not.  Version numbers do NOT work 
for this.  They have been used for that in some protocols, always with 
miserable failure.

>>>>> "Rich" == Rich Salz <[e-mail]> writes:

 >> Do you agree with Paul and me that a new version number is needed
 >> only if new data cannot be properly parsed by old software?

 Rich> No.  There might be semantic changes in existing pdu's.  E.g.,
 Rich> multiple "revoke me" requests return an error or ignore replay.
 Rich> This kind of thing happens when you find that most
 Rich> implementations of a spec didn't do wghat was "obvisouly"
 Rich> intended.  E.g., closing connection during EE/RA
 Rich> communications.

That's a good point.  But another way to do this that doesn't require
incrementing the version number is to say "new semantics means a new
message".  I.e., don't change message semantics, but rather create new 
messages when new semantics are needed.

Which of these is chosen is a matter of taste.  I do agree that you
can't pick the approach you mentioned if you don't have version
numbers; that's a good reason to throw one in, as I suggested.

	paul


Received: from hpheger0.nm.informatik.uni-muenchen.de ([e-mail] [129.187.214.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA15339 for <[e-mail]>; Fri, 24 Sep 1999 04:31:51 -0700 (PDT)
Received: (from usm2000@localhost) by hpheger0.nm.informatik.uni-muenchen.de (8.8.6 (PHNE_17135)/8.8.6) id NAA23029 for [e-mail]; Fri, 24 Sep 1999 13:35:51 +0200 (METDST)
Date: Fri, 24 Sep 1999 13:35:51 +0200 (METDST)
Message-Id: <[e-mail]>
From: USM 2000 Organisation Committee <[e-mail]>
To: USM 2000 <[e-mail]>
Subject: USM 2000 - Second Call for Papers

           USM 2000: SECOND ANNOUNCEMENT AND CALL FOR PAPERS

                 3rd IFIP/GI International Conference on
                Trends towards a Universal Service Market

                            Munich, Germany
                         September 12-14, 2000 


General Information

USM 2000 is the third event in a series of international IFIP conferences
on Trends in Distributed Systems. It continues TreDS'96, held in Aachen,
Germany and TrEC'98 with special focus on Electronic Commerce in Hamburg,
Germany.

The technological progress in internet and telecommunication domains as
well as deregulation efforts of the telecommunication markets currently
under way in many countries enable an integration of data and
telecommunication. Distributed platforms get adapted to the needs of
telecommunication networks. This leads to a global distributed system with
millions of objects, running on top of a middleware kernel and interacting
with each other to provide services. USM 2000 brings together researchers,
service vendors and users in the field of universal service markets. USM
2000 takes place in Munich, Germany, the city of the famous Oktoberfest
which will start two days after the conference on September 16, 2000.


Topics

The USM 2000 considers services of a universal market in relation to
middleware, distributed applications and management. Areas of special
interest include:

* Component Based Systems, Service Creation
* Service Market Models, Accounting and Customer Care
* Quality of Service for Distributed Applications
* Trading, Brokering and Information Management
* Management of Virtual Networks
* Service and Application Management
* Ubiquitous Services and Nomadic Computing
* Distributed and Mobile Objects
* Agent Technology for Integrated Management 
* Advances in Middleware, e.g. CORBA, DCOM, Jini
* Telecommunication Architectures related to Distributed Systems
 

Submissions

You are encouraged to submit full technical papers describing original,
unpublished research or experience of about 12 pages. Extended abstracts
of 3-5 pages will be accepted for poster session papers. For submission 
guidelines please visit our web server. The proceedings will be published
in "Lecture Notes in Computer Science", Springer-Verlag.

Submissions due:         January 30th, 2000
Notice of Acceptance:    April 15th, 2000
Camera-ready Paper due:  June 1st, 2000


Further Information

Contact Person: Helmut Reiser - Phone (Fax): [phone] (~2147)

e-mail: [e-mail],
WWW:    http://usm2000.informatik.uni-muenchen.de/

Address: Ludwig Maximilians University
	 Institute for Computer Science
	 Oettingenstr. 67
	 D-80538 Munich
	 GERMANY


Conference Chairs

Claudia Linnhoff-Popien and Heinz-Gerd Hegering, LMU Munich


Program Committee

Sebastian Abeck, Uni Karlsruhe, Germany
Andrew T. Campbell, Center for Telecommunications Research, Columbia Uni New York, USA
John Dilley, Hewlett Packard, Palo Alto, USA
Kurt Geihs, Uni Frankfurt, Germany
Bernd Heinrichs, Cisco Systems Europe, Düsseldorf, Germany
Yigal Hoffner, IBM Zurich Research Laboratory, Switzerland
Axel Küpper, RWTH Aachen, Germany
Lea Kutvonen, Uni Helsinki, Finland
Winfried Lamersdorf, Uni Hamburg, Germany
Luigi Logrippo, Uni Ottawa, Canada
Michael Merz, Ponton, Hamburg, Germany
Zoran Milosevic, DSTC Brisbane, Australia
Elie Najm, Ecole Nationale Superieure des Telecommunications, Paris, France
Bernhard Neumair, DeTeSystem, Germany
Jerome Rolia, Uni Ottawa, Canada
Alexander Schill, TU Dresden, Germany
Doug Schmidt, ARL St. Louis, USA
Gerd Schürmann, GMD FOKUS, Germany
Morris Sloman, Imperial College, London, UK
Otto Spaniol, RWTH Aachen, Germany
Michael Stal, Siemens ZT, München, Germany
Ralf Steinmetz, TU Darmstadt, Germany
Volker Tschammer, GMD FOKUS, Berlin, Germany


Conference Organisation

Helmut Reiser (Chair), Christian Ensel, Markus Garschhammer, Rainer Hauck,
Bernhard Kempter, Annette Kostelezky, Igor Radisic, Holger Schmidt, Gerald
Vogt, LMU Munich


Sponsors

Ludwig-Maximilians-University (LMU)
International Federation for Information Processing (IFIP)
German National Foundation for Computer Science (GI)
Computing Centre of the Bavarian Academy of Sciences (LRZ)
BMW AG
DG Bank
Munich Network Management Team (MNM)
and others



Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA10180 for <[e-mail]>; Fri, 24 Sep 1999 01:56:52 -0700 (PDT)
Received: (from ronald@localhost) by gandalf.trustpoint.com (8.8.7/8.8.7) id CAA14316 for [e-mail]; Fri, 24 Sep 1999 02:00:58 -0700
From: "Life is hard, and then you die." <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: TSP version 03
To: [e-mail]
Date: Fri, 24 Sep 1999 02:00:58 -0700 (PDT)
Content-Type: text

> First off: I don't care whether you use the new CMP-over-TCP protocol 
> for TSP or not. [snip]

Actually, that's not quite true. It would be nice if the same protocol
were used to send CMP and TSP messages over TCP (and HTTP, for that
matter), as it means the same protocol library can be used. But I'm
obviously biased...

OTOH, I'm not quite sure why the "direct TCP based TSA message"
protocol is introduced at all. In CMP its raison d'être is to 
introduce a polling mechanism which is needed because of possible
manual intervention at the RA and other potential delays there.
I don't see this need with TSP. But I'm probably just missing
something.


  Cheers,

  Ronald



Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA03237 for <[e-mail]>; Thu, 23 Sep 1999 21:12:08 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 1B4B515539; Fri, 24 Sep 1999 00:15:44 -0400 (EDT)
Received: by haggis.ma.certco.com (Postfix, from userid 1079) id EC7477C051; Fri, 24 Sep 1999 00:15:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by haggis.ma.certco.com (Postfix) with SMTP id E46E274455; Fri, 24 Sep 1999 00:15:43 -0400 (EDT)
Date: Fri, 24 Sep 1999 00:15:43 -0400 (EDT)
From: Rich Salz <[e-mail]>
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail]
Subject: Re: TSP version 03
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> Do you agree with Paul and me that a new version number is needed only
> if new data cannot be properly parsed by old software?

No.  There might be semantic changes in existing pdu's.  E.g., multiple
"revoke me" requests return an error or ignore replay.  This kind of
thing happens when you find that most implementations of a spec didn't
do wghat was "obvisouly" intended.  E.g., closing connection during EE/RA
communications.

>  "unsupported packet format 09h
> from joe".  This is more useful than "unsupported version 5 connection
> from joe"

Are you speaking from experience or theory?

My experience (revving the DCE RPC protocol) is the exact opposite.
Very strongly so.
	/r$



Received: from Default (ip12.proper.com [165.227.249.12]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA20006 for <[e-mail]>; Thu, 23 Sep 1999 16:15:42 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 23 Sep 1999 16:19:48 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: PKIX Roadmap document
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

The -03 version of this draft came out a few weeks ago, and there has been 
almost no discussion on it. I believe that this document is very important 
to the PKIX work and should be reviewed more carefully than it has been. 
There are still a few places which say "needs more work" and I would bet 
that the editors would like suggested text, or at least suggested outlines 
for those.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA19721 for <[e-mail]>; Thu, 23 Sep 1999 16:09:44 -0700 (PDT)
Received: from ronald.trustpoint.com (ronald@ronald [192.168.42.4]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id QAA13044; Thu, 23 Sep 1999 16:13:48 -0700
From: Ronald Tschalär <[e-mail]>
Received: (from ronald@localhost) by ronald.trustpoint.com (8.8.7/8.8.7) id QAA26057; Thu, 23 Sep 1999 16:13:47 -0700
Message-Id: <[e-mail]>
Subject: Re: TSP version 03
To: [e-mail]
Date: Thu, 23 Sep 1999 16:13:46 -0700 (PDT)
Cc: [e-mail]
In-Reply-To: <[e-mail]> from "David P. Kemp" at Sep 23, 99 05:48:13 pm
Content-Type: text

First off: I don't care whether you use the new CMP-over-TCP protocol 
for TSP or not. That's up to you. My argument was against the blanket
statement that version numbers are not of any use, and against the
arguments used to support that statement which seemed to based on A)
badly designed protocols, and B) the use versions in static data
structures (as opposed to a networking situation that allows negotiation).
I apologize if I misunderstood you.

Note: the choice of the term "flag" for the message-type in the spec is
a bit unfortunate - I will use "message-type" instead, and use "flag" to
mean a flag in the more general sense.

> > From: Ronald Tschalär <[e-mail]>
> > 
> > There is a serious difference between being able to detect a version
> > mismatch and trying to parse the packet using the wrong version. In
> > the first case I send back a useful error message, in the second case
> > I can't.
> 
> Referring to Paul's example of 100 new packet formats not requiring
> a new version number, please give an example of new functionality
> that might be required in TSP-over-TCP which would force the protocol
> to be unparsable by current software. There are 249 unused "flag"
> values, only one of which would be needed to introduce an infinitely
> expandable protocol layer.

You can certainly do this. So, to introduce a new connection-close flag
you now define a new message-type which allows that flag to be set and
encapsulates all the other message types. To get this working in general
(i.e. to allow a client a server to negotiate the message-types they
understand), all you now need is an error message which allows the
server to specify what message-types it understands (otherwise all an
older server can do is reject the message, w/o giving sufficient
information for the client to decide why it was rejected, and whether
to retry the request using a different message-type). At this point
you're using the message-type as a kind of version indicator.

> The example I gave earlier was a DER-encoded
> value with syntax "Extensions".  You could burn one more flag value
> to represent any MIME object and still have 247 values left.
> These are over-the-top examples; it's far more likely that new
> functionality could be accommodated within the existing DER-encoded
> TSP messages or with a few new top-level messages identified by new
> "flag" numbers.

Whether the functionality goes into the transport protocol or into TSP
itself depends on what it affects. Yes, in most cases you want to
extend TSP; but in some cases, such as adding a connection-close flag
or adding new message-types, you need to change the underlying protocol
itself. Nothing new here.

> Do you agree with Paul and me that a new version number is needed only
> if new data cannot be properly parsed by old software?

No. It all depends on how negotiation you want to allow. At the one end
you could say "If I can't parse it I'll just abort" - this doesn't
"need" any versioning. At the other end you want to fully negotiate the
capabilities of each side.  This can be done either with version
numbers, extensible options, or some combination thereof. If your
extension mechanism is flexible enough you'll never need to change the
parser (you may want to for reasons of efficiency, or something, but
it's not necessary).

> After parsing,
> you might silently discard unrecognized data, or you might fail with an
> error, or you could use a critical flag to specify discard/fail at
> runtime, but in all cases you are able to recognize what has happened
> and send back a useful error message: "unsupported packet format 09h
> from joe".  This is more useful than "unsupported version 5 connection
> from joe" because a packet format number or an extension OID provides
> finer-grained information than a socket protocol version number.

The argument is not really about version numbers, but about how to allow
for negotiation. If you want to do that with options, fine. If you want
to do that with a version number, fine too. Which you want to use
depends a lot on how flexible the protocol needs to be, how fine grained
the negotiation should be, how much complexity you want to stick into
the basic parser, etc. The problem with the "direct TCP-based message"
protocols as defined in rfc-2510 and the TSP draft is that they don't
allow any negotiation: if the client wants to use a new feature
(message-type) which the server does not understand then all it gets
back is an errorMsgRep (hopefully - the spec doesn't even specify that),
and that does not have a machine parseable syntax defined to be able to
let the client figure out why exactly the error happened and possibly
how to correct it. This can be fixed by adjusting the errorMsgRep
syntax. Also, client can't advertise that it, say, understands new
response messages. This can be fixed by either adding a version number
or by adding new message-types. In CMP-over-TCP we fixed the errorMsgRep,
and chose to use a version number for simplicity. This gives the basic
framework to allow automatic negotiation should new features be added.

Enough said...


  Cheers,

  Ronald



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA18312 for <[e-mail]>; Thu, 23 Sep 1999 14:46:43 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id RAA05201 for <[e-mail]>; Thu, 23 Sep 1999 17:51:13 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id RAA05197 for <[e-mail]>; Thu, 23 Sep 1999 17:51: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 RAA19544 for <[e-mail]>; Thu, 23 Sep 1999 17:50:35 -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 RAA09658 for <[e-mail]>; Thu, 23 Sep 1999 17:48:13 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 23 Sep 1999 17:48:13 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: TSP version 03
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=ISO-8859-1
Content-MD5: guqoGLGCjn4UNyiLWD0K3Q==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.proper.com id OAA18313

> From: Ronald Tschalär <[e-mail]>
> 
> There is a serious difference between being able to detect a version
> mismatch and trying to parse the packet using the wrong version. In
> the first case I send back a useful error message, in the second case
> I can't.

Referring to Paul's example of 100 new packet formats not requiring
a new version number, please give an example of new functionality
that might be required in TSP-over-TCP which would force the protocol
to be unparsable by current software.  There are 249 unused "flag"
values, only one of which would be needed to introduce an infinitely
expandable protocol layer.  The example I gave earlier was a DER-encoded
value with syntax "Extensions".  You could burn one more flag value
to represent any MIME object and still have 247 values left.
These are over-the-top examples; it's far more likely that new
functionality could be accommodated within the existing DER-encoded
TSP messages or with a few new top-level messages identified by new
"flag" numbers.

Do you agree with Paul and me that a new version number is needed only
if new data cannot be properly parsed by old software?  After parsing,
you might silently discard unrecognized data, or you might fail with an
error, or you could use a critical flag to specify discard/fail at
runtime, but in all cases you are able to recognize what has happened
and send back a useful error message: "unsupported packet format 09h
from joe".  This is more useful than "unsupported version 5 connection
from joe" because a packet format number or an extension OID provides
finer-grained information than a socket protocol version number.






Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA17338 for <[e-mail]>; Thu, 23 Sep 1999 13:25:09 -0700 (PDT)
Received: from ronald.trustpoint.com (ronald@ronald [192.168.42.4]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id NAA10438; Thu, 23 Sep 1999 13:29:13 -0700
From: Ronald Tschalär <[e-mail]>
Received: (from ronald@localhost) by ronald.trustpoint.com (8.8.7/8.8.7) id NAA25781; Thu, 23 Sep 1999 13:29:12 -0700
Message-Id: <[e-mail]>
Subject: Re: TSP version 03
To: [e-mail]
Date: Thu, 23 Sep 1999 13:29:11 -0700 (PDT)
Cc: [e-mail]
In-Reply-To: <[e-mail]> from "David P. Kemp" at Sep 23, 99 09:55:46 am
Content-Type: text

> A comment on item ii):  an explicit version number field is
> the traditional means of allowing a protocol engine to determine that
> it does not understand a PDU from a later version of the protocol,
> but it is not a particularly good or useful means.
> 
> 1) The presence or absence of a version number is immaterial to the
> ability to accommodate future changes.  If a v1 engine encounters a PDU
> with an explicit version number of v2, what can it do other than say
> "I don't understand".  How is this different from omitting the version
> number and including v2 data that is not legal in v1 of the protocol -
> the engine still says "I don't understand", and can still take action
> identical to what it would have taken upon encountering an unrecognized
> explicit version number.

There is a serious difference between being able to detect a version
mismatch and trying to parse the packet using the wrong version. In
the first case I send back a useful error message, in the second case
I can't. The client, upon receiving a version mismatch error, can then
back down and use an older version (the new CMP-over-TCP protocol
specifies an error message containing the highest version the server
supports).

> 2) If a particular data item is legal in both v1 and v2, but the
> semantics of the datum are affected by the version number, then I
> would say the v2 protocol design is botched.

Agreed.

> 3) A version number offers no guidance on where the protocol may be
> extended in the future (i.e. items may be added to this list, values
> may be added to this enumeration, the legal range of this item may be
> extended, etc).  A version number offers no guidance on what action
> should be taken when encountering data from a future version.

If it doesn't, then the protocol is botched. A version number only makes
sense if you nail down what to do when new versions are introduced. The
CMP-over-TCP protocol does exactly that. Please have a closer look at it
before you summarily dismiss version numbers.

Note that a network protocol is quite different from, say, an X.509
certificate. The network allows you to back down and retry using a
different version. Processing a fixed certificate which can't be
changed does not. So the version in a certificate should not be confused
with the version used in a network protocol.


  Cheers,

  Ronald



Received: from cymail.cylink.com ([192.43.161.17]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA15439 for <[e-mail]>; Thu, 23 Sep 1999 10:58:41 -0700 (PDT)
Received: from dellious ([10.101.12.153]) by cymail.cylink.com (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-41860U500L2S100) with SMTP id AAA5786; Thu, 23 Sep 1999 10:58:54 -0700
From: [e-mail] (Mihran Mkrtchian)
To: <[e-mail]>, <"IETF-Announce:;@imc.org"@defender>
Cc: <[e-mail]>
Subject: EE-RA-CA protocol
Date: Thu, 23 Sep 1999 11:04:51 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

The chapter 3.2.8 (RFC 2510) suggests the following protocol:
EE            RA            CA
---- req ---->
<--- chall ---
---- resp --->
               ---- req' --->
               <--- rep -----
               ---- conf --->
<--- rep -----
---- conf --->

I think the implementation will be less complicated (in case if EE rejects
the cert) if the following scenario would be suggested:

EE            RA            CA
---- req ---->
<--- chall ---
---- resp --->
               ---- req' --->
               <--- rep -----
<--- rep -----
---- conf --->
               ---- conf --->

Mihran A. Mkrtchian
Cylink Corporation
Phone [phone]



Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA14286 for <[e-mail]>; Thu, 23 Sep 1999 09:32:10 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 50DC815539; Thu, 23 Sep 1999 12:35:44 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id E4A667C051; Thu, 23 Sep 1999 12:35:43 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2232.9) id <S5N1TRK6>; Thu, 23 Sep 1999 12:35:43 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Subject: RE: TSP version 03
Date: Thu, 23 Sep 1999 12:35:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

>You can generate an *additional* diagnostic ("unrecognized version
>number field"), but how useful is it?

It's been very useful to be able to report "Received v3 packet from joe"
rather than "Received bad packet from joe."

>how much quicker is it to parse and handle an explicit
>version field than to omit the field and allow version mismatches to
>be treated as any other malformed-ness error?

It can be significant, especially if I can avoid having to read in the
entire packet and start parsing.

>The recent discussion of v1/v2 CRLs is illustrative of the problem with
>version numbers. ... [elided]

I don't know the issue well enough to understand, other than to say that it
sure looks like ISO did a poor job of specifying the how/when extensions are
to appear.  If extensions are an optionally array of key/value pairs, then
I don't see why "v2 w/o extensions" is an issue.  (I'm not asking to open
that discussion, here, I'm just claiming that your example doesn't prove
that
version numbers are wrong, but rather that some mistake was made somewhere.)


>I don't want to have to think about what to do if I receive a cert with
>a SubjectUID field present and a version number absent (defaulting to v1).

You shouldn't have to think.  If they weren't defined in v1 then you
shouldn't
be looking for them. :)  Less flippantly, I think I understand a difference
in
where we're coming from. You're thinking of new code being able to handle
old
and new data structures.  I'm thinking of an existing deployed base being
able
to quickly and easily tell new code why they're not able to work together,
and giving the new code the option of going to "old fogey" mode.


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA13220 for <[e-mail]>; Thu, 23 Sep 1999 08:30:30 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhhxu23948; Thu, 23 Sep 1999 15:34:16 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA06056; Thu, 23 Sep 99 11:32:34 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA16354; Thu, 23 Sep 1999 11:34:15 -0400
Date: Thu, 23 Sep 1999 11:34:15 -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], [e-mail]
Subject: RE: TSP version 03
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

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

 >> From: "Salz, Rich" <[e-mail]> To: "'David P. Kemp'"
 >> <[e-mail]> Cc: "'[e-mail]'"
 >> <[e-mail]> Subject: RE: TSP version 03 Date: Thu, 23 Sep
 >> 1999 10:12:50 -0400
 >> 
 >> >In short, saying "add an explicit version number field" to allow
 >> for >future changes is both easy and ineffective.
 >> 
 >> I disagree.  It makes it easy to "bail out" quickly and generate a
 >> useful diagnostic.

 David> You can generate an *additional* diagnostic ("unrecognized
 David> version number field"), but how useful is it?

If version numbers are incremented for the wrong reason, they can hurt 
-- you may end up rejecting a packet you could have supported solely
because it has an unexpected version number.

 David> If the software doesn't bail out correctly (defined as
 David> something other than a core dump/GPF or wedge) when receiving
 David> malformed data, then the software is of poor quality.  If the
 David> software does handle malformed data correctly, how much
 David> quicker is it to parse and handle an explicit version field
 David> than to omit the field and allow version mismatches to be
 David> treated as any other malformed-ness error?

That's true but that's a different issue.

No system should crash because it receives malformed packets
(including intentionally malformed packets).  But it shouldn't be
required to act in a particularly useful way when that happens.

On the other hand, packets with new elements added in accordance to
the protocol extension rules are NOT malformed packets.  Those should
be handled as specified by the rules of the protocol.

	paul



Received: from emerald.lightlink.com ([e-mail] [205.232.34.14]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA13050 for <[e-mail]>; Thu, 23 Sep 1999 08:28:35 -0700 (PDT)
Received: from Mike ([209.216.70.17]) by emerald.lightlink.com (8.8.8/8.8.8) with ESMTP id LAA01884; Thu, 23 Sep 1999 11:32:31 -0400
Message-ID: <004101bf05d7$75a1aaa0$1146d8d1@Mike>
Reply-To: "Michael Duren" <[e-mail]>
From: "Michael Duren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Cc: "IETF-PXIX" <[e-mail]>
Subject: Re: time-stamp-03: interaction of TSTTime and serialNumber values
Date: Thu, 23 Sep 1999 11:22:10 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Denis,

The revised text for that section is more appropriate.

Seems to me that section 2.1 (Requirements of the TSA), items 3 and 4
already invalidate the example.  However, looking at item 4 of that section:

"to include a monotonically incrementing integer for each newly generated
time stamp token."

Should that requirement state that the monotonically incrementing integer
must be unique?

Mike Duren


-----Original Message-----
From: Denis Pinkas <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: IETF-PXIX <[e-mail]>
Date: Thursday, September 23, 1999 5:52 AM
Subject: Re: time-stamp-03: interaction of TSTTime and serialNumber values


>Terry,
>
>The current text says:
>
>The serialNumber field shall include a strictly monotonically
>increasing integer from one TimeStampToken to the next (e.g. 45,
>236,
> 245, 1023, ...). This guarantees that each token is unique and
>allows to compare the ordering of two time stamps from the same TSA
>bearing the same time. This field also provides the way to build a
>unique identifier to reference the token. It should be noticed that
>the monotonic property must remain valid even after a possible
>interruption (e.g. crash) of the service.
>
>Apparently it is not clear enough. The text was supposed to mean:
>
>The serialNumber field shall include a strictly monotonically
>increasing integer from one TimeStampToken to the next (e.g. 45,
>236,
> 245, 1023, ...). This guarantees that each token is unique and
>allows to compare the ordering of two time stamps. This is
>useful in particular when two times stamps bear the same time.
>This field also provides the way to build a unique identifier
>to reference the token. It should be noticed that the monotonic
>property must remain valid even after a possible interruption
>(e.g. crash) of the service.
>
>As a consequence with this clarification, your example will become
>invalid. I will include this clarification in the next draft.
>
>Denis
>
>> The current draft of TSP requires that responses include a monotonically
>> increasing integer to identify the token and to resolve ordering within
>> the precision of the time stamp value.  However, the draft is not clear
>> as to whether the serial number itself is sufficient to order all tokens
>> issued by a certain TSA.  In particular, the draft does not indicate
>> whether the order of serialNumbers must correspond with the order of the
>> time stamp values themselves.
>>
>> For example, is it legal to issue the following time stamps?
>>
>>   Token #1:
>>     genTime: 19990922233002Z
>>     serialNumber: 1
>>
>>   Token #2:
>>     genTime: 19990922233001Z
>>     serialNumber: 2
>>
>>   Token #3:
>>     genTime: 19990922233002Z
>>     serialNumber: 3
>>
>> I think that this sequence should be legal.  The serial number field
>> still provides ordering within the same genTime value, and also provides
>> the required reference value for future queries about the token.  The
>> primary source of ordering information should always be the genTime
>> field.  If those values are the same, then the serialNumber MAY be used
>> to resolve the ordering of the tokens.
>>
>> (As an aside, I think providing ordering information is really beyond
>> the scope of this protocol in any case, and so I don't see any
>> requirement for monotonically increasing values)
>>
>> Terry
>>
>>   --------------------------------------------------------------------
>>
>>   Terry Hayes <[e-mail]>
>>   Netscape Communications Corp.
>>
>>   Terry Hayes
>>   Netscape Communications Corp.  <[e-mail]>
>>                                  Courrier HTML
>>                                  Bureau: [phone]
>>                                  Adresse Netscape Conference
>>   Informations supplémentaires:
>>   le nom           Hayes
>>   Prénom           Terry
>>   Version          2.1
>



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA12871 for <[e-mail]>; Thu, 23 Sep 1999 08:26:21 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhhxu19441; Thu, 23 Sep 1999 15:30:23 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA05963; Thu, 23 Sep 99 11:28:40 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA16167; Thu, 23 Sep 1999 11:30:21 -0400
Date: Thu, 23 Sep 1999 11:30:21 -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: TSP version 03
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

Version numbers appear in many protocols, but not all use them the
right way.  Or the optimal way, if you prefer.

There are various protocols, especially old ones, that aren't directly 
extensible.  There you need a version number, which is incremented
whenever the packet format changes.

Extensible protocols, which basically means protocols that use tagged
fields (ASN.1, IPv4 options, etc.), don't have that strong a need for
version numbers.  At least not if the rules for handling tags are done 
right.  (Some are not; there are protocols that require you to reject
anything you don't recognize, which obviously blows the whole thing
right out of the water.  Fortunately they are rare.)  If you obey the
"be strict in what you send, lenient in what you receive" principle,
adding new tags to an existing protocol handles many new requirements.

If you do that, then you should NOT increment the version number.  In
other words, version number should identify a set of parsing rules,
not a specific set of tag values used.  If you add 100 new tags but
the rules for interpreting messages are unchanged, then the version
number shouldn't change.  (Certainly the major version should not.)
With tagged protocols, you only need change the (major) version number 
if you do something to the protocol that invalidates the parsing
rules.  For example, if tags change from one byte to two.

One useful thing some protocols have is a "critical" flag ("if you
don't understand this tag, reject the whole packet").  ATM's routing
protocol PNNI goes further, though it's not clear to me whether that
additional complexity will ever be used.

	paul


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA12519 for <[e-mail]>; Thu, 23 Sep 1999 08:10:07 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA10931; Thu, 23 Sep 1999 11:12:05 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA10927; Thu, 23 Sep 1999 11:12:00 -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 LAA14551; Thu, 23 Sep 1999 11:11:21 -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 LAA09487; Thu, 23 Sep 1999 11:09:00 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 23 Sep 1999 11:09:00 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: TSP version 03
To: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: l4rHgK4MYmvn9G5KBOXb5A==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Salz, Rich" <[e-mail]>
> To: "'David P. Kemp'" <[e-mail]>
> Cc: "'[e-mail]'" <[e-mail]>
> Subject: RE: TSP version 03
> Date: Thu, 23 Sep 1999 10:12:50 -0400
> 
> >In short, saying "add an explicit version number field" to allow for
> >future changes is both easy and ineffective.
> 
> I disagree.  It makes it easy to "bail out" quickly and generate a
> useful diagnostic.

You can generate an *additional* diagnostic ("unrecognized version
number field"), but how useful is it?

If the software doesn't bail out correctly (defined as something other
than a core dump/GPF or wedge) when receiving malformed data, then
the software is of poor quality.  If the software does handle malformed
data correctly, how much quicker is it to parse and handle an explicit
version field than to omit the field and allow version mismatches to
be treated as any other malformed-ness error?

The recent discussion of v1/v2 CRLs is illustrative of the problem with
version numbers.  CRL extensions were defined in v2, and v1 software
might not be expected to understand them.  But instead of having only
two reasonable cases (CRLs without extensions, CRLs with extensions),
we have a third case (CRLs without extensions but with an explicit
version=v2 field) whose validity has been the subject of debate.

The very existence of the explicit version field has caused unnecessary
confusion. If it did not exist, the discussion would never have been
needed.  If the outcome of the discussion had not been to modify X.509
to allow the third case, then applications would have been
unnecessarily complicated by checking for consistency between version
number and the presence of extensions.

I don't want to have to think about what to do if I receive a cert with
a SubjectUID field present and a version number absent (defaulting to v1).
If I understand SubjectUIDs, I'll handle them, otherwise I'll bail.
Much simpler.



Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA11646 for <[e-mail]>; Thu, 23 Sep 1999 07:09:30 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 3B6CD15537; Thu, 23 Sep 1999 10:12:58 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 82E387C051; Thu, 23 Sep 1999 10:12:57 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2232.9) id <S5N1TR2G>; Thu, 23 Sep 1999 10:12:57 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: TSP version 03
Date: Thu, 23 Sep 1999 10:12:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

>In short, saying "add an explicit version number field" to allow for
>future changes is both easy and ineffective.

I disagree.  It makes it easy to "bail out" quickly and generate a
useful diagnostic.


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA11376 for <[e-mail]>; Thu, 23 Sep 1999 06:54:17 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA06735 for <[e-mail]>; Thu, 23 Sep 1999 09:58:45 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA06731 for <[e-mail]>; Thu, 23 Sep 1999 09:58:45 -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 JAA13490 for <[e-mail]>; Thu, 23 Sep 1999 09:58:07 -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 JAA09452 for <[e-mail]>; Thu, 23 Sep 1999 09:55:46 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 23 Sep 1999 09:55:46 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: TSP version 03
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: wuzCRuxk3laAIcax628Q4w==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

John,

A comment on item ii):  an explicit version number field is
the traditional means of allowing a protocol engine to determine that
it does not understand a PDU from a later version of the protocol,
but it is not a particularly good or useful means.

1) The presence or absence of a version number is immaterial to the
ability to accommodate future changes.  If a v1 engine encounters a PDU
with an explicit version number of v2, what can it do other than say
"I don't understand".  How is this different from omitting the version
number and including v2 data that is not legal in v1 of the protocol -
the engine still says "I don't understand", and can still take action
identical to what it would have taken upon encountering an unrecognized
explicit version number.

2) If a particular data item is legal in both v1 and v2, but the
semantics of the datum are affected by the version number, then I
would say the v2 protocol design is botched.

3) A version number offers no guidance on where the protocol may be
extended in the future (i.e. items may be added to this list, values
may be added to this enumeration, the legal range of this item may be
extended, etc).  A version number offers no guidance on what action
should be taken when encountering data from a future version.

In short, saying "add an explicit version number field" to allow for
future changes is both easy and ineffective.  A harder but better
suggestion would be to define where the protocol might be extended
in the future and what should be done on encountering data from
beyond the supported version.

Dave Kemp


Note: I take no credit for the above - it is taken wholesale from
Prof. Larmouth's discussion of extensibility and exceptions in
"ASN.1 Complete".



> From: [e-mail]
> Subject: Re: TSP version 03
> To: Denis Pinkas <[e-mail]>
> Cc: IETF-PXIX <[e-mail]>
> 
> Denis,
> 
> The TSP-over-TCP protocol defined in the new draft suffers from some of the
> same problems we found in the CMP-over-TCP protocol in RFC 2510.  I would
> suggest that the changes recommended in the new
> draft-ietf-pkix-cmp-tcp-00.txt be applied to TSP-over-TCP as well.  These
> changes include:
> 
> i)  Changing the "poll time" from an absolute time to a delta time.  This
> is more robust than an absolute time in the event of a clock-skew between
> requester and responder, and also doesn't suffer from the Y2038 problem.
> 
> ii) Changing the protocol to contain an explicit version number field to
> allow for future changes.
> 
> iii) Specifying whether the TCP connection may remain up to carry multiple
> TSP requests, and which end is responsible for closing it.
> 
> John





Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA09340 for <[e-mail]>; Thu, 23 Sep 1999 04:41:43 -0700 (PDT)
From: [e-mail]
Subject: Re: TSP version 03
To: Denis Pinkas <[e-mail]>
Cc: IETF-PXIX <[e-mail]>
Date: Thu, 23 Sep 1999 07:14:59 -0400
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Arista/Iris(Build V5010621|June 21, 1999) at 09/23/99 07:47:44 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Denis,

The TSP-over-TCP protocol defined in the new draft suffers from some of the
same problems we found in the CMP-over-TCP protocol in RFC 2510.  I would
suggest that the changes recommended in the new
draft-ietf-pkix-cmp-tcp-00.txt be applied to TSP-over-TCP as well.  These
changes include:

i)  Changing the "poll time" from an absolute time to a delta time.  This
is more robust than an absolute time in the event of a clock-skew between
requester and responder, and also doesn't suffer from the Y2038 problem.

ii) Changing the protocol to contain an explicit version number field to
allow for future changes.

iii) Specifying whether the TCP connection may remain up to carry multiple
TSP requests, and which end is responsible for closing it.

John





Denis Pinkas <[e-mail]> on 09/21/99 09:18:04 AM

To:   IETF-PXIX <[e-mail]>
cc:

Subject:  TSP version 03


A new draft of the Time Stamping Protocol (TSP) has been published
at:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-03.txt

The draft attempts to accommodate the issues raised at the Oslo
meeting, comments received at the Oslo meeting and comments sent on
the PKIX mailing list.

Issues raised at the Oslo meeting:

1) Format of the TSTTime (inspired form NTP)
2) TDA (Temporal Data Authority) support.

1) A new TSTTime has been defined. It fairly simple and composed of
two fields, one field using GeneralizedTime and allowing to specify
the time below the precision of a second and another optional field
allowing to specify the accuracy in seconds or sub-seconds when that
precision is *not* plus or minus one second. It is expected that
many TSA will not use the precision field and thus will produce the
time according to RFC 2459 section 4.1.2.5.2. with plus or minus one
second for the precision.

In addition the previous draft was attempting to provide a
chronology between two time stamps issued by the same TSA within the
same second (assuming sub-seconds were not used). This can now be
provided using the serial number which is being made mandatory.

2) At the last meeting I advertised that if no one would produce a
"good" rational for supporting TDAs, TDAs would be removed. Since
such a rational has not been produced, the extension has now been
suppressed. However, it has been realized that we make making the
same original mistake that X.509 did with the version 1: omitting to
provide an extension mechanism. So an extension field has been
added. This allows anyone (including ISO) to define extensions in
the future, without impacting *this* document. TDAs could even been
re-introduced at any time in the future, but using the extension
mechanism.

Comments received at the Oslo meeting

3) Steve Kent during the meeting said that we should not confuse a
Time Stamp with a time information and thus requested the hash in
the request to be mandatory. This is now done.

4) some people complained about the fact that the TSA was making its
own judgment about the validity of the hash function used by the
requester. This requirement has been partly raised since the TSA is
now only required to know the OID of the hash function to make sure
that the length of the hash code is correct. So the OIDs need to be
known, but the TSA offers no guarantee about the strength of the
hash functions (the legal responsibility has disappeared).

Note: The filling dates for all patents have been added and a
warning about the *use* of the protocol has been added.

As a result of all of this, the document is now simpler and shorter.

Denis






Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA01052 for <[e-mail]>; Thu, 23 Sep 1999 02:40:08 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA24752; Thu, 23 Sep 1999 11:43:27 +0200
Message-ID: <[e-mail]>
Date: Thu, 23 Sep 1999 11:43:24 +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: time-stamp-03: interaction of TSTTime and serialNumber values
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Terry,

The current text says:

The serialNumber field shall include a strictly monotonically 
increasing integer from one TimeStampToken to the next (e.g. 45,
236,
 245, 1023, ...). This guarantees that each token is unique and 
allows to compare the ordering of two time stamps from the same TSA 
bearing the same time. This field also provides the way to build a 
unique identifier to reference the token. It should be noticed that 
the monotonic property must remain valid even after a possible 
interruption (e.g. crash) of the service. 

Apparently it is not clear enough. The text was supposed to mean:

The serialNumber field shall include a strictly monotonically 
increasing integer from one TimeStampToken to the next (e.g. 45,
236,
 245, 1023, ...). This guarantees that each token is unique and 
allows to compare the ordering of two time stamps. This is 
useful in particular when two times stamps bear the same time. 
This field also provides the way to build a unique identifier 
to reference the token. It should be noticed that the monotonic 
property must remain valid even after a possible interruption 
(e.g. crash) of the service. 

As a consequence with this clarification, your example will become
invalid. I will include this clarification in the next draft.

Denis
 
> The current draft of TSP requires that responses include a monotonically
> increasing integer to identify the token and to resolve ordering within
> the precision of the time stamp value.  However, the draft is not clear
> as to whether the serial number itself is sufficient to order all tokens
> issued by a certain TSA.  In particular, the draft does not indicate
> whether the order of serialNumbers must correspond with the order of the
> time stamp values themselves.
> 
> For example, is it legal to issue the following time stamps?
> 
>   Token #1:
>     genTime: 19990922233002Z
>     serialNumber: 1
> 
>   Token #2:
>     genTime: 19990922233001Z
>     serialNumber: 2
> 
>   Token #3:
>     genTime: 19990922233002Z
>     serialNumber: 3
> 
> I think that this sequence should be legal.  The serial number field
> still provides ordering within the same genTime value, and also provides
> the required reference value for future queries about the token.  The
> primary source of ordering information should always be the genTime
> field.  If those values are the same, then the serialNumber MAY be used
> to resolve the ordering of the tokens.
> 
> (As an aside, I think providing ordering information is really beyond
> the scope of this protocol in any case, and so I don't see any
> requirement for monotonically increasing values)
> 
> Terry
> 
>   --------------------------------------------------------------------
> 
>   Terry Hayes <[e-mail]>
>   Netscape Communications Corp.
> 
>   Terry Hayes
>   Netscape Communications Corp.  <[e-mail]>
>                                  Courrier HTML
>                                  Bureau: [phone]
>                                  Adresse Netscape Conference
>   Informations supplémentaires:
>   le nom           Hayes
>   Prénom           Terry
>   Version          2.1


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA06083 for <[e-mail]>; Wed, 22 Sep 1999 19:16:52 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA14522 for <[e-mail]>; Thu, 23 Sep 1999 12:20:21 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd_Zy6F_; Thu Sep 23 12:19:59 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA18938 for <[e-mail]>; Thu, 23 Sep 1999 12:19:59 +1000 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0bNKcl; Thu Sep 23 12:15:33 1999
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA09402 for <[e-mail]>; Thu, 23 Sep 1999 12:15:33 +1000 (EST)
Message-Id: <[e-mail]>
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <TK2BVNQT>; Thu, 23 Sep 1999 12:13:54 +1000
From: "Manger, James" <[e-mail]>
To: [e-mail]
Subject: RE: Timestamp: 03: TSP version 3
Date: Thu, 23 Sep 1999 12:14:21 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF0569.48BBA428"

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_01BF0569.48BBA428
Content-Type: text/plain;
	charset="iso-8859-1"

> Comments on version 3 of the timestamp draft:
> 
> 2.2
> Highlights from the 1st sentence: ".. requesting .. requests .. request
> ..Req ..".  :-)
> 
> 2.4.1
> Please use integer 1 for version 1 - it avoids confusion.
> 	version	INTEGER {v1(1)},
> 
> 4) ..TSA offers no guarantee about the strength of the hash functions..
> But the paragraph after the MessageImprint definition still says 'It is up
> to the TSA to decide whether or not the given has algorithm is
> "sufficient"'.  Rename the 'messageImprint' field as 'opaque' to make it
> obvious that the TSA is making no claim about the value, other than its
> existence, even though it is signing it.
> 	opaque	[2] MessageImprint,
> Why is it optional?
> 
> 2.4.2
> Why repeat selected definitions from CMS (SignedData etc.)?  You still
> have to read CMS because not all definitions are repeated (e.g.
> CMSVersion).  Don't bother repeating any - it just opens the possibility
> of incompatibility or confusion.
> 
> Time is the whole reason for the timestamp.  Call the field 'time', not
> 'genTime'; put it at the top of the token (after the version) and don't
> bury it in a TSTTime construct (make 'accuracy' the 3rd field in TSTInfo).
> Now the major items are directly visible in the definition of the major
> type.
> 
> Don't restrict the 'seconds' accuracy field to 1..59.  This is an
> unnecessary & arbitrary limit.  My clock may only be synchronized to UTC
> to +/-2 minutes (I may wish to use a very conservative estimate).  You
> don't, of course, need a new 'minutes' choice in the Accuracy type, just
> allow values like 120 seconds.
> 
> Show the syntax as: YYYYMMDDhhmmss[.s...]Z
> This implies all the DER-encoding rules it can (keep the sentence about
> omitting trailing 0's in the fractional second component & the decimal
> point if the fractional seconds is 0).
> The syntax in the current draft does not show the full options of the
> GeneralizedTime syntax (e.g. does not show decimal comma option), nor does
> it imply all the DER-encoding restrictions (e.g. terminate with Z).
> 
> 3.2
> time-to-check-back
> Surely a relative time would be far more appropriate here, i.e. number of
> seconds from now until you should poll again.
> 
> 3.4
> How about an easier HTTP request:
> 	
> http://aaa.bbb.com/cgi-bin/timestamp?alg=sha1&hash=A9993E364706816ABA3E257
> 17850C26C9CD0D89D
> 
> 6.
> CMS has been published as RFC 2630.
> 
> A.
> Providing a syntax to hold a timestamp & its associated data is a good
> idea, but there is no need for this to have extra security - the timestamp
> is already signed & contains a hash of the data!
> 
> Given that a major identified use of timestamps is to timestamp a digital
> signature it is likely that a CMS SignedData structure is already being
> used.  A sensible place to store a timestamp is in this existing structure
> - as an unauthenticatedAttribute.
> 
> A timestamp could apply to the content being signed (e.g. PDF doc), the
> signature on the content or the signature plus the certificates & CRLs.
> Perhaps three attributes are required:
> 	timestampedContent	ATTRIBUTE ::= { WITH SYNTAX ContentInfo  ID
> id-at-??? 1 }
> 		-- msgImprint is the same value as the MessageDigest
> auth.att. value
> 	timestampedSignature	ATTRIBUTE ::= { WITH SYNTAX ContentInfo  ID
> id-at-??? 2 }
> 		-- msgImprint is the hash of the encryptedDigest field
> (DER-encoded)
> 	timestampedCertSig	ATTRIBUTE ::= { WITH SYNTAX ContentInfo  ID
> id-at-??? 2 }
> 		-- msgImprint is the hash of the concatenation of the
> certificates, crls &
> 		-- encryptedDigest fields (all DER-encoded)
> 
> Alternatively, or in addition, define how the data can be stored in the
> timestamp itself.
> 	"Data can be stored with its associated timestamp as the contents of
> an octet string held as the value of a attribute of type 'data' in the
> unauthenticatedAttributes field of the timestamp."
> 
> x.
> The I-D ACTION e-mail had an extra sentence at the end of the Annex,
> compared to the actual draft.
> 	"..(TDA) .. proves in addition that a datum existed before a
> particular unpredictable event."
> This should say "after", not "before".
> 

------_=_NextPart_000_01BF0569.48BBA428
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IjcCAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAhAAAAUkU6IFRpbWVzdGFtcDogMDM6IFRTUCB2ZXJzaW9u
IDMALAoBCYABACEAAABFNEI2RTdDNzRGNzFEMzExQkQyMzAwMTA0QjA4REJGMQApBwEggAMADgAA
AM8HCQAXAAwADQA1AAQASAEBBYADAA4AAADPBwkAFwAMAA4AFQAEACkBAQ2ABAACAAAAAgACAAED
kAYAFA4AAB4AAAADAC4AAAAAAEAAOQDwdmVZaQW/AR4AcAABAAAALQAAAEktRCBBQ1RJT046ZHJh
ZnQtaWV0Zi1wa2l4LXRpbWUtc3RhbXAtMDMudHh0AAAAAAIBcQABAAAAGwAAAAG/BCHtSYTN/pVw
EBHTrlcACMckrdIAUcrA1gACAQkQAQAAAKcKAACjCgAAcRMAAExaRnX1qbRUAwAKAHJjcGcxMjX+
MgD/AgYCpAPkBesCgwBQEwNUAgBjaArAc2V0/jIGAAbDAoMOUAPVBxMCg7IzE89mNBA/EUR9CoDb
CM8J2TsYbw4wNRmDDiAeOBi8F5EOYgtgbmczFDA4AFBoBbB6ZG9qYwAAKhJVIAKRHcBsrx31CvsU
4gwBYwBBcANg7nQFkAVACFBtB4ACMAQguQIgIHYEkACQIbEzIaDgZiB0aGUioAdyAZBAbXAgZHJh
AYA6IwqFCoUyLjIKhUhpeGdobCWBIYEDUiKjMR0jMCASsAIwCfBjZTqgICIuLiAYcHEKUPMjMAuA
ZyAnqAQgJ6gocQ5SJ+AocSeQICA6LSIpI/40LjEKhVBs5GVhErAgdSzBC4Ag0H5nBJAmoCYQBbEh
5i2wLYMtIAVAYXZvaWQEINkFoG5mLPAiIS4KhgGRAyHWMINJTlRFR0UCUgMwe3YxKDEpOFx9LCP8
CvQlsDM25w6wH4wgpjQpCuEfnyCmRyegNE8gxFRTQSJxZoEh8SBubyBndQrA/wBwINAi0AGgCGAF
QCKyIzDfGHAcwCKwInYSgHM7sC+g9ydAIvACIHM17zb/OA8zHFs9PyCXQjrVQJFhCcBhXnA7sCOx
LYEisk0HkHP5Q4BlSSNgBRACMCOADoBvC4Au0CIiKCFsAyBEwHl5BCAnSQVABAAs4CNwdH854CKy
OSJHgQWBLzAi0Hc/IsAisQXABbE50DrkZ2nPIeADoDxBLvBsZwWwLtDGaCZQRyEic3UOkA3gswiQ
AjAiJyqBKhBuI1DbItEiwScHgUTJJyYQCJDsbGQu8EbBb0CQJ/FOEBtHgQDAay0RBUBvYnb3IiAs
8CKhYTrkOSJHIU+BuyhCOdFjC2EmUDqodgdA/QpQLCGgSQNQgQOgLtAEINxleAQAJyNTcGVKIiKw
3whgJZAuwkchAJBnAwAoUY8u0DALTtQwg1syXUSN8TKmV2h5RxJP0gUwIiG9B0A/Ku8k51oSGHBw
LKC/JtIskCDwCYBFeSYFQwXhrChTVmEJgERQoGFUcKB0Yy4pPyqQWQhg30YlEoAh4EdyGHBhTnBf
MvpiBZBhLPJJggdAAyBeKg8KwCLQXSRd8ShlLmerJ7BfMVYh9CkqgUQCIP4nBUAG4EkDXSQoQgBw
WjB9LrNqLPBakgnwUGJDMW/5BBBpYgMQLtBaMCKBC4D/BaAjYGdBaXYFwC9/QGUHYv9HEiKySNAG
8GRCLLAhsS3S+yK7KoFDYyIisk40ZmAHcVYnU3BJgictcG4HYif+O0NAOtEu0jrkR4AjcCKG9m9P
oAOgKEP4IeU1wABw/14BZkQIcFoxRwEDoGAQOSCuVGzDa0E7QXUg8ShPg9onANBjCHAA0HlPMSLB
XjMLIE4ldkF2kUkvkG+5ZfJObwfgIrIAwGoFscku0GVtZARkaRhwIPD+bFowUCBpUW2xdkEiskWJ
/yKFewRpsF1Aa91mNBhwO0H7DeA65CcSsGtBL0BOEHgmS04lR4ExJ6A1OSqBVP5oWlJKgQOgPKBf
sCdQRLF9deEmZBFpcDtQhNIlsG27VtEqkE1aMFIgHYBrT3FdacFufGFiYCbgeSdAaBsDYAMAel3x
R4FVVEOxR3IrLy0S4IXwbjrQ+QeRKEmG0wPxO7BHgSzy/2AQIeGGYTzxBJBTICLwYXH/KBIAwCDQ
ZfJgsnVjU3EikP8FoAhwErBw4QngTnGOYQfgf00giXROEBJwLyAnUH0GQf+CFn8CU3BoM2MhepFT
IwQgdyWwT6EOIDAm4YGTa91Tbx0weqSHoQGQeE6BJ3BZwZXhTU1ERGhLEHuQmHNbLpOgJ6BdWmxW
X4OzI2AlsAeRb6ZEMeAt/ycxBHAoQndgLJBaY2KAc8H/T6BdMDr0JwU6lQNwLtAoM/eFcWmBKFEw
gWB9BgNQAND/WtSTNWsxI2ACICFhhQF9RP9IgADAAyBpIEVCBpCdv4GE/UcSMGXwl0eVF30VeEE7
Yf9FYSOidVEHkUmCPGB6lS+g70ZhWrQhkSKURwnwBJAHQP+IImzDlTVk9KV8oCZqMQDA/VqlKXDi
BcClc1XymBFaMP+Yj5mTgKVek2T0RBGJYWSh24pBO6FaoudAZTMk5yLyGi1HgC0ScAWQay1i/QDQ
a5Q2CHBOUKzxJ8ELYL+MAyLySMAIYE5hh3FmCsH/BGBkMUOwIKFFIa/ySRFTYexpLmUAOcB1BtBJ
IiKQP6ImJiM50AfgPKBGQSB5/2DCVZFOYWkgRmFDgAtxsK/+NCUGepE6pAORLKEIkSVg/XawUCfG
I+Ywg0EvAFCZ4DMglh6QbmtOcCXgdHCQOi8vYcIgLmLCYHIuajEvY0oAswALgC8VIvc/SqE9PGBh
MSaRPEI9QTnE8DNFNBAQNDcwNh0ANkFCBkHFIA4wNzE3ODUAMEMyNkM5Q0TgMEQ4OUS/jyCII/z+
NjAGXzJKYmJgSjFx8AJg54phjpIEIFJGiMDGsBzg9WvdQTAGUANgUCCZg2AQ/5U1R4FtkY6iIviF
EFRCLLB3bhBIgGSjZF/yg/I58G/3BHAtIA5wYVNwdcA642Qx/0chOdGOc25UbRLPYWFiVIB/hXGT
MghxabEusCK8g/Js/2HSWjBWUl3xhRBrQQGQC4Cv0gI8QyKF0aIhI/xHShP/UINgEHsFDnC5gU4x
TnAs8v8igiMGg9NHgiMHYBB8AEoA/wGQRnFWYVCgs9FV5ZKyfGH/24VfMl+Jd0TgI9dYYmAoQv0s
8WQqgTlAJvF8tAtRkAH/R4EjMLYT1px9E0chVIMoQv/imC6wSnKEMmKQIrG5gWKA/V3hQQJABRDS
8X8+SBEjB/+N8U5itmDhAkeU2IKfguPko9f1ZPRQREZ1UWOrwf87A9/XIbHtmm5l38gLUFBTP3bx
BJDckuoSBCCFEENS9kyToCqQUASQEoDd8SKwvwnRclHqhWQGJ/B8EWS+u18i9wmACFDt8zCDQXaw
UpRJQoigRSqgOj0yAVFaAElUSAYAWTGgQZ5YIRHt83oCKpBJRNKB8i1QoC0//LAtoTKAvsvtMJIt
LrB7kGdFBm0VRMDvTLFTI06CRFlEJYApsumS/i710SewUyP3X/hkX4LgA//5P/pP+1/8ZxLg/R/+
L2jEf9k6JzF14KtwX8EBNE40KP+ZBxiAKtb3z/OhX4EEjwWf/wavB78Izwnf2TprQeoSr+Hvffnz
mlNwC8Bs9EETvxTBvwuvTkKJwWMiDR/NCGxEEb8XQiHgfGBTcXtBdlFk30D/PNJTcH2DPCF6ldGj
mmKHcl/mAnmD1m0l8E5QZjALIv9f4yE8sDPQvd6J8zXt5KdD/71RhqA40KoRgMGdIdZwTmT/Uuco
Y/XIcwN/EUbQ0aJOEL99Fel/9fdONHMWbuciW0ySeKL6SS38MEFDefD0T069cC3b8LmhSmBOcb+9
YdVlm2Y65HFgLvdBhGH+eBjhakIh0keFniE6EGNBh6UiI4yW8ChUREF1AP+W8ENAzjGaAh8423bR
obfQ/1R1tXJuUYryQJHp8ZngQKH/hFDA4PcggOG88G2xVTJW4L8wJoOjuhVGkSRAQ/MicOReIjvE
OIA3xjfxZMdmMhfH9MidE6EARAAAAwD9P1IDAAAeAEIQAQAAACEAAAA8MTk5OTA5MjExMDU5LkdB
QTI3Nzc1QGlldGYub3JnPgAAAAADACYAAAAAAAMANgAAAAAAHgAxQAEAAAAQAAAASk1BTkdFUjI5
Mjg4RUYzAAMAGkAAAAAAHgAwQAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAMAGUAAAAAAAgH5PwEA
AABnAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAABgAAAC9PPVRFTFNUUkEvT1U9UUxEIEtJTkdT
Rk9SRC1TTUlUSC9DTj1NUyBNQUlMIFJFQ0lQSUVOVFMvQ049Sk1BTkdFUjI5Mjg4RUYzAAAeAPg/
AQAAAA4AAABNYW5nZXIsIEphbWVzAAAAHgA4QAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAIB+z8B
AAAAZwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAYAAAAvTz1URUxTVFJBL09VPVFMRCBLSU5H
U0ZPUkQtU01JVEgvQ049TVMgTUFJTCBSRUNJUElFTlRTL0NOPUpNQU5HRVIyOTI4OEVGMwAAHgD6
PwEAAAAOAAAATWFuZ2VyLCBKYW1lcwAAAB4AOUABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwBAAAcw
oDhJGGkFvwFAAAgwKKS7SGkFvwEeAD0AAQAAAAUAAABSRTogAAAAAB4AHQ4BAAAAHQAAAFRpbWVz
dGFtcDogMDM6IFRTUCB2ZXJzaW9uIDMAAAAACwApAAAAAAALACMAAAAAAAMABhCHOTKhAwAHEFgM
AAADABAQAQAAAAMAERACAAAAHgAIEAEAAABlAAAAQ09NTUVOVFNPTlZFUlNJT04zT0ZUSEVUSU1F
U1RBTVBEUkFGVDoyMkhJR0hMSUdIVFNGUk9NVEhFMVNUU0VOVEVOQ0U6IlJFUVVFU1RJTkdSRVFV
RVNUU1JFUVVFU1RSRVEiOgAAAACe6w==

------_=_NextPart_000_01BF0569.48BBA428--


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id OAA24483 for <[e-mail]>; Wed, 22 Sep 1999 14:08:45 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Wed, 22 Sep 1999 17:16:07 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 22 Sep 1999 17:12:28 -0400
To: [e-mail], IETF-Announce:;
From: Robert Moskowitz <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-cmp-tcp-00.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 07:06 AM 9/15/1999 -0400, [e-mail] wrote:

I want to point out to people here that this draft reflects work from the
3rd CMP interop workshop (which was virutally held the week of Aug 30th).
This was one of 2 big challenges we faced.

Please review it, as those of us that worked at it feel that it makes
direct TCP usable and interoperable for CMP and have asked Carlisle to roll
it into upcoming changes to 2510.

We are trying to finish up a draft on the other major work item.  Stay tuned.

>
>	Title		: Using TCP as a Transport Protocol for CMP
>	Author(s)	: R. Tschalar,  A. Kapoor, C. Adams
>	Filename	: draft-ietf-pkix-cmp-tcp-00.txt
>	Pages		: 9
>	Date		: 14-Sep-99
>	
>This document describes how to layer Certificate Management
>Protocols [CMP] over [TCP]. A method for doing so is described in
>section 5.2 of [CMP], but that method does not solve problems
>encountered by implementors. This document specifies an enhanced
>method which extends the protocol.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-tcp-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-cmp-tcp-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-cmp-tcp-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-cmp-tcp-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-tcp-00.txt>

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


Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA24316 for <[e-mail]>; Wed, 22 Sep 1999 14:06:09 -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 OAA25752 for <[e-mail]>; Wed, 22 Sep 1999 14:09:38 -0700 (PDT)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FIHC4200.7TJ; Wed, 22 Sep 1999 14:09:38 -0700 
Message-ID: <[e-mail]>
Date: Wed, 22 Sep 1999 14:09:23 -0700
From: [e-mail] (Terry Hayes)
Reply-To: [e-mail]
Organization: Netscape Communications, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: time-stamp-03: interaction of TSTTime and serialNumber values
Content-Type: multipart/mixed; boundary="------------09574FECFF220B3F9E390ACC"

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

The current draft of TSP requires that responses include a monotonically
increasing integer to identify the token and to resolve ordering within
the precision of the time stamp value.  However, the draft is not clear
as to whether the serial number itself is sufficient to order all tokens
issued by a certain TSA.  In particular, the draft does not indicate
whether the order of serialNumbers must correspond with the order of the
time stamp values themselves.

For example, is it legal to issue the following time stamps?

  Token #1:
    genTime: 19990922233002Z
    serialNumber: 1

  Token #2:
    genTime: 19990922233001Z
    serialNumber: 2

  Token #3:
    genTime: 19990922233002Z
    serialNumber: 3

I think that this sequence should be legal.  The serial number field
still provides ordering within the same genTime value, and also provides
the required reference value for future queries about the token.  The
primary source of ordering information should always be the genTime
field.  If those values are the same, then the serialNumber MAY be used
to resolve the ordering of the tokens.

(As an aside, I think providing ordering information is really beyond
the scope of this protocol in any case, and so I don't see any
requirement for monotonically increasing values)

Terry

--------------09574FECFF220B3F9E390ACC
Content-Type: text/x-vcard; charset=us-ascii;
 name="thayes.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Terry Hayes
Content-Disposition: attachment;
 filename="thayes.vcf"

begin:vcard 
n:Hayes;Terry
tel;work:[phone]
x-mozilla-html:TRUE
org:Netscape Communications Corp.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
x-mozilla-cpt:;-1
fn:Terry Hayes
end:vcard

--------------09574FECFF220B3F9E390ACC--



Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA20139 for <[e-mail]>; Wed, 22 Sep 1999 07:06:03 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP for <[e-mail]> id 0A0D215535; Wed, 22 Sep 1999 10:09:30 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 7F6F77C052 for <[e-mail]>; Wed, 22 Sep 1999 10:09:30 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2232.9) id <S5N1TQX0>; Wed, 22 Sep 1999 10:09:30 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'Manger, James'" <[e-mail]>, [e-mail]
Subject: RE: Timestamp: nonce field
Date: Wed, 22 Sep 1999 10:09:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

> The nonce field adds nothing.  It should be removed from the request &
> timestamp token.  The messageImprint serves the desired purpose.
It can be useful to prove that proper diligence was done, when timestamping
is part of a series of interactions.  Keeping the nonce consistent across
timestamp, OCSP, etc., means it can be used as an audit identifier.



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA18889 for <[e-mail]>; Wed, 22 Sep 1999 05:06:38 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id OAA09960; Wed, 22 Sep 1999 14:09:22 +0200
Message-ID: <[e-mail]>
Date: Wed, 22 Sep 1999 14:09:19 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: "Manger, James" <[e-mail]>
CC: [e-mail]
Subject: Re: Timestamp: nonce field
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> The nonce field adds nothing.  It should be removed from the request &
> timestamp token.  The messageImprint serves the desired purpose.

There has already be a thread on that topic and the conclusion was
to keep the nonce. 
 
> Replay attacks are not attacks for a timestamp.  A timestamp means "this
> datum existed at this time", which implies it exists for all time beyond
> this point as well (you could lose the datum but I don't think that is
> relevant).  If you request a timestamp today but a timestamp for the same
> message from last Monday is substituted... you know the datum existed before
> last Monday, which is (always) better than knowing it existed before today.

Not in all cases: in some cases it is important to get the time
stamp with the current time and not to get an older one. When the
client has no trusted local clock, the nonce is the only way to test
the freshness.

Denis
 
> Perhaps you want a new timestamp for the same message because you want it
> signed with the TSA's new key, or you want a version 2 timestamp, or you
> want a different policy, or you want an extension.  In all these cases, you
> should not check for freshness but for your desired feature.
> 
> If all you want is a fresh timestamp as "signed time" it is still simple:
> make up a random message (or a random hash) and get that timestamped.
> 
>   --------------------------------------------------------------------
> 
>    Part 1.2       Type: application/ms-tnef
>               Encoding: base64


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA18148 for <[e-mail]>; Wed, 22 Sep 1999 03:52:11 -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 GAA27637; Wed, 22 Sep 1999 06:55:38 -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-time-stamp-03.txt
Date: Wed, 22 Sep 1999 06:55:37 -0400
Sender: [e-mail]

--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 Time Stamp 
                          Protocols (TSP)
	Author(s)	: C. Adams, P. Cain, D. Pinkas,  R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-03.txt
	Pages		: 17
	Date		: 20-Sep-99
	
A time stamping service allows to prove that a datum existed before
a particular time and can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]). This document describes the format of a request sent to a
Time Stamping Authority (TSA) and of the response that is returned.
An example on how to prove that a digital signature was generated
during the validity period of the corresponding public key
certificate is given in an annex.

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA12770 for <[e-mail]>; Tue, 21 Sep 1999 22:21:49 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id PAA16844 for <[e-mail]>; Wed, 22 Sep 1999 15:25:11 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0JOyxd; Wed Sep 22 15:24:55 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id PAA25999 for <[e-mail]>; Wed, 22 Sep 1999 15:24:54 +1000 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd07oCap; Wed Sep 22 15:23:40 1999
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA02089 for <[e-mail]>; Wed, 22 Sep 1999 15:23:39 +1000 (EST)
Message-Id: <[e-mail]>
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <TK2BSJWP>; Wed, 22 Sep 1999 15:22:03 +1000
From: "Manger, James" <[e-mail]>
To: [e-mail]
Subject: RE: Timestamp: nonce field
Date: Wed, 22 Sep 1999 15:22:31 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF04BA.6683E010"

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_01BF04BA.6683E010
Content-Type: text/plain

The nonce field adds nothing.  It should be removed from the request &
timestamp token.  The messageImprint serves the desired purpose.

Replay attacks are not attacks for a timestamp.  A timestamp means "this
datum existed at this time", which implies it exists for all time beyond
this point as well (you could lose the datum but I don't think that is
relevant).  If you request a timestamp today but a timestamp for the same
message from last Monday is substituted... you know the datum existed before
last Monday, which is (always) better than knowing it existed before today.

Perhaps you want a new timestamp for the same message because you want it
signed with the TSA's new key, or you want a version 2 timestamp, or you
want a different policy, or you want an extension.  In all these cases, you
should not check for freshness but for your desired feature.

If all you want is a fresh timestamp as "signed time" it is still simple:
make up a random message (or a random hash) and get that timestamped.


------_=_NextPart_000_01BF04BA.6683E010
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IgQFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAbAAAAUkU6IFRpbWVzdGFtcDogbm9uY2UgZmllbGQANgkB
CYABACEAAABFM0JBQzcxNTc4NzBEMzExQkQyMjAwMTA0QjA4REJGMQAQBwEggAMADgAAAM8HCQAW
AA8AFgACAAMAHwEBBYADAA4AAADPBwkAFgAPABYAHwADADwBAQ2ABAACAAAAAgACAAEDkAYAtAYA
AB4AAAADAC4AAAAAAEAAOQAQnw14ugS/AR4AcAABAAAAJwAAAFRpbWUgU3RhbXBpbmc6IGNvbW1l
bnRzIG9uIG5vbmNlIGZpZWxkAAACAXEAAQAAABsAAAABvoDxkvvNIrfP7OQR0q4xAAjHJK3SIOxu
guYAAgEJEAEAAABCAwAAPgMAADwFAABMWkZ1cUhq9gMACgByY3BnMTI1/jIA/wIGAqQD5AXrAoMA
UBMDVAIAY2gKwHNldP4yBgAGwwKDDlAD1QcTAoBufQqACM8J2TsVjw4wNQ8CgAqBDnELYG5nMzAK
OABQaAWwemRvY7UAACoSVSACkRmQbBnFFwr7E7IMAWMAQCBUaKhlIG4CIGMckGYIkMBsZCBhZGQE
IBywBHRoC4BnLiAgSdUFQHMZAHUdQWIckBWQ3QRgdgmAHQADYSAd4B8S6nEKUHMFQCYf8AdyAZDk
bXAf8G9rCfAeMRxywQeBc2FnZUkhUAUQ/wIwHoAEkB9wBCAgAg5wAJBJFZEgcAhwcG8SsC7TCoUK
hVJlC1F5HWACQP0A0GsEIArAHJIFQCY2AhDtBcBhINgeMUEg2QeABiJWIh3hBCBkJjB1H+Bl+ngE
AHQfgSYwH/EqISDisCIsIHcd8BJwIAdwdwtQCJAEIGkFQCqzJ5Vs9wMgIOIe8XkCIB1QKgMkkLUi
8mEEIHcdMAMgKC6Q/HUgBaAewhUgErAjlCpjtGJ1BUBJI9ACICcrQzxuax/xKzEqIRWQbGWSdgBw
dCkeMmYgMCL/IEYn+SFxKlAmEDGyNQonsn8gAiJwLkEiRR+kC2AgkU3HLqEmASohc3ViIJAtANsx
wAmALjpgNDNrHLAH4P8xGCq2HwAnsRyQOMksBwQgyigHQHcmAHMpHvECQP8EkDLCA6A64h4BLPc8
KDXD7STdUASQEoBwBCAwIj5QPy9iHKAH0TaPN5wfAGNh3nUw4ULXLQEAkGdDgB1QhwPwHeAf81RT
QScdoX8H0SGgPWEFsULZH3ASoGldAiAgEuAg50jOZAaQZt8EkAnwBUAkkCywY0i+A6D/KrAq8ACB
AiAeMgOgLeMcgPcw4UXQErBzLAAwIh6VJvK/EnAFkDKwJ7IDUAeQaEOA/wQRMbInsjAhBcAj5kwg
KmH/FZAk3TQRLeJGOCaRUYQg2f0vkSJG9SuzLPI5giDgLfFTAJAskWU6IjBhIaAgfnVXER8gAHAZ
QB/gN/YovyfDWiUSgB6QPpBaMSAikP8rQisyIPY6QQqPG5gi0B3QLwWQBUBd1RSxAGCwAAADAP0/
UgMAAB4AQhABAAAANQAAADwwMDgyMDFiZTgwZGEkODFiYjE1NjAkYjAwMWE4YzBAZGMtMDcuY2Vy
ZXMuZm5tdC5lcz4AAAAAAwAmAAAAAAADADYAAAAAAB4AMUABAAAAEAAAAEpNQU5HRVIyOTI4OEVG
MwADABpAAAAAAB4AMEABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwADABlAAAAAAAIB+T8BAAAAZwAA
AAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAYAAAAvTz1URUxTVFJBL09VPVFMRCBLSU5HU0ZPUkQt
U01JVEgvQ049TVMgTUFJTCBSRUNJUElFTlRTL0NOPUpNQU5HRVIyOTI4OEVGMwAAHgD4PwEAAAAO
AAAATWFuZ2VyLCBKYW1lcwAAAB4AOEABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwACAfs/AQAAAGcA
AAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAGAAAAL089VEVMU1RSQS9PVT1RTEQgS0lOR1NGT1JE
LVNNSVRIL0NOPU1TIE1BSUwgUkVDSVBJRU5UUy9DTj1KTUFOR0VSMjkyODhFRjMAAB4A+j8BAAAA
DgAAAE1hbmdlciwgSmFtZXMAAAAeADlAAQAAABAAAABKTUFOR0VSMjkyODhFRjMAQAAHMMAhBE2j
BL8BQAAIMBDgg2a6BL8BHgA9AAEAAAAFAAAAUkU6IAAAAAAeAB0OAQAAABcAAABUaW1lc3RhbXA6
IG5vbmNlIGZpZWxkAAALACkAAAAAAAsAIwAAAAAAAwAGEEkWgjYDAAcQKgMAAAMAEBAAAAAAAwAR
EAEAAAAeAAgQAQAAAGUAAABUSEVOT05DRUZJRUxEQUREU05PVEhJTkdJVFNIT1VMREJFUkVNT1ZF
REZST01USEVSRVFVRVNUJlRJTUVTVEFNUFRPS0VOVEhFTUVTU0FHRUlNUFJJTlRTRVJWRVNUSEVE
RVNJAAAAAKTN

------_=_NextPart_000_01BF04BA.6683E010--


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA02105 for <[e-mail]>; Tue, 21 Sep 1999 06:14:50 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id PAA12412 for <[e-mail]>; Tue, 21 Sep 1999 15:18:25 +0200
Message-ID: <[e-mail]>
Date: Tue, 21 Sep 1999 15:18:04 +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: TSP version 03
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A new draft of the Time Stamping Protocol (TSP) has been published
at:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-03.txt

The draft attempts to accommodate the issues raised at the Oslo
meeting, comments received at the Oslo meeting and comments sent on
the PKIX mailing list.

Issues raised at the Oslo meeting: 

1) Format of the TSTTime (inspired form NTP)
2) TDA (Temporal Data Authority) support.

1) A new TSTTime has been defined. It fairly simple and composed of
two fields, one field using GeneralizedTime and allowing to specify
the time below the precision of a second and another optional field
allowing to specify the accuracy in seconds or sub-seconds when that
precision is *not* plus or minus one second. It is expected that
many TSA will not use the precision field and thus will produce the
time according to RFC 2459 section 4.1.2.5.2. with plus or minus one
second for the precision.

In addition the previous draft was attempting to provide a
chronology between two time stamps issued by the same TSA within the
same second (assuming sub-seconds were not used). This can now be
provided using the serial number which is being made mandatory.

2) At the last meeting I advertised that if no one would produce a
"good" rational for supporting TDAs, TDAs would be removed. Since
such a rational has not been produced, the extension has now been
suppressed. However, it has been realized that we make making the
same original mistake that X.509 did with the version 1: omitting to
provide an extension mechanism. So an extension field has been
added. This allows anyone (including ISO) to define extensions in
the future, without impacting *this* document. TDAs could even been
re-introduced at any time in the future, but using the extension
mechanism.

Comments received at the Oslo meeting

3) Steve Kent during the meeting said that we should not confuse a
Time Stamp with a time information and thus requested the hash in
the request to be mandatory. This is now done.

4) some people complained about the fact that the TSA was making its
own judgment about the validity of the hash function used by the
requester. This requirement has been partly raised since the TSA is
now only required to know the OID of the hash function to make sure
that the length of the hash code is correct. So the OIDs need to be
known, but the TSA offers no guarantee about the strength of the
hash functions (the legal responsibility has disappeared).

Note: The filling dates for all patents have been added and a
warning about the *use* of the protocol has been added.

As a result of all of this, the document is now simpler and shorter.

Denis


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA00509 for <[e-mail]>; Tue, 21 Sep 1999 03:56:23 -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 GAA27775; Tue, 21 Sep 1999 06:59:46 -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-time-stamp-03.txt
Date: Tue, 21 Sep 1999 06:59:45 -0400
Sender: [e-mail]

--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 Time Stamp  
                          Protocols (TSP)
	Author(s)	: C. Adams,  P. Cain, B. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-03.txt
	Pages		: 17
	Date		: 20-Sep-99
	
A time stamping service allows to prove that a datum existed before 
a particular time and can be used as a Trusted Third Party (TTP) as 
one component in building reliable non-repudiation services (see 
[ISONR]). This document describes the format of a request sent to a 
Time Stamping Authority (TSA) and of the response that is returned.
An example on how to prove that a digital signature was 
generated during the validity period of the corresponding public key 
certificate is given in an annex. In order to get additional 
confidence about the information returned by the TSA, an optional 
Temporal Data Authority (TDA) can add data to the response that 
proves in addition that a datum existed before a particular 
unpredictable event.

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA18435 for <[e-mail]>; Mon, 20 Sep 1999 13:57:49 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id OAA29818; Mon, 20 Sep 1999 14:01:08 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id OAA26440; Mon, 20 Sep 1999 14:01:08 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Grant, Alistair'" <[e-mail]>, <[e-mail]>
Cc: "'Daniel Lanz'" <[e-mail]>
Subject: RE: Huge CRLs
Date: Mon, 20 Sep 1999 14:04:23 -0700
Message-ID: <013301bf03ab$b76c6b10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Hi Alistair,
    On talking with Peter, it appears that I was not very clear
in my mail.

One of the things that OCSP allows you to do, is specify your
response type as part of the response. If your response type
is a CRT based response, then you don't need to sign the response,
since you provide the signature on the CRT itself as proof of the
validity of the response.

In short, when you get an OCSP request, you set the response-type
as a CRT based response and then include the CRT slice in the
response. This means that you don't sign the specific response,
so the creator of the CRT and the provider of the response can
be different entities - one with a private key (to sign the CRT)
and the other without any private key (since it is just doling
out responses based on a trusted CRT).

Hope this clarifies the issue,
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: Grant, Alistair [mailto:[e-mail]]
> Sent: Tuesday, September 14, 1999 6:17 PM
> To: [e-mail]
> Cc: Ambarish Malpani; 'Daniel Lanz'
> Subject: RE: Huge CRLs
> 
> 
> Hi Ambarish,
> 
> You wrote:
> 	    Basically, with OCSP, the responder needs to have its key
> 	available online to sign responses (you can mitigate 
> this risk to
> 	some extent by having a proxy between your responder 
> and the rest
> 	of the world, but it is still an issue). So you need to 
> make your
> 	responder available for people to talk to, but if anybody ever
> 	manages to break into your responder and get access to 
> your private
> 	key, your whole OCSP response system is open to compromise.
> 
> 	With CRTs, you can acctually have the Tree Issuer be 
> separate from
> 	the CRT responders. The Tree Issuer has access to your 
> CRT private
> 	key and can create new CRTs, which it then distributes to one or
> 	more CRT responders (which don't have the highly trusted private
> 	key), which actually provide the CRT responses.
> 
> I think I must be missing something, even with CRT's the OCSP 
> responder
> still has to sign its response, so the situation does not seem to be
> improved by the use of CRT's.
> 
> 
> Cheers,
> 
> Alistair Grant
> Phone:	[phone]
> Mobile:	[phone]
> Fax:  	[phone]
> E-Mail:	[e-mail]
> 
> > > -----Original Message-----
> > > From: Daniel Lanz [mailto:[e-mail]]
> > > Sent: Tuesday, September 14, 1999 7:57 AM
> > > To: 'Ambarish Malpani'
> > > Cc: [e-mail]
> > > Subject: RE: Huge CRLs
> > > 
> > > 
> > > 
> > > 
> > > >CRTs are a proprietary method to implement OCSP in a 
> more scalable
> > > >and secure way.
> > > 
> > > Ambarish,
> > > 
> > > How do CRTs make OCSP more secure?
> > > 
> > > Regards,
> > > 
> > > Dan Lanz
> > > 
> > > 
> > > 
> 


Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA16792 for <[e-mail]>; Mon, 20 Sep 1999 11:35:20 -0700 (PDT)
Received: from ronald.trustpoint.com (ronald@ronald [192.168.42.4]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id LAA28948 for <[e-mail]>; Mon, 20 Sep 1999 11:38:58 -0700
From: Ronald Tschalär <[e-mail]>
Received: (from ronald@localhost) by ronald.trustpoint.com (8.8.7/8.8.7) id LAA09540 for [e-mail]; Mon, 20 Sep 1999 11:38:57 -0700
Message-Id: <[e-mail]>
Subject: Re: FW: I-D ACTION:draft-ietf-pkix-cmp-tcp-00.txt
To: [e-mail]
Date: Mon, 20 Sep 1999 11:38:57 -0700 (PDT)
Content-Type: text

> The draft does not define any particular behavior for the client on
> receiving the errorMsgRep. I guess it should be more specific.

The behaviour is the same as for any other message.

> Should the client: 
> a)Close the connection regardless of the value of the 'close' bit

No!

> b)Close the connection only if the 'close' bit is set

Yes.

> Should it mundate the server to set the 'close' bit when replying with the
> errorMsgRep?

No. The server may decide if it wants to close the connection or not. The
protocol is defined in such a way that the full size of the request is known
(and the complete request can therefore be read and possibly thrown away)
even if, say, an unknown message-type or version is encountered. So, unless
something goes really wrong, the server can usually safely keep the connection
open.

> In general: can the connection be used after the server replied with the
> errorMsgRep?

Absolutely.


  Cheers,

  Ronald



Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by mail.proper.com (8.9.3/8.9.3) with SMTP id GAA13419; Mon, 20 Sep 1999 06:00:57 -0700 (PDT)
Received: by mailgate.rdg.opengroup.org; id AA03400; Mon, 20 Sep 1999 13:08:26 GMT
Received: from jeffrey.rdg.opengroup.org [192.153.166.172] by mailgate.rdg.opengroup.org via smtpd  V1.32 (99/03/30 12:28:06) for <[e-mail]> ; Mon Sep 20 14:08 BST 1999
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 20 Sep 1999 13:44:27 +0100
To: [e-mail], [e-mail], [e-mail]
From: Chris Harding <[e-mail]>
Subject: DirConnect5
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

DirConnect5 - Second Call

The theme of the forthcoming Open Group Members Meeting to be held in
Washington DC from 25th to 29th October is "Trust and Confidence in the
Global Infrastructure".  In addition to the meeting sessions we will hold a
DirConnect testing session from 26 - 28 October which will focus on the
directory and security interoperability required to support a trusted
infrastructure.

The testing will build upon the work done at DirConnect4 (Montreal, July)
which explored LDAP V3 functionality and the storage and retrieval of
certificates.

This event will provide the ideal environment for the detection and
resolution of interoperability problems that may have arisen through
different interpretations of the standard or implementation error.  This is
your chance as a developer of directory software to bring your application
to a workshop-style event and check that it really works with
implementations from your competitors.

As usual, only technical staff will be invited with marketing staff and
press explicitly excluded in order to create an environment where
implementors feel free to discuss technical details of their software. This
policy will be strictly observed and measures taken to maintain security.

DirConnect 5 will be held at The Embassy Suites Crystal City/National
Airport, 1300 Jefferson Davis Hwy, Arlington 22202 US, Tel: [phone].
The Embassy Suites Hotel is about three blocks from the Crystal City Hilton
where the Open Group Members Meeting will be held.

The facilities will include: Open room with tables, power, and connectivity
for participant systems; 10BaseT network; Connection to the Internet;
Buffet lunch served each day; Break food; Security for equipment left on site 

Cost of Attendance: The cost is $1000 per company for members of the Open
Group and $3500 for non-members.
Registration is per company, which is up to three people and three
computers. Additional people for a registered company can attend at a cost
of $350 per person. Due to space limitations of the event room, the event
is limited to 30 people total. We request that participants bring as few
people as possible to get the job done well (but to bring as many as are
needed!). This should not be an issue since many companies will send only
one or two people to the event.

For more details please contact Clive Betteridge
([e-mail]) or Chris Harding ([e-mail])



Regards,

Chris
+++++

-------------------------------------------------------------------------
           Chris Harding
  T H E    Development Manager
 O P E N   Apex Plaza, Forbury Road, Reading RG1 1AX, UK
G R O U P  Mailto:[e-mail]   Ph: [phone] x2262
           WWW: http://www.opengroup.org    Fx: [phone]  

OSF/1, Motif, UNIX and the "X" device are registered trademarks in
the US and other countries, and IT DialTone and The Open Group are
trademarks of The Open Group.
-------------------------------------------------------------------------


Received: from biltenmail.bilten.metu.edu.tr (biltenmail.bilten.metu.edu.tr [144.122.246.3]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id AAA08480 for <[e-mail]>; Mon, 20 Sep 1999 00:43:04 -0700 (PDT)
Received: from bilten.metu.edu.tr (DIGITALID.bilten.metu.edu.tr [144.122.246.106]) by biltenmail.bilten.metu.edu.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id SB0JR1AA; Mon, 20 Sep 1999 10:52:06 +0300
Message-ID: <[e-mail]>
Date: Mon, 20 Sep 1999 10:49:03 +0300
From: Ferda Topcan <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: About "draft-ietf-pkix-ipki-part1-07.txt"
Content-Type: text/plain; charset=iso-8859-9
Content-Transfer-Encoding: 7bit

Hello,

I look for a documentation with headline "Internet Public Key
Infrastructure X.509 Certificate and CRL Profile". This was a PKIX
Working Group Internet Draft.
A time ago, I downloaded  a part of this documentation from the address
of   "http://csrc.nist.gov/pki/draft-ietf-pkix-ipki-part1-07.txt". But
it is not available now. How can I obtain this documentation?

I try to create a X.509 certificate file. Do you know where can I find
more the detailed documentation about X.509 certificate creation?

Thank you,
Ferda TOPCAN



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA03865 for <[e-mail]>; Sun, 19 Sep 1999 19:43:11 -0700 (PDT)
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 MAA15599 for <[e-mail]>; Mon, 20 Sep 1999 12:48:50 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <TBXRS660>; Mon, 20 Sep 1999 12:47:13 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail]
Subject: FW: I-D ACTION:draft-ietf-pkix-cmp-tcp-00.txt
Date: Mon, 20 Sep 1999 12:47:10 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

The draft does not define any particular behavior for the client on
receiving the errorMsgRep. I guess it should be more specific.

Should the client: 
a)Close the connection regardless of the value of the 'close' bit
b)Close the connection only if the 'close' bit is set

Should it mundate the server to set the 'close' bit when replying with the
errorMsgRep?

In general: can the connection be used after the server replied with the
errorMsgRep?

To me, the simplest and inambigouos approach wold be (a), and the server IS
REQUIRED to set the 'close' bit when replying with the errorMsgRep.

MichaelZ


Received: from MAIL.NETCOM.COM (HSE-OTT-ppp30091.sympatico.ca [209.226.112.16]) by mail.proper.com (8.9.3/8.9.3) with SMTP id DAA03299; Sat, 18 Sep 1999 03:45:41 -0700 (PDT)
From: [e-mail]
Subject: Wealth at once!!
Date: Sat, 18 Sep 1999 03:08:18
Message-Id: <[e-mail]>

This is a one time message, if it reached you by mistake please accept 
my apologies, disregard and delete. Thank you.

Dear Entrepreneur:

Please take the time to read this. It can start you on the road to an 
easier life as an internet businessman/woman.
Thank you.



EBIZ = 1,2,3...4 CASH!

1.	READ THIS ALL THE WAY THROUGH!
2.	FOLLOW THE INSTRUCTIONS!
3.	GO BUY A BIG BAG...
4. 	ALL THE CASH!



THE PROGRAM
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

INCREDIBLE $0 to $50,000 in 90 days!!!

Dear Friend,

You can earn $50,000 or more in next the 90 days sending e-mail. Seem 
impossible? Read on for details.

"AS SEEN ON NATIONAL TV"
Thank you for your time and interest. This is the letter you've been 
reading about in the news lately.  Due to the popularity of this letter 
on the Internet, a major nightly news program recently devoted an entire 
show to the investigation of the program described below to see if it 
really can make people money.
The show also investigated whether or not the program was legal.  Their 
findings proved once and for all that there are absolutely no laws 
prohibiting the participation in the program. This has helped to show 
people that this is a simple, harmless and fun way to make some extra 
money at home.
The results of this show have been truly remarkable. So many people are 
participating that those involved are doing much better than ever 
before.  Since everyone makes more as more people try it out, it's been 
very exciting to be a part of it lately. You will understand once you 
experience it.

HERE IT IS BELOW:

*** Print This Now For Future Reference ***
The following income opportunity is one you may be interested in taking 
a look at. It can be started with VERY LITTLE investment and the income 
return is TREMENDOUS!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $50,000 in less than 90 days !
Please read the enclosed program...THEN READ IT AGAIN!!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not 
require you to come into contact with people, do any hard work, and best 
of all, you never have to leave the house except to get the mail. If you 
believe that someday you'll get that big break that you've been waiting 
for, THIS IS IT!  Simply follow the instructions, and your dreams will 
come true. This multi-level e-mail order marketing program works 
perfectly...100% EVERY TIME.
E-mail is the sales tool of the future. Take advantage of this 
non-commercialized method of advertising NOW!!! The longer you wait, the 
more people will be doing business using e-mail. Get your piece of this 
action!!!
MULTI-LEVEL MARKETING (MLM) has finally gained respectability.  It is 
being taught in the Harvard Business School, and both Stanford Research 
and the Wall Street Journal have stated that between 50% and 65% of all 
goods and services will be sold through multi-level methods by the mid 
to late 1990's.  This is a Multi-Billion Dollar industry and of the 
500,000 millionaires in the U.S., 20% (100,000) made their fortune in 
the last several years in MLM.  Moreover, statistics show 45 people 
become millionaires everyday through Multi-Level Marketing.
You may have heard this story before, but over the summer Donald Trump 
made an appearance on the David Letterman show. Dave asked him what he 
would do if he lost everything and had to start over from scratch. 
Without hesitating, Trump said he would find a good network marketing 
company and get to work. The audience started to hoot and boo him. He 
looked out at the audience and dead-panned his response:
"That's why I'm sitting up here and you are all sitting out there!"
The enclosed information is something I almost let slip through my 
fingers. Fortunately, sometime later I re-read everything and gave some 
thought and study to it. My name is Johnathon Rourke. Two years ago, the 
corporation I worked at for the past twelve years down-sized and my 
position was eliminated. After unproductive job interviews, I decided to 
open my own business. Over the past year, I incurred many unforeseen 
financial problems.  I owed my family, friends and creditors over 
$35,000.
The economy was taking a toll on my business and I just couldn't seem to 
make ends meet. I had to refinance and borrow against my home to support 
my family and struggling business. AT THAT MOMENT something significant 
happened in my life and I am writing to share the experience in hopes 
that this will change your life FOREVER FINANCIALLY!!!
In mid December, I received this program via e-mail. Six month's prior 
to receiving this program I had been sending away for information on 
various business opportunities. All of the programs I received, in my 
opinion, were not cost effective. They were either too difficult for me 
to comprehend or the initial investment was too much for me to risk to 
see if they would work or not. One claimed that I would make a million 
dollars in one year...it didn't tell me I'd have to write a book to make 
it!
But like I was saying, in December of 1997 I received this program. I 
didn't send for it, or ask for it, they just got my name off a mailing 
list. THANK GOODNESS FOR THAT!!! After reading it several times, to make 
sure I was reading it correctly, I couldn't believe my eyes. Here was a 
MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, 
without putting me further into debt. After I got a pencil and paper and 
figured it out, I would at least get my money back. But like most of you 
I was still a little sceptical and a little worried about the legal 
aspects of it all. So I checked it out with the U.S. Post Office 
(1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! 
After determining the program was LEGAL and NOT A CHAIN LETTER, I 
decided "WHY NOT."
Initially I sent out 10,000 e-mails. It cost me about $15 for my time 
on-line. The great thing about e-mail is that I don't need any money for 
printing to send out the program, and because all of my orders are 
fulfilled via e-mail, my only expense is my time. I am telling you like 
it is I hope it doesn't turn you off, but I promised myself that I would 
not "rip-off" anyone, no matter how much money it made me.
In less than one week, I was starting to receive orders for REPORT #1 By 
January 13, I had received 26 orders for REPORT #1. Your goal is to 
"RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, 
SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 
90 days was done.  By January 30, I had received 196 orders for REPORT 
#2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 
WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 
ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, 
I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and 
relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with 
more coming in every day.
I paid off ALL my debts and bought a much needed new car. Please take 
time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!  ! 
Remember, it won't work if you don't try it. This program does work , 
but you must follow it EXACTLY! Especially the rules of not trying to 
place your name in a different place. It won't work and you'll lose out 
on a lot of money!
In order for this program to work, you must meet your goal of 20+ orders 
for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 
or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!!
If you choose not to participate in this program, I am sorry. It really 
is a great opportunity with little cost or risk to you. If you choose to 
participate, follow the program and you will be on your way to financial 
security. If you are a fellow business owner and are in financial 
trouble like I was, or you want to start your own business, consider 
this a sign. I DID!
Sincerely,
Johnathon Rourke



A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM:
By the time you have read the enclosed program and reports, you should 
have concluded that such a program, and one that is legal, could not 
have been created by an amateur.
Let me tell you a little about myself. I had a profitable business for 
10 years. Then in 1979 my business began falling off. I was doing the 
same things that were previously successful for me, but it wasn't 
working. Finally, I figured it out. It wasn't me, it was the economy.  
Inflation and recession had replaced the stable economy that had been 
with us since 1945.I don't have to tell you what happened to the 
unemployment rate... because many of you know from first hand 
experience. There were more failures and bankruptcies than ever before.
The middle class was vanishing. Those who knew what they were doing 
invested wisely and moved up. Those who did not, including those who 
never had anything to save or invest, were moving down into the ranks of 
the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET 
POORER." The traditional methods of making money will never allow you to 
"move up" or "get rich", inflation will see to that.
You have just received information that can give you financial freedom 
for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF 
EFFORT." You can make more money in the next few months than you have 
ever imagined. I should also point out that I will not see a penny of 
this money, nor anyone else who has provided a testimonial for this 
program. I have already made over 4 MILLION DOLLARS!I have retired from 
the program after sending thousands and thousands of programs.
Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way . 
It works exceedingly well as it is now. Remember to e-mail a copy of 
this exciting report to everyone you can think of. One of the people you 
send this to may send out 50,000...and your name will be on everyone of 
them!
Remember though, the more you send out the more potential customers you 
will reach.
So my friend, I have given you the ideas, information, materials and 
opportunity to become financially independent. IT IS UP TO YOU NOW!
"THINK ABOUT IT"
Before you delete this program from your mailbox, as I almost did, take 
a little time to read it and REALLY THINK ABOUT IT. Get a pencil and 
figure out what could happen when YOU participate. Figure out the worst 
possible response and no matter how you calculate it, you will still 
make a lot of money! You will definitely get back what you invested. Any 
doubts you have will vanish when your first orders come in. IT WORKS!
Jody Jacobs, Richmond, VA
HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$
INSTRUCTIONS:
This method of raising capital REALLY WORKS 100% EVERY TIME.  I am sure 
that you could use up to $50,000 or more in the next 90 days. Before you 
say "BULL... ", please read this program carefully.
This is not a chain letter, but a perfectly legal money making 
opportunity. Basically, this is what you do: As with all multi-level 
businesses, we build our business by recruiting new partners and selling 
our products. Every state in the USA allows you to recruit new 
multi-level business partners, and we offer a product for EVERY dollar 
sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not 
involved in personal selling. You do it privately in your own home, 
store or office. This is the GREATEST Multi-Level Mail Order Marketing 
anywhere.
This is what you MUST do:
1. Order all 4 reports shown on the list below (you can't sell them if 
you don't order them).
* For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU 
ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in 
case of a problem) to the person whose name appears on the list next to 
the report.  MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE 
OF ANY MAIL PROBLEMS!
* When you place your order, make sure you order each of the four 
reports. You will need all four reports so that you can save them on 
your computer and resell them.
* Within a few days you will receive, via e-mail, each of the four 
reports. Save them on your computer so they will be accessible for you 
to send to the 1,000's of people who will order them from you.

2. IMPORTANT DO NOT alter the names of the people who are listed next to 
each report, or their sequence on the list, in any way other than is 
instructed below in steps "a" through "f" or you will lose out on the 
majority of your profits. Once you understand the way this works, you'll 
also see how it doesn't work if you change it. Remember, this method has 
been tested, and if you alter it, it will not work.
a. Look below for the listing of available reports.
b. After you've ordered the four reports, take this advertisement and 
remove the name and address under REPORT #4. This person has made it 
through the cycle and is no doubt counting their $50,000!  c. Move the 
name and address under REPORT #3 down to REPORT #4.  d. Move the name 
and address under REPORT #2 down to REPORT #3.  e. Move the name and 
address under REPORT #1 down to REPORT #2.  f.  Insert your name/address 
in the REPORT #1 position.
Please make sure you COPY ALL INFORMATION, every name and address, 
ACCURATELY!
3. Take this entire letter, including the modified list of names, and 
save it to your computer. Make NO changes to the instruction portion of 
this letter.
Your cost to participate in this is practically nothing (surely you can 
afford $20). You obviously already have an Internet connection and 
e-mail is FREE!


There are two primary methods of building your downline:
METHOD #1: SENDING BULK E-MAIL
Let's say that you decide to start small, just to see how it goes, and 
we'll assume you and all those involved send out only 2,000 programs 
each. Let's also assume that the mailing receives a 0.5% response. Using 
a good list the response could be much better. Also, many people will 
send out hundreds of thousands of programs instead of 2,000. But 
continuing with this example, you send out only 2,000 programs. With a 
0.5% response, that is only 10 orders for REPORT #1. Those 10 people 
respond by sending out 2,000 programs each for a total of 20,000. Out of 
those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 
2,000 programs each for a total of 200,000.
The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 
send out 2,000 programs each for a 2,000,000 total. The 0.5% response to 
that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. 
CASH!!! Your total income in this example is $50 + $500 + $5,000 + 
$50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 
1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND 
TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF 
EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000.  Believe 
me, many people will do just that, and more! By the way, your cost to 
participate in this is practically nothing.  You obviously already have 
an Internet connection and e-mail is FREE!!! REPORT #2 will show you the 
best methods for bulk e-mailing, tell you where to obtain free bulk 
e-mail software and where to obtain e-mail lists.


METHOD #2 - PLACING FREE ADS ON THE INTERNET
Advertising on the internet is very, very inexpensive, and there are 
HUNDREDS of FREE places to advertise. Let's say you decide to start 
small just to see how well it works. Assume your goal is to get ONLY 10 
people to participate on your first level. (Placing a lot of FREE ads on 
the Internet will EASILY get a larger response.) Also assume that 
everyone else in YOUR ORGANIZATION gets ONLY 10 downline members.
Follow this example to achieve the STAGGERING results below:
1st level-your 10 members with 
$5.......................................$50
2nd level--10 members from those 10 ($5 x 100)..................$500
3rd level--10 members from those 100 ($5 x 1,000)...........$5,000
4th level--10 members from those 1,000 ($5 x 10,000).....$50,000
THIS TOTALS ---------->$55,550
Remember friends, this assumes that the people who participate only 
recruit 10 people each. Think for a moment what would happen if they got 
20 people to participate! Most people get 100's of participants!  THINK 
ABOUT IT! For every $5.00 you receive, all you must do is e-mail them 
the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON 
ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR 
name and address on it will be prompt because they can't advertise until 
they receive the report!
AVAILABLE REPORTS
*** Order Each REPORT by NUMBER and NAME ***
Notes:
* ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT 
ACCEPTED.
* ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL.
* Make sure the cash is concealed by wrapping it in at least two sheets 
of paper. On one of those sheets of paper, include:
(a) the number & name of the report you are ordering, (b) your e-mail 
address, and (c) your name & postal address.
PLACE YOUR ORDER FOR THESE REPORTS NOW:

REPORT #1   "The Insider's Guide to Advertising for Free on the 
Internet'
ORDER REPORT #1 FROM
EBIZ 
PH2-45 Grenoble Drive
Toronto, Ontario
Canada   M3C 1C5

REPORT #2  "The Insider's Guide to sending Bulk E-Mail on the Internet.
ORDER REPORT #2 FROM:
C. Alexander
2315 Lava Dr.
San Jose, CA 95133


REPORT #3  "The secrets of Multilevel Marketing on the Internet.
ORDER REPORT #3 FROM:
P.G. Webb
16 Huntley Crescent
St. Catharines, Ontario
Canada, L2M 6E7


REPORT #4  "How to become a Millionaire Utilizing the Power of 
Multilevel Marketing on the Internet"
ORDER REPORT #4 FROM:
F.D. Hardy
22306 128th. ST. E.
Sumner, Wa. 98390-7634


About 50,000 new people get online every month!
******* TIPS FOR SUCCESS *******
* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the 
directions accurately.
* Send for the four reports IMMEDIATELY so you will have them when the 
orders start coming in because: When you receive a $5 order, you MUST 
send out the requested product/report.
* ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE.
* Be patient and persistent with this program. If you follow the 
instructions exactly, your results WILL BE SUCCESSFUL!
* ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED!

******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to 
guarantee your success:
If you don't receive 20 orders for REPORT #1 within two weeks, Continue 
advertising or sending e-mails until you do. Then, a couple of weeks 
later you should receive at least 100 orders for REPORT#2. If you don 
't, continue advertising or sending e-mails until you do. Once you have 
received 100 or more orders for REPORT #2, YOU CAN RELAX, because the 
system is already working for you, and the cash will continue to roll 
in!
THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you are placed in front 
of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching 
which report people are ordering from you. If you want to generate more 
income, send another batch of e-mails or continue placing ads and start 
the whole process again! There is no limit to the income you will 
generate from this business!
Before you make your decision as to whether or not you participate in 
this program. Please answer one question. DO YOU WANT TO CHANGE YOUR 
LIFE? If the answer is yes, please look at the following facts about 
this program:

1. You are selling a product which does not Cost anything to PRODUCE, 
SHIP OR ADVERTISE.
2. All of your customers pay you in CASH!
3. E-mail is without question the most powerful method of distributing 
information on earth. This program combines the distribution power of 
e-mail together with the revenue generating power of multi-level 
marketing.
4. Your only expense-other than your initial $20 investment-is your 
time!
5. Virtually all of the income you generate from this program is PURE 
PROFIT!
6. This program will change your LIFE FOREVER.

ACT NOW! Take your first step toward achieving financial independence.  
Order the reports and follow the program outlined above-SUCCESS will be 
your reward.
Thank you for your time and consideration.


PLEASE NOTE: If you need help with starting a business, registering a 
business name, learning how income tax is handled, etc., contact your 
local office of the Small Business Administration (a Federal Agency) 
1-800-827-5722 for free help and answers to questions. Also, the 
Internal Revenue Service offers free help via telephone and free 
seminars about business tax requirements. Your earnings are highly 
dependent on your activities and advertising. The information contained 
on this site and in the report constitutes no guarantees stated nor 
implied. In the event that it is determined that this site or report 
constitutes a guarantee of any kind, that guarantee is now void. The 
earnings amounts listed on this site and in the report are estimates 
only. If you have any questions of the legality of this program, contact 
the Office of Associate Director for Marketing Practices, Federal Trade 
Commission, Bureau of Consumer Protection in Washington, DC.
 
 
 
 
 
 


Received: from kftc.kftc.or.kr ([210.103.193.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA19262 for <[e-mail]>; Fri, 17 Sep 1999 19:19:10 -0700 (PDT)
From: [e-mail]
Received: from dpuppy ([210.103.193.168]) by kftc.kftc.or.kr (Netscape Messaging Server 3.6)  with SMTP id AAA2132 for <[e-mail]>; Sat, 18 Sep 1999 11:21:26 +0900
Message-ID: <00c901bf017c$8ee4e040$[e-mail]>
To: <[e-mail]>
Subject: 
Date: Sat, 18 Sep 1999 11:21:46 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C6_01BF01C7.FE357860"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_00C6_01BF01C7.FE357860
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

c3Vic2NyaWJlDQo=

------=_NextPart_000_00C6_01BF01C7.FE357860
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz
X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjAwLjIzMTQuMTAwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT2xvLiyIHNpemU9
Mj5zdWJzY3JpYmU8L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_00C6_01BF01C7.FE357860--



Received: from kftc.kftc.or.kr ([210.103.193.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA14026 for <[e-mail]>; Fri, 17 Sep 1999 18:00:32 -0700 (PDT)
From: [e-mail]
Received: from dpuppy ([210.103.193.168]) by kftc.kftc.or.kr (Netscape Messaging Server 3.6)  with SMTP id AAA1FD0 for <[e-mail]>; Sat, 18 Sep 1999 10:03:01 +0900
Message-ID: <006401bf0171$9a697d00$[e-mail]>
To: <[e-mail]>
Subject: 
Date: Sat, 18 Sep 1999 10:03:21 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01BF01BD.09C33CE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0061_01BF01BD.09C33CE0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

cWdqbGFza25na2w7YXNkbmdxamdhJ3NqZ2xhc2pnbGFzamcncWonb3Fqd29naidhbw0K

------=_NextPart_000_0061_01BF01BD.09C33CE0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz
X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjAwLjIzMTQuMTAwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT2xvLiyIA0Kc2l6
ZT0yPnFnamxhc2tuZ2tsO2FzZG5ncWpnYSdzamdsYXNqZ2xhc2pnJ3FqJ29xandvZ2onYW88L0ZP
TlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_0061_01BF01BD.09C33CE0--



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA10983 for <[e-mail]>; Fri, 17 Sep 1999 12:48:31 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id MAA18864; Fri, 17 Sep 1999 12:51:55 -0700 (PDT)
Received: from media ([192.168.3.125]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id MAA14090; Fri, 17 Sep 1999 12:51:55 -0700 (PDT)
Message-ID: <002a01bf0145$ce4828f0$[e-mail]>
From: "valicert" <[e-mail]>
To: "Grant, Alistair" <[e-mail]>, <[e-mail]>
Subject: Re: Huge CRLs
Date: Fri, 17 Sep 1999 12:49:51 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Alistair,

Ambarish is not at work today, so may not reply early; so let
me try to address your comment, as best as I can.

I use my experience of X.500 distributed directory design to
discuss the security relationships between OCSP and
information management techniques like CRTs. Just as X.500
has a security procedure for securing client access, so PKIX has
OCSP. Just as X.500 has another security procedure (DSP)  for
server-server cooperation, so we use CRTs. X.500 has
additional secured protocols for DIB partion
replication, also. CRTs also facilitate partioning,
replication, and failure-tolerant partition
synchronization as a core  value.

As Phil said the other day, a client can access
an OCSP responder, and a not standardized "backend" thing
at the server talks to the source of status information.
This design of this backend thing and its integration
with OCSP has security  implications concerning the integrity
and fidelity of the status information delivered by the OCSP
channel.

In one ValiCert design of a distributed repository,
the CRT-based "backend thing" addressed the needs
for confirmed integrity of the server-server channel
used to distribute status information to the autonomous
OCSP servers.  It was assumed that these
servers would need to respond in an offline mode to queries,
and would not necessarily maintain a connection to the
source of status information.  (This is just
one mode, note. Other customers have different
connectivity and chained-OCSP
responsibility requirements.)

Two customers specifically required that we show
we had technical means deployed to show
the "fidelity" of the status values delivered at the
OCSP server . It was necessary to provide
assurace that the OCSP response would be consistent
with a given CRL source, and no other, at the
the various OCSP access points. This was critical
to their distributed security model. They did
not want the CA's more uptodate status db to
signal to clients; they wanted the
CRL, and only the CRL-status to be signaled. (This
is just one mode, note. Other knowlegeable
customers have different requirements.)

Hope this addresses your question.

-----Original Message-----
From: Grant, Alistair <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: Ambarish Malpani <[e-mail]>; 'Daniel Lanz'
<[e-mail]>
Date: Friday, September 17, 1999 9:53 AM
Subject: RE: Huge CRLs


>Hi Ambarish,
>
>You wrote:
>     Basically, with OCSP, the responder needs to have its key
> available online to sign responses (you can mitigate this risk to
> some extent by having a proxy between your responder and the rest
> of the world, but it is still an issue). So you need to make your
> responder available for people to talk to, but if anybody ever
> manages to break into your responder and get access to your private
> key, your whole OCSP response system is open to compromise.
>
> With CRTs, you can acctually have the Tree Issuer be separate from
> the CRT responders. The Tree Issuer has access to your CRT private
> key and can create new CRTs, which it then distributes to one or
> more CRT responders (which don't have the highly trusted private
> key), which actually provide the CRT responses.
>
>I think I must be missing something, even with CRT's the OCSP responder
>still has to sign its response, so the situation does not seem to be
>improved by the use of CRT's.
>
>
>Cheers,
>
>Alistair Grant
>Phone: [phone]
>Mobile: [phone]
>Fax:  [phone]
>E-Mail: [e-mail]
>
>> > -----Original Message-----
>> > From: Daniel Lanz [mailto:[e-mail]]
>> > Sent: Tuesday, September 14, 1999 7:57 AM
>> > To: 'Ambarish Malpani'
>> > Cc: [e-mail]
>> > Subject: RE: Huge CRLs
>> >
>> >
>> >
>> >
>> > >CRTs are a proprietary method to implement OCSP in a more scalable
>> > >and secure way.
>> >
>> > Ambarish,
>> >
>> > How do CRTs make OCSP more secure?
>> >
>> > Regards,
>> >
>> > Dan Lanz
>> >
>> >
>> >



Received: from nw171.netaddress.usa.net (nw171.netaddress.usa.net [204.68.24.71]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA09949 for <[e-mail]>; Fri, 17 Sep 1999 11:28:28 -0700 (PDT)
Received: (qmail 23707 invoked by uid 60001); 17 Sep 1999 18:32:01 -0000
Message-ID: <[e-mail]>
Received: from 204.68.24.71 by nw171 for [12.75.155.31] via web-mailer(M3.3.0.77) on Fri Sep 17 18:32:01 GMT 1999
Date: 17 Sep 99 12:32:01 MDT
From: TJ Swalla <[e-mail]>
To: [e-mail]
Subject: pki marketshare data
X-Mailer: USANET web-mailer (M3.3.0.77)
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 LAA09950

Does anyone know where I can find informative, reliable data on PKI regarding
marketshare data and projections?  I am writing a research paper on PKI and
would like to know of any good sources for market research.

Thank you for your time and continue talking about huge CR

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA09027 for <[e-mail]>; Fri, 17 Sep 1999 10:03:35 -0700 (PDT)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI7RJX00.DMC for <[e-mail]>; Fri, 17 Sep 1999 17:07:09 +0000 
Received: from nma.com ([209.21.28.105]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI7QMG00.0BK; Fri, 17 Sep 1999 16:47:04 +0000 
Message-ID: <[e-mail]>
Date: Fri, 17 Sep 1999 10:07:06 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <v04020a02b4059bc76fed@[128.33.238.12]> <v04020a0eb406d0c5ecd8@[128.33.238.30]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed Gerck wrote (in part):
> > The point I mentioned above is the delay between a need to revoke a
> > cert (which need is materialized at the CA as request to revoke, of
> > course), and the reflection of this need in a certificate chain with
> > different CAs.  This is the real-world issue here -- and one which is
> > not addressed.
>
> I presume you mean not addressed in specific CA CPS.  That's a business
> matter.  if clients demand this as a part of doing business with a CA, then
> CAs will do it.  I'm not even sure how widely this is true, i.e., how many
> CA CPSs have you reviewed in coming to this conclusion?

All I could. I see that you have not seen one that does that either, otherwise
I am sure you would quote it.  Whether this is a business issue or not, I suggest
a litmus test:

Suppose you contract with a limo service to take any of *your potential clients*
from downtown to your shop, so that you rely on the limo to take *your clients*
to you and not to the a spoof shop or to the swamp,  but for which service the
provider would say -- "if I know that my limos which I provide to you as a paid
service are not going to your shop with your potential clients, either because
you tell me so or because I find it out, I am under no obligation to issue a
service revocation to my drivers within any specific time limit and may do so
as I happen to do it".  Would you contract it?

> >> >Also, requiring the user to check with a CA before sending a message
> >> >makes the use of multiple CAs much more difficult, unless they can be
> >> >convinced to work together, an interesting problem for competing
> >> >businesses.  Constant checking with a single CA also makes traffic
> >> >analysis much easier. Even if the attacker cannot intercept the
> >> >message which is sent, if the attacker can monitor the central CA
> >> >(with a single administrative order and a GAKware system to circumvent
> >> >any encryption), everyone's communication patterns can be seen.
> >> >Also, an attacker can fool a CA into revoking a key -- a denial of service
> >> >attack.
> >>
> >> First, one does not "check with a CA" under the traditional CRL model.
> >
> >Neither did I say so -- but, requiring it won't be so useful because it makes
> >the use of multiple CAs more difficult and so on.  So, back to point one.
>
> Yes, Ed, you did say so! The triple-indented text above is yours.

But not the ending, Steve -- the "under the traditional CRL model" part is of your
vintage.  So, that is why I wrote that "requiring it won't be so useful", where you may
note the future tense of the phrase employed by myself. In other words, what I am
saying is that after we see all the shortcomings of the present CRL usage model
in actual protocols (as I summarized in that posting and you have by now agreed
that the cited problems do exist -- though you say that some of them are to be dealt
elsewhere), then I commented that it will not be useful to solve them by requiring
so and so.  One of the "so and so" that I disfavored was to check with a CA
before every transaction.

I hope it is clear now. There are problems, but requiring to check with a CA won't be
so useful to solve it.  And, of course, Kansas already went bye-bye -- the traditional
CRL model is in the past.

Cheers,

Ed Gerck
______________________________________________________________________
http://www.mcg.org.br/authors/eg.htm                    [e-mail]




Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA08777 for <[e-mail]>; Fri, 17 Sep 1999 09:56:56 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xma011911; Fri, 17 Sep 99 12:59:35 -0400
Received: from siac.com (localhost [127.0.0.1]) by charley.wisdom.siac.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA12147; Fri, 17 Sep 1999 12:59:30 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 17 Sep 1999 12:59:30 -0400
From: Daniel Alex Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61C-SGI [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: I changed my mind (Re: Huge CRLs)
References: <v04020a03b4002a7dc532@[128.89.0.111]> <v04020a04b406a9277120@[128.33.238.30]>
Content-Type: multipart/alternative; boundary="------------A5DB35066A78BE28B690F89B"

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

Stephen Kent wrote:

> In part, the problem is that the financial services environment is quite diverse and thus no single characterization of requirements is appropriate. One can argue that the current use of SSL and certs (even without CRLs!) to secure access for home banking, online tradeing, and online porfolio management are all "financial service" applications and this use works well enough to have spurred very significant activity in these areas. By that measure, the problem is solved :-).
>

Yes, I was completely disregarding the penetration of cryptographic security into public domain (SSL-enabled transactions and, to a much more limited extent, the distribution of certificates from commercial CA's like Verisign et alii). This was not intentional. My sights were very narrowly focussed on inter- and intra-business applications, reflecting my personal interest.

>
> SET makes very limited use of CRLs, because its design does not require much in the way if propogating revocation data, vs. local checking. It would seem that that financial app doesn't pose requirements that exceed the capabilities of the existing CRL mechanisms. On the other hand, one can certainly define PKI-based apps that pose such great demands on timely knbowledge of cert status, and which involve such a large community, that it may be very difficult, perhaps impractical, to meet these requirements with CRLs in any form. In the final analysis, PKIs are not the solution for all problems, though one generally derives great benefit from leveraging standards and widely available products that meet those standards.

That's very important to us, especially as we have found that even slight deviations from standards may cause dramatic failures. And also, exploits into areas not addressed by standards can do the same. But standards have generally been designed along a technical line rather than a business line. This was well and good just to establish the technology, however as we identify business requirements we find that technology has tried to take the lead and isn't terribly applicable to our business models. Form follows function, if you will.

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



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Stephen Kent wrote:
<blockquote TYPE=CITE>In part, the problem is that the financial services
environment is quite diverse and thus no single characterization of requirements
is appropriate. One can argue that the current use of SSL and certs (even
without CRLs!) to secure access for home banking, online tradeing, and
online porfolio management are all "financial service" applications and
this use works well enough to have spurred very significant activity in
these areas. By that measure, the problem is solved :-).
<br>&nbsp;</blockquote>
Yes, I was completely disregarding the penetration of cryptographic security
into public domain (SSL-enabled transactions and, to a much more limited
extent, the distribution of certificates from commercial CA's like Verisign
<i>et alii</i>). This was not intentional. My sights were very narrowly
focussed on inter- and intra-business applications, reflecting my personal
interest.
<blockquote TYPE=CITE>&nbsp;
<br>SET makes very limited use of CRLs, because its design does not require
much in the way if propogating revocation data, vs. local checking. It
would seem that that financial app doesn't pose requirements that exceed
the capabilities of the existing CRL mechanisms. On the other hand, one
can certainly define PKI-based apps that pose such great demands on timely
knbowledge of cert status, and which involve such a large community, that
it may be very difficult, perhaps impractical, to meet these requirements
with CRLs in any form. In the final analysis, PKIs are not the solution
for all problems, though one generally derives great benefit from leveraging
standards and widely available products that meet those standards.</blockquote>
That's very important to us, especially as we have found that even slight
deviations from standards may cause dramatic failures. And also, exploits
into areas not addressed by standards can do the same. But standards have
generally been designed along a technical line rather than a business line.
This was well and good just to establish the technology, however as we
identify business requirements we find that technology has tried to take
the lead and isn't terribly applicable to our business models. Form follows
function, if you will.
<pre>--&nbsp;
Daniel Alex Finkelstein
Shared IT Services
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>

--------------A5DB35066A78BE28B690F89B--



Received: from usilms20.cai.com (mail3.cai.com [141.202.248.42]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA08396 for <[e-mail]>; Fri, 17 Sep 1999 09:44:54 -0700 (PDT)
Received: by usilms20.cai.com with Internet Mail Service (5.5.2448.0) id <TDAGD23S>; Fri, 17 Sep 1999 12:36:16 -0400
Message-ID: <[e-mail]>
From: "Grant, Alistair" <[e-mail]>
To: [e-mail]
Cc: Ambarish Malpani <[e-mail]>, "'Daniel Lanz'" <[e-mail]>
Subject: RE: Huge CRLs
Date: Tue, 14 Sep 1999 21:17:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Hi Ambarish,

You wrote:
	    Basically, with OCSP, the responder needs to have its key
	available online to sign responses (you can mitigate this risk to
	some extent by having a proxy between your responder and the rest
	of the world, but it is still an issue). So you need to make your
	responder available for people to talk to, but if anybody ever
	manages to break into your responder and get access to your private
	key, your whole OCSP response system is open to compromise.

	With CRTs, you can acctually have the Tree Issuer be separate from
	the CRT responders. The Tree Issuer has access to your CRT private
	key and can create new CRTs, which it then distributes to one or
	more CRT responders (which don't have the highly trusted private
	key), which actually provide the CRT responses.

I think I must be missing something, even with CRT's the OCSP responder
still has to sign its response, so the situation does not seem to be
improved by the use of CRT's.


Cheers,

Alistair Grant
Phone:	[phone]
Mobile:	[phone]
Fax:  	[phone]
E-Mail:	[e-mail]

> > -----Original Message-----
> > From: Daniel Lanz [mailto:[e-mail]]
> > Sent: Tuesday, September 14, 1999 7:57 AM
> > To: 'Ambarish Malpani'
> > Cc: [e-mail]
> > Subject: RE: Huge CRLs
> > 
> > 
> > 
> > 
> > >CRTs are a proprietary method to implement OCSP in a more scalable
> > >and secure way.
> > 
> > Ambarish,
> > 
> > How do CRTs make OCSP more secure?
> > 
> > Regards,
> > 
> > Dan Lanz
> > 
> > 
> > 


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA08317 for <[e-mail]>; Fri, 17 Sep 1999 09:38:27 -0700 (PDT)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI7QE000.MMU for <[e-mail]>; Fri, 17 Sep 1999 16:42:00 +0000 
Received: from nma.com ([209.21.28.105]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI7PGJ00.5AW; Fri, 17 Sep 1999 16:21:55 +0000 
Message-ID: <[e-mail]>
Date: Fri, 17 Sep 1999 09:41:57 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Huge CRLs
References: <[e-mail]> <v04020a0db406cf5e9811@[128.33.238.30]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed Gerck wrote:
> >However, there is no corresponding list sent in the other direction (from
> >the client to
> >the server) as allowed by the SSL protocol.  The effect of this **SSL
> >asymmetry** is
> >that which I summarized above: SSL does not [allow the client] to check
> >revocation lists
> >[that are meaningful to the client].
>
> SSL is an asymmetric protocol; it treats clients and servers differently,
> as opposed to IPsec, which treats both ends a peers.

Yes, but let us not get into IPSEC now ;-) since IMO IPSEC also treats the
man-in-the-middle as a peer ;-)

> However, despite your
> repeated protests to the contrary, it is not the case that SSL does not
> allow clients from checking CRLs; it merely does not provide a mechanism
> for transporting CRLs as part of the protocol.

Yes, I believe we calmly agree that there is something fishy about SSL's
treatment of the client's "rights" compared to the server's.

But, as I see it, being forced to choose from one option is not an option for
*checking* -- and this is because I don't see a  trust-value in "trust me" or
self-declarations.  Trust is that which cannot be self-declared  -- as known in
business, trust is not simply given away, it must be earned.  The same
happens in a formal treatment of this subject when trust is as well-defined
as information in Shannon's theory, and not a bit more emotional -- please
see Peter William's book, page 194 and references.

>  Some protocols do provide
> such a facility, e.g., IPsec and S/MIME, but even here this is an optional
> facility.  Since one may fetch CRLs by various transport mechanisms, it is
> not unreasonable to treat CRL transport as a separate facility.

Yes, and IMO this is one the central ideas that need to be emphazised: a CRL
is not just an attribute of a certificate (ie, the cert is valid if not in the CRL).
A CRL is a  *different information token*, requiring a different channel if a
trust-value is to be assignable to it.

> >Agreed and let's not forget TSL as another element of this letter soup. But
> >SSL (TSL) is a tool used in https, which means that one should *first* deal
> >with some SSL (TSL) quirks like the client-server certificate choice
> >asymmetry I mentioned.
>
> The acronym is TLS, not TSL, unless you are referring to some protocol not
> developed under the IETF umbrella.

God forbid! No, it was just a simple mistype.  Thanks for catching it implicitly.

Cheers,

Ed Gerck
______________________________________________________________________
http://www.mcg.org.br/authors/eg.htm                    [e-mail]




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA06115 for <[e-mail]>; Fri, 17 Sep 1999 06:23:46 -0700 (PDT)
Received: from [128.89.0.111] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA22829; Fri, 17 Sep 1999 09:26:52 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a0eb406d0c5ecd8@[128.33.238.30]>
In-Reply-To: <[e-mail]>
References: <v04020a03b4002a7dc532@[128.89.0.111]> <v04020a02b4059bc76fed@[128.33.238.12]>
Date: Thu, 16 Sep 1999 13:11:08 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Huge CRLs
Cc: [e-mail], [e-mail], [e-mail]

Ed,

>Still, all that you say offers no justification (besides denying liability
>for it) why
>couldn't CAs provide upper limits for *their* delays.  Forget about
>"discovery delay"
>and other things that you mention and which I consider philosophical since
>they can
>never be even estimated, and forget also about how often will the CA issue the
>same stale CRL (maybe, even every second if you wish).  The point I mentioned
>above is the delay between a need to revoke a cert (which need is
>materialized at
>the CA as request to revoke, of course), and the reflection of this need in a
>certificate chain with different CAs.  This is the real-world issue here
>-- and one
>which is not addressed.

I presume you mean not addressed in specific CA CPS.  That's a business
matter.  if clients demand this as a part of doing business with a CA, then
CAs will do it.  I'm not even sure how widely this is true, i.e., how many
CA CPSs have you reviewed in coming to this conclusion?

>> >Also, requiring the user to check with a CA before sending a message
>> >makes the use of multiple CAs much more difficult, unless they can be
>> >convinced to work together, an interesting problem for competing
>> >businesses.  Constant checking with a single CA also makes traffic
>> >analysis much easier. Even if the attacker cannot intercept the
>> >message which is sent, if the attacker can monitor the central CA
>> >(with a single administrative order and a GAKware system to circumvent
>> >any encryption), everyone's communication patterns can be seen.
>> >Also, an attacker can fool a CA into revoking a key -- a denial of service
>> >attack.
>>
>> First, one does not "check with a CA" under the traditional CRL model.
>
>Neither did I say so -- but, requiring it won't be so useful because it makes
>the use of multiple CAs more difficult and so on.  So, back to point one.

Yes, Ed, you did say so! The triple-indented text above is yours.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA06094 for <[e-mail]>; Fri, 17 Sep 1999 06:23:39 -0700 (PDT)
Received: from [128.89.0.111] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA22820; Fri, 17 Sep 1999 09:26:46 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a0db406cf5e9811@[128.33.238.30]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 16 Sep 1999 12:52:14 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Huge CRLs
Cc: [e-mail]

Ed,

<snip>

>However, there is no corresponding list sent in the other direction (from
>the client to
>the server) as allowed by the SSL protocol.  The effect of this **SSL
>asymmetry** is
>that which I summarized above: SSL does not [allow the client] to check
>revocation lists
>[that are meaningful to the client].

SSL is an asymmetric protocol; it treats clients and servers differently,
as opposed to IPsec, which treats both ends a peers.  However, despite your
repeated protests to the contrary, it is not the case that SSL does not
allow clients from checking CRLs; it merely does not provide a mechanism
for transporting CRLs as part of the protocol.  Some protocols do provide
such a facility, e.g., IPsec and S/MIME, but even here this is an optional
facility.  Since one may fetch CRLs by various transport mechanisms, it is
not unreasonable to treat CRL transport as a separate facility.

<snip>

>
>
>> It may be time to standardize https which is a hypermedia security
>> service, is really quite complex, and addresses framed security
>> contexts, multiple sessions, connection teardown, host-id
>> selection of keying material on the server, and various other
>> matters peculiar to stateless web behavior in the context
>> of hypermedia documents.
>
>Agreed and let's not forget TSL as another element of this letter soup. But
>SSL (TSL) is a tool used in https, which means that one should *first* deal
>with some SSL (TSL) quirks like the client-server certificate choice
>asymmetry I mentioned.

The acronym is TLS, not TSL, unless you are referring to some protocol not
developed under the IETF umbrella.

Steve


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA05071 for <[e-mail]>; Fri, 17 Sep 1999 05:11:26 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA00333; Fri, 17 Sep 1999 08:15:14 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA00292; Fri, 17 Sep 1999 08:15:14 -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 IAA22123; Fri, 17 Sep 1999 08:14:37 -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 IAA07327; Fri, 17 Sep 1999 08:12:26 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 17 Sep 1999 08:12:26 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Huge CRLs
To: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: fIMLO9OrPkWIzR5pmWu5hw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Ambarish Malpani" <[e-mail]>
> 
> Hi Dave,
>     A few incorrect statements in your mail:


Yes, I must have been thinking of a different protocol; one which
had only one cert per request, and which linked requests and responses
with a transaction ID.  That's not OCSP.

Regards,
Dave



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA24630 for <[e-mail]>; Thu, 16 Sep 1999 14:46:41 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id OAA12929; Thu, 16 Sep 1999 14:50:07 -0700 (PDT)
Received: from rsalaptop ([192.168.3.229]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id OAA24069; Thu, 16 Sep 1999 14:50:06 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Date: Thu, 16 Sep 1999 14:52:12 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Russ,

The following msg is long; it should take about 5 minutes
to read. It mainly recapitulates into a more organized fashion
what has been previously stated. The cogency of the argument
is now available for acceptance or denial. Accept
it or deny it, I'm always excited to help form
and then follow the adjudged consensus.

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Thursday, September 16, 1999 12:58 PM
> To: Peter Williams
> Cc: [e-mail]
> Subject: RE: End-Entity Certificate Policies
>
>
> Peter:
>
> Thanks for the tutorial on the process you use to determine
> whether or not
> to trust a particular "new root."

The "tutorial" was merely the policy inspection process advised
by RFC 1422 for Internet user subscribers, and promoted today as
good consumer practice in the e-commerce PKI world. It featured as
its technical mechanism nothing but RFC 2459 standardized
elements, used as intended.

These mechanisms included using policy qualifiers as intended
by ISO and by PKIX: I merely reinforced (IMESHO) what the designers
intended, what the interested parties understood when
making the agreements to them, and upon whose agreement
millions of dollars of investment were made to implement
those standards.

My own understanding of all this, as a mere peon, is based
on having read the public disclosures and arguments on the
topics, which were voluminous. It is also based on my having
probably been the cause of the use of the qualifier
in this manner, being the person who architected
the first generation of VeriSign certificates which
featured this usage as an specific innovation. I think
these facts legitimatize my opinion. But perhaps not.

I would be highly influenced in take another position if
any of the original proponents would chime up, with
non-vacuous rationale, to repudiate their earlier
support and deployment choices : Microsoft, Netscape,
VeriSign?

Now, I pointed out that the debate on the appropriateness
of the policy qualifier techniques described has already
happened, and was agreed to by the RFC 2459 WG, and
IESG.  Apparently, from your own admission, you
voiced concerns about the very concept at the time, and
the backdoor consensus in the author group was to over-ride
your concerns  - presumably in light of other factors.

I also suggested that in fixing a bug, as a principle,
we should not indirectly or incidentally deprecate a
working, fielded and valued mechanism; nor should we in
any way disparage its value or utility. As policy rules
are intended to be a operational matter in PKIX, we should be
encouraging diversity and experimentation in PKI-based rule
systems, whilst also encouraging technical
compliance with mechanical processing algorithms.
However, fixing a bug in said algorithm should
not lose us the goal...

To conclude my recapitulation, you asked if anyone but
Michael Baum objected, and I answered yes.  The thread
shows that Michael Myers also objects. Another source
articulated the core value, without prompting.


 Your use of qualifiers that
> has nothing
> to do with certificate path validation.  So, would it be fair to say they
> you believe that qualifiers in CA certificates are useful for determing
> whether or not to trust that CA, but that they have no impact on
> certificate path processing?

Certificate path processing is but one activity performed by
a recipient. But to answer your question as posed: yes I believe
qualifiers have no impact on ISO cert path processing; and their rules
should not specify a change to that process.  ISO path
processing is a process of matching or selecting RP and CA policy id
requirements, only. Its a fancy policy id matching rule, not
a technique for security enforcement. This opinion is
based on private conversations with those who wrote it,
and edited the standard.

As we know from the standard, a set of outputs of the ISO
path processing algoirhtm are generated, to be used by the
recipient in taking a security decision. Path validity checking
using the ISO algorithm is not sufficient to use the certificate
in a manner conforming with the policies *rules*; it merely handles the
matching of policy choices. Other signals are combined with
those outputs to make a policy-based decision. As we known,
these signals may invalidate the use of the certificate, even
though the ISO processing algorithm is happy. EKU, and Key
Usage are cases in question. Other non-critical private
extension may also control; that whats the Internet PKI
is all about.

Peter.




>
> Russ
>
>
> At 11:55 AM 9/10/99 -0700, Peter Williams wrote:
>
> > > Since the certificate validation algorithm does not use
> > > certificate policy
> > > qualifiers, how do certificate policy qualifiers in CA
> certificates help
> > > the certificate user?
> >
> >
> >Every so often, I receive in my S/MIME client a msg originated
> >by someone belonging to a certification domain that
> >I neither know, or trust. In general, they are RFC 2459 complying
> >CAs, doing what RFC 2459 seeks.
> >
> >The fact that I receive these  is probably based on the fact that
> >I co-authored an applied digital certificates book,
> >suggesting people go out and deploy RFC 2459 and SET
> >CAs (horror!): It  helped provide lots or practical know-how
> >enabling cheap experimental deployment using mass-market software. People
> >sometimes send me their results, proudly. (I rarely,
> >if ever, see their names on this list.)
> >
> >Anyway, my S/MIME tool (which uses a well-known mass market
> >certificate manager tool and crypto library) enables me to
> >label the inbound certificates as trusted. I can learn a
> >root, if you like. Some of the CA certs are self-signed, some
> >are intermediate  CAs in a chain that does not happen to
> >include the TLCA for  their domains.
> >
> >To decide to trust it, I inspect the certificate.  I,
> >and my "auditor" make an accreditation judgment on
> >its trustworthiness, much like CAs confirm the identify
> >and obligations of CAs during PKIX3-specified
> >cross-certification.
> >
> >Acting much as a professional security administrator in any
> >large enterprise, I am as capable of taking this
> >accreditation decision as any commercial CA might do on
> >my behalf.
> >
> >To finalize the decision, I sign a list of my
> >trusted roots which controls their use in my S/MIME client.
> >The signed trust list acts, effectively, as my personal CA
> >which controls inter-domain trust; conforming path
> >processing ensures both trusted interworking and
> >policy recognition during  S/MIME msg handling, when
> >I choose to use conforming rules. As per 2459, I
> >can turn off conforming rule processing, when
> >required.
> >
> >What use are the qualifier? Russ asks.
> >
> >During inspection, the CPS pointer identifies to
> >me the PEM-style policy elements which I used to evaluate
> >the trustworthiness of the domain, as recommended by
> >the designers of RFC 1422, whose basic ideas are incorporated
> >into RFC 2459 by charter directive.
> >
> >In some cases, the certificate identifies
> >one or more certificate policies.  In other
> >cases it identifies one or more combined certificate policy
> >and CPSs. I have to wade through the various declarations to make my
> >decision deciding whether or not
> >to extend trust, given goals of my own security program.
> >The know-how to do this is about as complex as designing
> >for NR. I use the PKIX-IV recommendations to do this,
> >as one would expect.
> >
> >I understand from friends in companies who
> >use other mass-market software, and who use the
> >other RFC 2459 qualifier which points to
> >Warwick Ford's (WG-ratified) scheme for locating
> >policy description fragments embedded in compound
> >documents, that they use that facility for purposes
> >similar to those that I described for the CA-cert
> >hosted URL.
> >
> >So, if nothing else, CA qualifiers are very valuable
> >in the actual Internet PKI for learning trust-points,
> >and taking accreditation decisions based on evaluation
> >and recognition of policy. The use of explicit
> >accreditation is a well-established technique,
> >advised by reputable organizations such as NIST.
> >
> >It is true that I never use certificate path processing
> >during this inspection and accreditation process; but then
> >path processing was not designed for, and is not
> >useful for, such an accreditation process. I would never
> >use mandatory access control lattice implementation when
> >accrediting a certified B2 OS product for use in my site,
> >either!
> >
> >Hope this helps; its reality, and it works using at least
> >two different mass-market software implementations that work
> >largely according to the design and specification of RFC2459.
> >The scheme is voluntary and optional. Only those
> >interworking parties that recognize the (qualified) policy
> >are affected. Those that do not recognize the a (qualified)
> >policy, are  unaffected, if they use conforming implementations.
> >
> >Therefore policy controls interworking by instrumenting
> >the accreditation, which is aided by the qualifiers, just as
> >one would expect. Much of the experience of NIST (and NSA)
> >is now implemented in the Internet PKI environment, supporting,
> >as is culturally required: autonomous operations, experimentation,
> >and multi-vendor implementations that interwork at least
> >a minimal level, and by default.
> >
> >"I find qualifiers useful to provide exact information about
> certain policy
> >elements." [another]
> >
> >Peter.
>



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA22868 for <[e-mail]>; Thu, 16 Sep 1999 12:55:57 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (207-172-49-29.s29.tnt7.lnhva.md.dialup.rcn.com [207.172.49.29]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA26806; Thu, 16 Sep 1999 12:52:02 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 16 Sep 1999 15:57:48 -0400
To: "Peter Williams" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Peter:

Thanks for the tutorial on the process you use to determine whether or not 
to trust a particular "new root."  Your use of qualifiers that has nothing 
to do with certificate path validation.  So, would it be fair to say they 
you believe that qualifiers in CA certificates are useful for determing 
whether or not to trust that CA, but that they have no impact on 
certificate path processing?

Russ


At 11:55 AM 9/10/99 -0700, Peter Williams wrote:

> > Since the certificate validation algorithm does not use
> > certificate policy
> > qualifiers, how do certificate policy qualifiers in CA certificates help
> > the certificate user?
>
>
>Every so often, I receive in my S/MIME client a msg originated
>by someone belonging to a certification domain that
>I neither know, or trust. In general, they are RFC 2459 complying
>CAs, doing what RFC 2459 seeks.
>
>The fact that I receive these  is probably based on the fact that
>I co-authored an applied digital certificates book,
>suggesting people go out and deploy RFC 2459 and SET
>CAs (horror!): It  helped provide lots or practical know-how
>enabling cheap experimental deployment using mass-market software. People
>sometimes send me their results, proudly. (I rarely,
>if ever, see their names on this list.)
>
>Anyway, my S/MIME tool (which uses a well-known mass market
>certificate manager tool and crypto library) enables me to
>label the inbound certificates as trusted. I can learn a
>root, if you like. Some of the CA certs are self-signed, some
>are intermediate  CAs in a chain that does not happen to
>include the TLCA for  their domains.
>
>To decide to trust it, I inspect the certificate.  I,
>and my "auditor" make an accreditation judgment on
>its trustworthiness, much like CAs confirm the identify
>and obligations of CAs during PKIX3-specified
>cross-certification.
>
>Acting much as a professional security administrator in any
>large enterprise, I am as capable of taking this
>accreditation decision as any commercial CA might do on
>my behalf.
>
>To finalize the decision, I sign a list of my
>trusted roots which controls their use in my S/MIME client.
>The signed trust list acts, effectively, as my personal CA
>which controls inter-domain trust; conforming path
>processing ensures both trusted interworking and
>policy recognition during  S/MIME msg handling, when
>I choose to use conforming rules. As per 2459, I
>can turn off conforming rule processing, when
>required.
>
>What use are the qualifier? Russ asks.
>
>During inspection, the CPS pointer identifies to
>me the PEM-style policy elements which I used to evaluate
>the trustworthiness of the domain, as recommended by
>the designers of RFC 1422, whose basic ideas are incorporated
>into RFC 2459 by charter directive.
>
>In some cases, the certificate identifies
>one or more certificate policies.  In other
>cases it identifies one or more combined certificate policy
>and CPSs. I have to wade through the various declarations to make my
>decision deciding whether or not
>to extend trust, given goals of my own security program.
>The know-how to do this is about as complex as designing
>for NR. I use the PKIX-IV recommendations to do this,
>as one would expect.
>
>I understand from friends in companies who
>use other mass-market software, and who use the
>other RFC 2459 qualifier which points to
>Warwick Ford's (WG-ratified) scheme for locating
>policy description fragments embedded in compound
>documents, that they use that facility for purposes
>similar to those that I described for the CA-cert
>hosted URL.
>
>So, if nothing else, CA qualifiers are very valuable
>in the actual Internet PKI for learning trust-points,
>and taking accreditation decisions based on evaluation
>and recognition of policy. The use of explicit
>accreditation is a well-established technique,
>advised by reputable organizations such as NIST.
>
>It is true that I never use certificate path processing
>during this inspection and accreditation process; but then
>path processing was not designed for, and is not
>useful for, such an accreditation process. I would never
>use mandatory access control lattice implementation when
>accrediting a certified B2 OS product for use in my site,
>either!
>
>Hope this helps; its reality, and it works using at least
>two different mass-market software implementations that work
>largely according to the design and specification of RFC2459.
>The scheme is voluntary and optional. Only those
>interworking parties that recognize the (qualified) policy
>are affected. Those that do not recognize the a (qualified)
>policy, are  unaffected, if they use conforming implementations.
>
>Therefore policy controls interworking by instrumenting
>the accreditation, which is aided by the qualifiers, just as
>one would expect. Much of the experience of NIST (and NSA)
>is now implemented in the Internet PKI environment, supporting,
>as is culturally required: autonomous operations, experimentation,
>and multi-vendor implementations that interwork at least
>a minimal level, and by default.
>
>"I find qualifiers useful to provide exact information about certain policy
>elements." [another]
>
>Peter.



Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA22577 for <[e-mail]>; Thu, 16 Sep 1999 12:41:09 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA349526; Thu, 16 Sep 1999 15:43:57 -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.05) with SMTP id PAA27600; Thu, 16 Sep 1999 15:44:26 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852567EE.006C6A11 ; Thu, 16 Sep 1999 15:44:10 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 16 Sep 1999 15:43:11 -0400
Subject: Re: New Internet Draft on Non-Repudiation Requirements
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Hi Aram,

     My responses are bracketed with [TG1: comment].
Hi Tom,

My comments are bracketed with [AP1: comments].

[snip]
>
> ABSTRACT
>
> This document describes those features of a service which processes
> signed doucments which must be present in order for that service to
> constitute a "technical non-repudiation" service.  A technical
> non-repudiation service must permit an independent verifier to
> determine whether a given signature was applied to a given data object
> by the private key associated with a given valid certificate, at a time
> later than the signature.  The features of a technical non-repudiation
> service are expected to be necessary for a full non-repudiation service,
> although they may not be sufficient.
> [AP: You've defined a "'technical non-repudiation' service", but not a "full
> non-repudiation service". I'll use the acronym "TNR" for technical
> non-repudiation and "FNR" for full non-repudiation.]
>
> This document is intended to clarify the definition of the
> "non-repudiation" service in RFC 2459.  It should thus serve as a guide
> to when the nonRepudiation bit of the keyUsage extension should be used
> [AP: We should be consistent with either "nonrepudiation" or
"non-repudiation".
> Also, does "used" mean the same thing as "set"?]
> [TG: "when the nonRepudiation bit should be used" could easily be "... set"
> without any real change in meaning.]
> and to when a Certificate Authority is required to archive CRL's.
> [AP: Does the CA only have to archive CRL's for TNR? Does the CA need to
perform
> a higher due diligence before setting the NR bit? Can the CA set the NR bit
> without the subject requesting that the bit be set?]
> [TG: It is stated above, that FNR incorporates TNR as a core set of
> requirements.  Thus, CRL archiving is only directly mandated for TNR - but
that
> mandates it for FNR as well.]

[AP1: Above you state that TNR is "expected to be necessary" for FNR. This
is different from "FNR incorporates TNR as a core set of requirements". Is
it SHOULD or MUST? Like I commented before, you defined TNR but not FNR.]
[TG1: I don't know, because nobody has yet defined an FNR service at all, let
alone one which does not require TNR.  I do not know how an FNR service would
work if one could not submit evidence of the original signature.]

> [TG: Higher levels of due diligence are probably needed for FNR.  I doubt if
> they are needed for TNR.]
> [TG: The CA can set the bit if it wishes.  This service does not have the kind
> of heavy-duty legal requirements that FNR is likely to.]

[AP1: So my abuelita (grandmother) may get a cert with the NR bit set
without her requesting it or knowing what it means and inadvertently sell
her house? ]
[TG1: No, it takes more than NR bit use to make a legal contract.  It even takes
more than the NR bit to make TNR - see the rest of this draft.  Su abuela is no
more at risk digitally than in real life.]

>
> 1 Introduction
>
> RFC 2459 [1] specifies a bit within the KeyUsage extension called the
> nonRepudiation bit which is "asserted when the subject public key is
> used to verify digital signatures used to provide a non-repudiation
> service which protects against the signing entity falsely denying some
> action, excluding certificate or CRL signing."  Extensive discussions
> in the PKIX WG have revealed that the description of the non-repudiation
> service contained in this passage is not widely enough understood or
> agreed upon to characterize any given service as providing or not
> providing a non-repudiation service.  Two major categories of service
> have been proposed as potentially providing a non-repudiation service:
> the technical non-repudiation service, which this draft attempts to
> define with greater precision, and a full non-repudiation service
> which is intended to prevent all possible repudiations of a signed
> object or document.  Since a full non-repudiation service is required
> to meet all the requirements of this technical non-repudiation service
> as a prerequisite, the technical non-repudiation service's definition
> is necessary for both [AP: I disagree if you require the NR bit to be set].
> [TG: I'm not defining FNR here.  An FNR set of requirements is likely to
define
> a needed keyPurpose ID in the XKU extension, anyway.  My question is whether
you
> and the other FNR supporters believe that there needs to be some indication in
> the certificate that a given certificate is intended for NR or FNR use.]

[AP1: Wow, I didn't know I was an "FNR supporter" ;-)  When you state
"intended for NR or FNR use" does "NR" mean "TNR"? I can't speak for the
other "FNR supporters", but what I believe is that you can have legally
binding digital signatures that do not have the NR bit set.]
[TG1: That will depend on the definition of legally binding signatures.
Personally, I'm not convinced that FNR is possible without TNR, but an FNR draft
might well convince most people.]

[snip]
> , that the signer has been adequately informed of the content which is signed,
> that the signer is not acting
> under duress, etc. [AP: I think the scope should only include when the NR bit
is
> set, but clearly state that you can have FNR with the NR bit not set (as have
> been stated in the WG).][TG: That is fairly controversial in the WG, and I'm
not
> doing the FNR definition].

[AP1: I'm confused about the scope of the document then. You are not
defining FNR but you state that FNR requires (or is a superset of) TNR. And
for TNR you state that the NR bit must be set.]
[TG1: I haven't seen a definition of FNR for which signature evidence
preservation is not essential, but then again I haven't seen much definition of
FNR yet.  Should I point out that "it may be theoretically possible to produce
an FNR service which does not satisfy all the requirements of TNR below", and
leave it at that?]

>
> 2    Requirements for both 1-way and 2-way NR
>
> 2.1  The signer must submit, with the signature, the signing
> certificate or an unambiguous identifier of that certificate.
> Unambiguous identifiers of certificates include the combination of a
> certificate serial number with an issuer name [AP: You've only given 1
> identifier.][TG: So far, that's right.  I wasn't trying to be exhaustive.]

[AP1: I think you should give at least two since you state "Unambiguous
identifiers of certificates include..."]
[TG1: All right.  A second unambiguous identifier of a certificate is the
combination of issuer name, subject name, and subject key identifier (I hope).]
[snip]
>
> 2.3  The signer must include, in the base over which the signature
> is calculated, the time at which the signature was created.[AP: I think this
>  opens up a can of worms: local time, GMT, precision, trusted, etc.]
> [TG: Format is not, and does not have to be, specified for this.  The signer
has
> to trust this time, but either the RP or the escrow holder (depending on 1-way
> vs. 2-way) will be adding a time stamp of their own.]

[AP1: How does the RP or EH (escrow holder) know the signer that the time
was included in the signature?]
[TG: There will be another time in the format, which is their responsibility.
They can reject a flagrantly forward-dated document, however.]

[snip]
>
> 3.2  The relying party must save the identity of the signing
> certificate, along with the content of the signature.[AP: Isn't the
>  certificate self-identifiable? Isn't is sufficient to save the certificate?]
> [TG: Content of the signature, not of the certificate.  The full certificate
is
> acceptable, of course, since it contains its own ID.]

[AP1: I'm not sure what you mean by "content of the signature"?]
[TG1: The signature itself, along with any signature attributes in the CMS
sense.]

>
> 3.3  The relying party must check that the signing certificate
> contains a keyUsage extension.  If the extension is not present or does
> not contain the nonRepudiation bit, and the version of the certificate
> is v3 or higher, the submission must be rejected.[AP: I (and others in the WG)
>  believe this is wrong. Above you state the TNR is a requirement for FNR,
> but I think it has been shown in the recent discussions that the NR bit is NOT
> required for FNR.]
> [TG: 1-way NR is not a basis for FNR.  We can discuss this under 4.3,
however.]

[AP1: Ditto above confusion on TNR and FNR.]

[snip]
>
> 4.3  The relying party must check whether or not the signing
> certificate contains a keyUsage extension.  If the keyUsage extension
> is present and the nonRepudiation bit is not set the submission must be
> rejected.[AP: ditto comment as in 3.3]
> [TG: If the group really wants this, I'll put in some wording about how
"larger
> services extending this one may dispense from this requirement".  Note that
> missing keyUsage's are allowed here although not for 1-way.]

[AP1: I think you need a better explanation of the differences between 1 and
2-way NR and why they are needed.]
[TG1: 1-way NR is a relatively minimal service.  It allows the RP itself to
preserve signed objects in such a way that they can be submitted as evidence
later.  2-way NR involves an escrow holder who is independent of the RP.]

Regards,
Aram Perez







Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA21886 for <[e-mail]>; Thu, 16 Sep 1999 12:01:28 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id MAA11876; Thu, 16 Sep 1999 12:04:48 -0700 (PDT)
Received: from rsalaptop ([192.168.3.229]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id MAA20266; Thu, 16 Sep 1999 12:04:47 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Phillip M Hallam-Baker" <[e-mail]>, <[e-mail]>
Subject: RE: Huge CRLs
Date: Thu, 16 Sep 1999 12:06:55 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <000101bf0063$7ed035c0$[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Phil,

Please, stop censoring. The PKIX revocation story evidently
does not inspire much confidence yet; although its better 
than the VeriSign story. Community debate, involvement
and action is essential to move us forward
collectively. Wacko idea expression can move to 
usenet, but engineering comment is essential here.

If you personally want to ignore a thread or an 
author, I am sure your mail reader permits this.
Nothing requires you to even follow the
mailing list; you can still be a part of
the WG and ignore the list.

I have personally learned alot from the recent
exchange of revocation comments; standaridization is often
about taking proprietary knowledge and art and slowly
reducing it to public property. With ups
and downs, our industry has come a long way since
[e-mail]. This is probably due to the desire
of those who run these forum to involve 
others - with suitable leadership - not exlude them.

I hear Animal Farm is coming to US TV soon.

> -----Original Message-----
> From: Phillip M Hallam-Baker [mailto:[e-mail]]
> Sent: Thursday, September 16, 1999 9:50 AM
> To: Bob Jueneman; [e-mail]
> Subject: RE: Huge CRLs
> 
> 
> I suggest discussion move to the USENet group alt.crypto.pki.revocation
> Perhaps someone could rmgroup it?
> 
> I don't see any relevance to any PKIX working group draft.
> 
> 	Phill
> 
> > -----Original Message-----
> > From: Bob Jueneman [mailto:[e-mail]]
> > Sent: Thursday, September 16, 1999 11:09 AM
> > To: [e-mail]
> > Subject: Re: Huge CRLs
> >
> >
> > Because this topic seems to be somewhat removed from the primary
> > focus of the cert-talk group, I'd like to suggest that further 
> discussions
> > only copy the ietf-pkix list.
> >
> > Bob
> >
> > >>> Ed Gerck <[e-mail]> 09/15/99 03:13PM >>>
> >
> >
> > Stephen Kent wrote:
> >
> > > >Further, the major X.509 security application today, SSL, does not
> > > >check revocation lists -- so they are near to useless. Also,
> > the user is
> > > >not able to check server certificates (and certificates in the
> > CA chains)
> > > >against revocation lists.
> > >
> > > I think you are confusing SSL, the protocol, vs. 
> implementations of SSL
> > > (and https, in browsers.  Browsers have a number of defects in their
> > > handling of certs, but it is not accurate to attribute this to SSL.
> >
> > No, Steve, I am not confusing either or even both ;-) Pls check
> > the list archives
> > for my exchanges with Ben on this thread, especially those with
> > subjects "Re:
> > Trust and client choices, was Re: Huge CRLs".  At least, Ben and
> > I agreed --
> > which I must say does not happen so often ;-)
> >
> > Cheers,
> >
> > Ed Gerck
> > ______________________________________________________________________
> > http://www.mcg.org.br/authors/eg.htm                    [e-mail]
> >
> >
> 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA21874 for <[e-mail]>; Thu, 16 Sep 1999 12:01:24 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id MAA11880; Thu, 16 Sep 1999 12:04:51 -0700 (PDT)
Received: from rsalaptop ([192.168.3.229]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id MAA20270; Thu, 16 Sep 1999 12:04:48 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Huge CRLs
Date: Thu, 16 Sep 1999 12:06:57 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01BF003B.F91F45F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <v04020a04b406a9277120@[128.33.238.30]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

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



SET makes very limited use of CRLs, because its design does not require much
in the way if propogating revocation data, vs. local checking.



This was one of the design "flaws" found in the analysis of an early
(private) draft
when the thinking on CRLs, revocation and compromise handling was being
formed.

Processors and merchants are now a critical element in the propagation of
A/CRLs to
the client to address root key and CA compromise/rollover, and
address processor compromise.

SET design requires merchants and clients to do CRL checking. Let us be
quite
clear on this. And merchants are a critical point -
as the conduit for the transfer of infrastructure ARLs to the client.  They
control whether clients receive notice of infrastructure or processor
compromise.

SET has interesting msg relaying characteristics which affect security
flowing
from certs. Clients prepare two items of confidential material. One is
prepared
for the merchant, the other for the processor. Yet the client has only a
direct transfer
channel to the merchant, who also controls the flow of ARL/CRL information
to the client, and thereby the security of the preparation of encrypted
material to the processor.

I almost feel there is design principle lurking here. Never allow one of a
set
of recipients to control the flow of infrastructure revocation information
to
the originator.

SET is noticeably different to https design as regards use of certs
and the security properties of apps which become dependent on PKI -
and particularly as revocation and revocation protocol issues affect
security of multiple sessions relating to a single transaction.  https has
multiple (not merely 2) session support; encryption of a
single-transaction's elements can be conducted in parallel,
as with SET, but revocation information
can always be collected out of band from a source
that is controlled only by the originator, and there
can be  are multiple independent connections to transfer
or gather session-encrypted information.




------=_NextPart_000_0054_01BF003B.F91F45F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D094593217-16091999></SPAN><FONT color=3D#0000ff =
face=3DArial=20
size=3D2>&nbsp;</FONT><BR><BR>SET makes very limited use of CRLs, =
because its=20
design does not require much in the way if propogating revocation data, =
vs.=20
local checking.&nbsp;<FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>This=20
was one of the&nbsp;design "flaws" found in the analysis of&nbsp;an =
early=20
(private) draft</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>when=20
the thinking on CRLs, revocation and compromise handling was being=20
formed.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>Processors and</SPAN></FONT><FONT =
color=3D#0000ff=20
face=3DArial size=3D2><SPAN class=3D094593217-16091999> merchants =
</SPAN></FONT><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>are now a=20
critical element in the&nbsp;propagation of&nbsp;A/CRLs to =
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>the=20
client to address</SPAN></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D094593217-16091999> root key and CA compromise/rollover,=20
and</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>address&nbsp;processor =
compromise.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>SET=20
design requires merchants and clients to do CRL checking. Let us be=20
quite</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>clear=20
on this. And&nbsp;merchants are a critical point - </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>as the=20
conduit for the transfer of infrastructure ARLs to the client.&nbsp;=20
They&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>control whether clients receive notice of=20
infrastructure or processor compromise.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>SET=20
has interesting msg relaying characteristics which affect security=20
flowing</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>from=20
certs. Clients prepare&nbsp;two items&nbsp;of confidential material. One =
is=20
prepared</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>for=20
the merchant, the other for the processor. Yet the client has only a =
direct=20
transfer</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>channel to the merchant, who also controls =
the flow of=20
ARL/CRL information</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>to the=20
client, and thereby the security of the preparation of=20
encrypted</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>material to the =
processor.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>I=20
almost feel there is design principle lurking here. Never allow one of a =

set</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>of=20
recipients to control the flow of infrastructure revocation information=20
to</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>the=20
originator.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>SET is=20
noticeably different to https design as regards use of =
certs</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>and=20
the security&nbsp;properties of apps which become dependent on=20
PK</SPAN></FONT><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>I -</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>and=20
particularly&nbsp;as revocation and revocation protocol&nbsp;issues=20
affect</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>security of multiple sessions relating to a =
single=20
transaction.&nbsp; https has&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>multiple (not merely 2)</SPAN></FONT><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN class=3D094593217-16091999> =
session=20
support;&nbsp;encryption of a </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>single-transaction's =
elements</SPAN></FONT><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN class=3D094593217-16091999> =
can=20
be&nbsp;conducted in parallel,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>as=20
with SET, but</SPAN></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D094593217-16091999> revocation information</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>can=20
always be collected out of band from a source</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>that=20
is controlled only by the originator, and </SPAN></FONT><FONT =
color=3D#0000ff=20
face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>there</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>can=20
be&nbsp; </SPAN></FONT><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =

class=3D094593217-16091999>are multiple independent connections to =
transfer=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>or=20
gather </SPAN></FONT><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>session-encrypted </SPAN></FONT><FONT =
color=3D#0000ff=20
face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>information.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999></SPAN></FONT><FONT color=3D#0000ff =
face=3DArial=20
size=3D2><SPAN class=3D094593217-16091999></SPAN></FONT><FONT =
color=3D#0000ff=20
face=3DArial size=3D2><SPAN =
class=3D094593217-16091999>&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D094593217-16091999>&nbsp;</SPAN></FONT></DIV></BODY></HTML>

------=_NextPart_000_0054_01BF003B.F91F45F0--



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA21125 for <[e-mail]>; Thu, 16 Sep 1999 11:04:15 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id LAA11442 for <[e-mail]>; Thu, 16 Sep 1999 11:07:39 -0700 (PDT)
Received: from indus ([192.168.4.124]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id LAA18797 for <[e-mail]>; Thu, 16 Sep 1999 11:07:39 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Michele B." <[e-mail]>
To: <[e-mail]>
Subject: Subscription Request
Date: Thu, 16 Sep 1999 11:05:45 -0700
MIME-Version: 1.0
Message-ID: <001c01bf006e$19cf93e0$[e-mail]>
Content-Type: multipart/signed; micalg=SHA-1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0034_01BF0033.6ADCA380"
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.2106.4

This is a multi-part message in MIME format.

------=_NextPart_000_0034_01BF0033.6ADCA380
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_002C_01BF0033.6AC5C020"


------=_NextPart_000_002C_01BF0033.6AC5C020
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_002D_01BF0033.6AC8CD60"


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



Please add me to your Distribution list.

Kind Regards,
Michele
_________________________
Michele Bondesson
Valicert, Inc.
Corp. Sales Rep.
T: 1-650-567-5475
F: 1-650-254-2148
email: [e-mail]
Enabling Global Private Trust 
 

------=_NextPart_001_002D_01BF0033.6AC8CD60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2163.0">
<TITLE></TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Please add me to your Distribution =
list.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Kind Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Michele</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">_________________________</FONT>
<BR><I><FONT SIZE=3D2 FACE=3D"Arial">Michele Bondesson</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Arial">Valicert, Inc.</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Arial">Corp. Sales Rep.</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Arial">T: 1-650-567-5475</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Arial">F: 1-650-254-2148</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Arial">email: =
[e-mail]</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Arial">Enabling Global Private =
Trust</FONT></I><FONT SIZE=3D2 FACE=3D"Arial"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> </FONT>
</P>

</BODY>
</HTML>
------=_NextPart_001_002D_01BF0033.6AC8CD60--

------=_NextPart_000_002C_01BF0033.6AC5C020
Content-Type: application/octet-stream;
	name="Michele Bondesson (E-mail).vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Michele Bondesson (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Bondesson;Michele
FN:Michele Bondesson (E-mail)
EMAIL;PREF;INTERNET:[e-mail]
REV:19990820T202641Z
END:VCARD

------=_NextPart_000_002C_01BF0033.6AC5C020--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFyTCCAogw
ggHxoAMCAQICAwFb3TANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0
aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAxNzo1NTE2MDQGA1UEAxMt
VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5OC45LjE2MB4XDTk5MDkwODE3
MjQxNFoXDTAwMDkwNzE3MjQxNFowRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEk
MCIGCSqGSIb3DQEJARYVbWljaGVsZWJAdmFsaWNlcnQuY29tMFwwDQYJKoZIhvcNAQEBBQADSwAw
SAJBAOISSzms+6mD809/M4p3y+kNpv6e20p5pYEdXKmbbQf91kuaucPl9cr7V5k3pAQxiGAxv5Hd
dvwPO3PShAWQO10CAwEAAaNTMFEwIAYDVR0RBBkwF4EVbWljaGVsZWJAdmFsaWNlcnQuY29tMAwG
A1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU/j5gnGuMD7DYM8bKxh5YsHE4teAwDQYJKoZIhvcNAQEE
BQADgYEAc9/bq56TIhQEh+O6hdhhkpmsX2uk4pXpnQd6InixJU8V8D1VjesmX+aahHIZWHCKnM3r
8X8bONFFeTUB1Ll4rbDV8+yvyy+f9xFd4IgF0sEbkNs0+YHES1H3Ca689jPewChnqcb8P+qU7cgs
PWgDpdpAiKVEr0HuqN4kIAPzhb4wggM5MIICoqADAgECAgEKMA0GCSqGSIb3DQEBBAUAMIHRMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY
BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz
IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG
9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTgwOTE2MTc1NTM0WhcNMDAw
OTE1MTc1NTM0WjCBuTELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UE
BxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3
dGUgUEYgUlNBIElLIDE5OTguOS4xNiAxNzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZy
ZWVtYWlsIFJTQSBJc3N1ZXIgMTk5OC45LjE2MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE
peXU1NBfCALuByF9JL+ra44e6yAHAhWEa4/QkyQfG53uaLK5LE/pk2cXEBceoflDQSO5MKp2l7vz
5/2BwLUxi/amUCZU8pUo6xmkHpcesOK4m8EEmjLQPAlsT+Q1T/B2vwATA09FCGDz/LTQkAGKEsmc
un9S6iqTNTY8POQ1LwIDAQABozcwNTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFHJJ
wnM0xlX0C3ZygX539IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBACzHgh8BQz4Hj+5pXKlkgvjAlq2T
K8ubUNdAmoHCuqZ2nTyVQNxVweFVgnmrCimm1QzhVyg+j/m71d8Nk1iqWy2LjzPk3VgVNXZyFSm9
QvRakgt3X50n25otThuCBo7SjVa7ld7bDGUF3pWeAt1TF76+/GvDGiJ6FCthvcKfXnpaMYICkjCC
Ao4CAQEwgcEwgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcT
C0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhhd3Rl
IFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNgIDAVvdMAkGBSsOAwIaBQCgggFnMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MDkxNjE4MDU0MlowIwYJKoZIhvcNAQkE
MRYEFBc8BV6XkGX7XcLteztxVYAmgC3wMDMGCSqGSIb3DQEJDzEmMCQwDQYIKoZIhvcNAwICASgw
BwYFKw4DAhowCgYIKoZIhvcNAgUwgdIGCSsGAQQBgjcQBDGBxDCBwTCBuTELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo
YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAxNzo1
NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5OC45LjE2
AgMBW90wDQYJKoZIhvcNAQEBBQAEQCX5R1nUcu0ehF7Hm5wBZuLFrP74htwoSMjyelNnGfbmPzTw
ubhsNO1rvjHPqPaMG/4CxpMgbGpppiX9seJaCywAAAAAAAA=

------=_NextPart_000_0034_01BF0033.6ADCA380--



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA19922 for <[e-mail]>; Thu, 16 Sep 1999 09:45:52 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA02618; Thu, 16 Sep 1999 09:47:12 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA28696; Thu, 16 Sep 1999 09:48:49 -0700 (PDT)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SF5SH93V; Thu, 16 Sep 1999 09:48:50 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
Subject: RE: Huge CRLs
Date: Thu, 16 Sep 1999 12:49:51 -0400
Message-ID: <000101bf0063$7ed035c0$[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]>

I suggest discussion move to the USENet group alt.crypto.pki.revocation
Perhaps someone could rmgroup it?

I don't see any relevance to any PKIX working group draft.

	Phill

> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]]
> Sent: Thursday, September 16, 1999 11:09 AM
> To: [e-mail]
> Subject: Re: Huge CRLs
>
>
> Because this topic seems to be somewhat removed from the primary
> focus of the cert-talk group, I'd like to suggest that further discussions
> only copy the ietf-pkix list.
>
> Bob
>
> >>> Ed Gerck <[e-mail]> 09/15/99 03:13PM >>>
>
>
> Stephen Kent wrote:
>
> > >Further, the major X.509 security application today, SSL, does not
> > >check revocation lists -- so they are near to useless. Also,
> the user is
> > >not able to check server certificates (and certificates in the
> CA chains)
> > >against revocation lists.
> >
> > I think you are confusing SSL, the protocol, vs. implementations of SSL
> > (and https, in browsers.  Browsers have a number of defects in their
> > handling of certs, but it is not accurate to attribute this to SSL.
>
> No, Steve, I am not confusing either or even both ;-) Pls check
> the list archives
> for my exchanges with Ben on this thread, especially those with
> subjects "Re:
> Trust and client choices, was Re: Huge CRLs".  At least, Ben and
> I agreed --
> which I must say does not happen so often ;-)
>
> Cheers,
>
> Ed Gerck
> ______________________________________________________________________
> http://www.mcg.org.br/authors/eg.htm                    [e-mail]
>
>



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA18805 for <[e-mail]>; Thu, 16 Sep 1999 08:15:38 -0700 (PDT)
Received: from [128.33.238.30] (TC013.BBN.COM [128.33.238.13]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA07986; Thu, 16 Sep 1999 11:18:58 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a05b406b2d8b011@[128.33.238.30]>
In-Reply-To: <[e-mail]>
Date: Thu, 16 Sep 1999 11:14:56 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Huge CRLs
Cc: [e-mail], [e-mail]

Kawika,

>I freely acknowlege the fact that I am biased because of my experience,
>sector focus, and sunk costs.   I did not intend to defame or diss anyone or
>their ideas.  Some financial services applications may have requirements and
>profiles that are unique, but I believe that in many cases the early lessons
>learned by the financial services sector will be required reading for others
>who are trying to scale up their systems or engage in high value transactions.
>
>I have tons of reasons for wanting to see revocation issues addressed to the
>satisfaction of a pretty demanding set of customers in the financial services
>sector.    Almost everyone already knows by now that I am working on CRL
>alternatives and have both policy, personal, and economic interests in this
>issue.  What has bothered me for quite some time is that despite everyone's
>best efforts, PKI technology has so far fallen short of delivering on its
>promises and underreturned on investments in part because of inflexible
>technology and models.  Even the most immature solutions have a lot of merit
>and are producing risk reduction results, but it has been extraordinarily
>difficult to integrate PKI into traditional entities production systems
>because of the inflexibility of many models and technologies.  I find more
>potential within PKI to transform business (strategy, policy)  models and
>processes than even TCPIP, but the practical work of infrastructure (legal,
>technical) development is painful.  A lot of effort and other resources are
>being invested and progress is being made.  I have committed significant
>personal resources to support my previous investments in PKI policy, and
>technology.    Much of my time is focused on defining the policy space (law,
>regulation, standards); helping people and institutions understand the policy
>space, business requirements, and technology; and providing technology
>solutions to fill gaps.

I see a possible basis for divergence in our expectations here.  I think
that it is not necessarily appropriate to expect to transform all aspects
of doing business by introducing PKI-based systems.  For example, if you
say that a PKI-based system is inadequate unless two companies can execute
a multi-million dollar agreement, having never previously done business
with one another, purely in cyberspace, etc., then we disagree.  My
expectations are more modest.  I would be happy if we could take most
existing ways of doing business in the physical world and move them to
cyberspace.  The cost savings would be very substantial, as would the
increases in efficiency.  The notion of that we must create PKIs that
enable high value transactions to take place without reference to
traditional relationships in the physical world, has, in my opinion, done
more to retard the deployment of useful PKIs than any technical
limitations.  However, I may be misunderstanding the range of apps you're
alluding to above.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA18603 for <[e-mail]>; Thu, 16 Sep 1999 08:09:49 -0700 (PDT)
Received: from [128.33.238.30] (TC013.BBN.COM [128.33.238.13]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA07126; Thu, 16 Sep 1999 11:13:04 -0400 (EDT)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1274627630==_ma============"
Message-Id: <v04020a04b406a9277120@[128.33.238.30]>
In-Reply-To: <[e-mail]>
References: <v04020a03b4002a7dc532@[128.89.0.111]>
Date: Thu, 16 Sep 1999 10:43:33 -0400
To: Daniel Alex Finkelstein <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Huge CRLs
Cc: [e-mail]

--============_-1274627630==_ma============
Content-Type: text/plain; charset="us-ascii"

Dan,

>But the importance of privacy and cryptography to financial services
>cannot be overlooked or ignored. It is no coincidence that the largest
>drivers of cryptography deployment have been banks and investment firms
>(and markets). Just recently, only banks were allowed to distribute
>greater-than-export strength crypto for their clientele.
>
>If CRLs are unsuitable for that environment, they should be tweaked until
>they are suitable (or until another means of similar functionality is
>developed). Ignoring this very large share of the market would be foolish;
>if you do, you'll lose a lot of customers. After all, PKI has been around
>for a while now and still hasn't "taken off." Many of us believe that
>PKI as we know it isn't "it," and something else will inevitably turn up
>that succeeds where PKI failed. Vendors clearly haven't produced anything
>usable for this sector, leaving the firms themselves to develop
>next-generation security. And why shouldn't we be successful? We've done
>it before.  

In part, the problem is that the financial services environment is quite
diverse and thus no single characterization of requirements is appropriate.
One can argue that the current use of SSL and certs (even without CRLs!) to
secure access for home banking, online tradeing, and online porfolio
management are all "financial service" applications and this use works well
enough to have spurred very significant activity in these areas.  By that
measure, the problem is solved :-).

SET makes very limited use of CRLs, because its design does not require
much in the way if propogating revocation data, vs. local checking.  It
would seem that that financial app doesn't pose requirements that exceed
the capabilities of the existing CRL mechanisms.  On the other hand, one
can certainly define PKI-based apps that pose such great demands on timely
knbowledge of cert status, and which involve such a large community, that
it may be very difficult, perhaps impractical, to meet these requirements
with CRLs in any form. In the final analysis, PKIs are not the solution for
all problems, though one generally derives great benefit from leveraging
standards and widely available products that meet those standards.

Steve
--============_-1274627630==_ma============
Content-Type: text/enriched; charset="us-ascii"

Dan,


<excerpt>But the importance of privacy and cryptography to financial
services cannot be overlooked or ignored. It is no coincidence that the
largest drivers of cryptography deployment have been banks and
investment firms (and markets). Just recently, only banks were allowed
to distribute greater-than-export strength crypto for their clientele.


If CRLs are unsuitable for that environment, they should be tweaked
until they are suitable (or until another means of similar
functionality is developed). Ignoring this very large share of the
market would be foolish; if you do, you'll lose a lot of customers.
After all, PKI has been around for a while now and still hasn't "taken
off." Many of us believe that PKI as we know it isn't "it," and
something else will inevitably turn up that succeeds where PKI failed.
Vendors clearly haven't produced anything usable for this sector,
leaving the firms themselves to develop next-generation security. And
why shouldn't we be successful? We've done it before.  

</excerpt>

In part, the problem is that the financial services environment is
quite diverse and thus no single characterization of requirements is
appropriate.  One can argue that the current use of SSL and certs (even
without CRLs!) to secure access for home banking, online tradeing, and
online porfolio management are all "financial service" applications and
this use works well enough to have spurred very significant activity in
these areas.  By that measure, the problem is solved :-).  


SET makes very limited use of CRLs, because its design does not require
much in the way if propogating revocation data, vs. local checking.  It
would seem that that financial app doesn't pose requirements that
exceed the capabilities of the existing CRL mechanisms.  On the other
hand, one can certainly define PKI-based apps that pose such great
demands on timely knbowledge of cert status, and which involve such a
large community, that it may be very difficult, perhaps impractical, to
meet these requirements with CRLs in any form. In the final analysis,
PKIs are not the solution for all problems, though one generally
derives great benefit from leveraging standards and widely available
products that meet those standards.


Steve

--============_-1274627630==_ma============--


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id IAA18422 for <[e-mail]>; Thu, 16 Sep 1999 08:06:07 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 16 Sep 1999 09:09:03 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Thu, 16 Sep 1999 09:09:01 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Subject: Re: Huge CRLs
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 IAA18424

Because this topic seems to be somewhat removed from the primary 
focus of the cert-talk group, I'd like to suggest that further discussions
only copy the ietf-pkix list.

Bob

>>> Ed Gerck <[e-mail]> 09/15/99 03:13PM >>>


Stephen Kent wrote:

> >Further, the major X.509 security application today, SSL, does not
> >check revocation lists -- so they are near to useless. Also, the user is
> >not able to check server certificates (and certificates in the CA chains)
> >against revocation lists.
>
> I think you are confusing SSL, the protocol, vs. implementations of SSL
> (and https, in browsers.  Browsers have a number of defects in their
> handling of certs, but it is not accurate to attribute this to SSL.

No, Steve, I am not confusing either or even both ;-) Pls check the list archives
for my exchanges with Ben on this thread, especially those with subjects "Re:
Trust and client choices, was Re: Huge CRLs".  At least, Ben and I agreed --
which I must say does not happen so often ;-)

Cheers,

Ed Gerck
______________________________________________________________________
http://www.mcg.org.br/authors/eg.htm                    [e-mail] 





Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA17213 for <[e-mail]>; Thu, 16 Sep 1999 06:39:29 -0700 (PDT)
Received: from fipr.demon.co.uk ([212.228.119.220] helo=director) by finch-post-10.mail.demon.net with smtp (Exim 2.12 #1) id 11RboN-0009GY-0A for [e-mail]; Thu, 16 Sep 1999 13:42:55 +0000
From: "Caspar Bowden" <[e-mail]>
To: <[e-mail]>
Subject: UK Decryption & Interception policy: "Scrambling for Safety 3.5", 23/9/99
Date: Thu, 16 Sep 1999 14:45:57 +0100
Message-ID: <001301bf0049$ceb16c90$0100a8c0@director>
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

PLEASE CIRCULATE TO THOSE THAT MIGHT BE INTERESTED
(APOLOGIES FOR ANY DUPLICATION)

Scrambling for Safety 3.5 - Thursday September 23 1999
======================================================
http://www.fipr.org/sfs35.html

The Foundation for Information Policy Research, Privacy International and
the LSE Computer Security Research Centre are jointly sponsoring the fourth
in the series of public conferences on cryptography policy, e-commerce and
Internet surveillance. This will be the second conference of 1999, and has
been called in response to the exceptional circumstance of two official DTI
consultations in the same year, and the Home Office's recent consultation on
revising the Interception of Communications Act to cover the Internet.

Admission is free of charge.

09:15 - 13:30, Thursday 23 September 1999

Old Theatre, Main Building,
London School of Economics,
Houghton St., London WC2
(for directions, check links on the Website)

Registration: Send e-mail to

 [e-mail]

with "name, organisation" in body. Telephone enquiries: 0171 354 2333

The connections between Home Office policy on interception and powers
proposed in Part.III of the DTI's draft Electronic Communications Bill
(closing date for responses 8th October) will be explored, and well as
the legal framework for establishing voluntary licensing of cryptography
services, and recognition of digital signatures.

Provisional Programme :
======================================================================
(Timing and speakers likely to change :
please check frequently for updates - http://www.fipr.org/sfs35.html )
======================================================================
09.25 Welcome - Caspar Bowden, FIPR

09:30 Internet Service Providers Association (invited)
 Alliance for Electronic Business: Progress towards self-regulation

10:00 "Cryptography, privacy and information warfare"
 - Whitfield Diffie

10:30 "Why we needed further consultation"
 - Alan Duncan MP, Shadow spokesman on Trade and Industry

11:00 "Cryptography's central role in e-commerce policy"
 - Chris Sundt, CBI

11:30 "Law enforcement access to keys - legal and human rights issues"
 - Nicholas Bohm (Law Society)

12:00 Keynote: Patricia Hewitt MP
 - Minister of State for E-Commerce at the DTI

12:45 Panel discussion
 - Jim Norton (Cabinet Office PIU)
 - Stephen Pride (DTI)
 - Peter Sommer (Special Adviser to T&I Sel Ctee)
 - Clare Wardle (Post Office)
 - LIBERTY
 - Jack Beatson QC (Essex Court Chambers)
 - Stewart Baker (Steptoe & Johnson, ex-NSA General Counsel)

13:30 close
============



Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA16618 for <[e-mail]>; Thu, 16 Sep 1999 05:57:02 -0700 (PDT)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI5LGT00.FGY for <[e-mail]>; Thu, 16 Sep 1999 13:00:29 +0000 
Received: from nma.com ([209.21.28.76]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI5LGH00.SIX; Thu, 16 Sep 1999 13:00:17 +0000 
Message-ID: <[e-mail]>
Date: Thu, 16 Sep 1999 06:00:32 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: metagrobolized, was Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <v04020a02b4059bc76fed@[128.33.238.12]> <v04020a14b4067fb21214@[128.33.238.83]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed,
>
> Ed Gerck wrote:
> >No, Steve, I am not confusing either or even both ;-) Pls check the list
> >archives for my exchanges with Ben on this thread, especially those with
> >subjects "Re: Trust and client choices, was Re: Huge CRLs".  At least,
> >Ben and I agreed -- which I must say does not happen so often ;-)
>
> Irrespective of whether you and Ben agree, SSL does not specify cert & CRL
> processing.

Since this simple discussion is now metagrobolized, let me first note that
it is a common misconception to think that SSL is a socket protocol that
does not care about what is transported, just because it is called
"Secure Socket Layer" ;-) As we know, names used in Internet protocols do
not need to mean what they mean elsewhere, not even in other Internet
Protocols ;-)  SSL is  NOT a socket protocol as the name might indicate and
SSL states fully depend on what was and is being transported in the session
-- SSL is a layered protocol with *stateful* sessions that depend on
transported content.  And, as with any state machine, you may recognize a
Turing machine and yes, guess what... it processes information.

As you can read in http://home.netscape.com/eng/ssl3/3-SPEC.HTM#7-6-4
the client knows which CAs are acceptable to the server exactly because SSL
allows the server to send an SSL message with a list of distinguished names  in the
SSL 'certificate request' message to the client:

   If the server has sent a 'certificate request' message, the client must send either the
   'certificate message' or a 'no certificate alert'.

where the names within single-quotes are *SSL messages* processed and
sent according to * SSL states*.  Further, Section "7.6.4 Certificate request" of
the SSL spec says:

     A non-anonymous server can optionally request a certificate from the client, if
     appropriate for the selected cipher suite.
...
     Note: It is a fatal 'handshake_failure' alert for an anonymous server to request client
     identification.

which means that SSL changes state and aborts the protocol based on an invalid
certificate request performed by the driving application -- so, SSL is aware of what
was transported in the past and reacts to it in the present. It has processed that
information using its states as memory.

Now, if SSL would be just a "socket protocol" that would ignore the content encoded
in whatever is being transported, including certs which would be just bits, then this
fatal alert would not even be able to exist, no?

And this is oftentimes a second misconception here: SSL is not HTTPS but
HTTPS uses SSL, so HTTPS is not stateless as HTTP.

Further, as I noted in this thread, this is what makes SSL *cause* the CRL
verification problem for the client since there is NO corresponding list sent in the
other direction (from the client to the server) allowed by the SSL protocol.  The
effect of this *SSL asymmetry* in dealing with certificates is that which I
summarized in my first message. Which is detrimental to the client's capability
of verifying CRLs.

> Even the recently released https I-D does not specify cert
> validation behavior, though it probablky should.  So, when you say that
> "SSL does not check revocation lists" that is vacuously true, in so far as
> SSL specifies no form of cert validation, including CRL processing.

Your usage of the words "vacuously true" is disingenuous.  I did provide
a URL with the context for my short comment, since my intention was
to show that my comment in that URL (already visited more than 90,000
times and published in short form in a book by McGrawHill) can be
direclty applied also to CRLs  -- as a second-order choice that the client
is however denied to make under SSL. This is that text, now inlined:

(ii) The client needs to accept the server CAs' key signatures, usually
in a list that may include an unknown (i.e., untrusted) CA if that CA is
trusted by a CA that the client trusts, and so on to a possibly large
depth starting from only one known CA -- otherwise, the client has the
choice of terminating the connection, which is hardly a choice (i.e., no
alternative). However, a good certificate list could decrease, clearly, the
number of untrusted entries (and, risk) in such a chain. Further, the job
of providing a good certificate list is more challenging for the server
than it would have been for the client -- the server is essentially
groping in the dark because it is not informed by the client what CAs
to best aim for in a ranking list (CAs that are directly trusted by the
client or, untrusted CAs directly trusted by a CA that the client
trusts or, etc.). The client, however, would know which CAs are
acceptable to the server because the server sends a list of
distinguished names [2] in the "certificate request" message. Note
that there is no corresponding list sent in the other direction (from
the client to the server).


> What
> you are commenting about appears to be observed behavior of SSL in commonly
> available browsers, as I said.  Note that several vendors provide plug in
> software for web severs which does check CRLs, and which performs more
> extensive cert validation that than offered by the server software.

What is the worth of checking a CRL from a distrusted CA for CRLs? Note also
that the CA may be trusted for signing but not for CRLs, as I commented before.

> This is
> consistent with the fact that SSL, per se, does not address these details,
> but rather is a protocol spec that happens to carry certs and relies on
> other software to validate them.

You seem to believe that SSL is a socket protocol that "carry things". It ain't,
in spite of the name. It recalls things that it carried before in the session and it
reacts to requests also in terms of that session's past.  It is easy to see that SSL
in fact validates positively or negatively what other software wants to do
after they validate or not a cert.  *Other* software thus also rely on SSL to
validate their actions in terms of those certs, not only the other way around
as you wrote. Who watches over whom is an interesting question here, and
one which is IMO well-solved to a large extent in SSL.

To close, I wish to note that IMO SSL is a very interesting protocol and my
comments to its unfortunate asymmetry in regard to server certs and CRL
bullying to the client are not to be seen as a dismissive treatment of SSL but
rather as a way to  help make it even better -- both by motivating changes
as well as by calling attention to the problems and possible workarounds.

Cheers,

Ed Gerck
______________________________________________________________________
http://www.mcg.org.br/authors/eg.htm                    [e-mail]




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA16129 for <[e-mail]>; Thu, 16 Sep 1999 05:19:54 -0700 (PDT)
Received: from [128.33.238.30] (TC030.BBN.COM [128.33.238.30]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id IAA14935; Thu, 16 Sep 1999 08:23:10 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a02b4068fde137a@[128.33.238.83]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 16 Sep 1999 08:24:21 -0400
To: "Peter Williams" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Huge CRLs
Cc: "Ed Gerck" <[e-mail]>, <[e-mail]>

Peter,

>SSL does not involve certificates, if you read the design carefully. Its
>processing is independent of the key distribution mechanism; any valid
>means of distributing asymmetric keys is acceptable. Cipher suites
>do not bind to any particular method of key distribution, in general.
>(some of the poorer specification bind cipher suites to kerberos,
>breaking the architecture though; on well, purity has no value of
>itself.)

I was speaking of SSL v3 and TLS v1, the current specs.  There is a very
definate certificate awareness in these protocols, for transport of server,
CA, and client certs.  Yes the key generation method is independent of the
use of certs, although it is heavily oriented toward public key crypto, and
biased toward the use of RSA (which was the focus of SSL v2, I believe).

>https is indeed a distinct protocol from SSL. its specification
>is "fluid", and is well now well into its 5th version. Its defined largely
>as that which Netscape and Microsoft web client/servers are
>interoperable on, with options and value add on each side. Use of
>SSL for secure data conferencing,  white boarding authorization, etc
>and  other uses are not standardized. The securing
>of the FrontPage protocol is similarly not standardized. These
>all have security protocols built over and above SSL layer protocols,
>like https.

You and I differ on principles here.  I don't consider implementations to
be protocol specs.  If I did, then I would have to say that the early
versions of SSL were seriously flawed because Netscape used a terrible
PRNG.  In reality, it was the early IMPLEMENTATIONS that were flawed in
this fashion.

>It may be time to standardize https which is a hypermedia security
>service, is really quite complex, and addresses framed security
>contexts, multiple sessions, connection teardown, host-id
>selection of keying material on the server, and various other
>matters peculiar to stateless web behavior in the context
>of hypermedia documents. It goes way beyond  just securing the
>TCP channel over which  http messages are exchanged with an few
>integrity/confidentiality keys.

SSL already defines a multiple session continuity facility, i.e., the
handshake accommodates both new and resumed sessions.  Are you referring to
some other feature?

>The integration of certificate validation with https (forming
>https "5"  if you  like) is an ongoing task, some of which was
>deployed with IE5. It may be better to use w3c to standardize
>https, given its hypermedia orientation, however. IETF is
>not too good at web stuff. One can perhaps expect https
>"6" to address XML signatures on the media items
>that https governs and interacts with, now that these
>are gaining wide acceptance.

The IETF is pretty good at certificate stuff, and to the extent that we are
talking about how certs and crls are used to support SSL/TLS, I think that
fair game for and IETF WG, should it wish to do so.  Eric's initial SHTTP
draft suggests a step in that direction, but it clearly does not cover much.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA15193 for <[e-mail]>; Thu, 16 Sep 1999 04:02:25 -0700 (PDT)
Received: from [128.33.238.83] (TC063.BBN.COM [128.33.238.63]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id HAA07747; Thu, 16 Sep 1999 07:05:44 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a14b4067fb21214@[128.33.238.83]>
In-Reply-To: <[e-mail]>
References: <v04020a03b4002a7dc532@[128.89.0.111]> <v04020a02b4059bc76fed@[128.33.238.12]>
Date: Thu, 16 Sep 1999 07:06:53 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Huge CRLs
Cc: [e-mail]

Ed,

>No, Steve, I am not confusing either or even both ;-) Pls check the list
>archives
>for my exchanges with Ben on this thread, especially those with subjects "Re:
>Trust and client choices, was Re: Huge CRLs".  At least, Ben and I agreed --
>which I must say does not happen so often ;-)

Irrespective of whether you and Ben agree, SSL does not specify cert & CRL
processing.  Even the recently released https I-D does not specify cert
validation behavior, though it probablky should.  So, when you say that
"SSL does not check revocation lists" that is vacuously true, in so far as
SSL specifies no form of cert validation, including CRL processing.  What
you are commenting about appears to be observed behavior of SSL in commonly
available browsers, as I said.  Note that several vendors provide plug in
software for web severs which does check CRLs, and which performs more
extensive cert validation that than offered by the server software. This is
consistent with the fact that SSL, per se, does not address these details,
but rather is a protocol spec that happens to carry certs and relies on
other software to validate them.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA14995 for <[e-mail]>; Thu, 16 Sep 1999 03:57:02 -0700 (PDT)
Received: from [128.33.238.83] (TC063.BBN.COM [128.33.238.63]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id HAA07381; Thu, 16 Sep 1999 07:00:22 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a10b4067da59644@[128.33.238.83]>
In-Reply-To: <[e-mail]>
Date: Thu, 16 Sep 1999 06:59:34 -0400
To: "Aram Perez" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Trust and client choices
Cc: [e-mail]

At 4:02 PM -0700 9/15/99, Aram Perez wrote:
>Hi Steve,
>
>> I suggest you review some of the literature on CA models that do not rely on
>> global CA registries.
>
>Where could one find such literature?

Try the proceedings of SNDSS, IEEE S&P, NISSC, USENIX Security Symposium,
ACM Security Conference, and MILCOM 97, for example.


Steve


Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA07877 for <[e-mail]>; Wed, 15 Sep 1999 19:02:14 -0700 (PDT)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI4R5F00.VF7 for <[e-mail]>; Thu, 16 Sep 1999 02:05:39 +0000 
Received: from nma.com ([209.21.28.112]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI4Q7Y00.53U; Thu, 16 Sep 1999 01:45:34 +0000 
Message-ID: <[e-mail]>
Date: Wed, 15 Sep 1999 19:05:40 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <v04020a03b405a1d8de51@[128.33.238.12]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed,
>
> >The first interesting question raised here is that of trust -- I cannot assume
> >or favor the notion that there is only one CA that the client MUST trust,
> >which  CA is by the way the ONE that the *other party* (the server) has
> >chosen ;-)
>
> In general, two parties are free to choose different CAs as issuers of
> their respective certificates.  Thus each party always has to work to find
> a path for validating the other party's certificate.  Why is this news to
> you, Ed?

The news is that I have assumed that SSL was better known.  What you say is
theoretical and NOT allowed by SLL protocol because there may be no path
known to the client -- even though a path might have existed to the client if
SSL would allow the client to propose a hit list to the server, which however the
server is allowed to do towards the client under the same SSL. Capice?

So, the server can send a message with a list of distinguished names  in the
SSL "certificate request" message to the client.  However, there is no corresponding
list that can be sent in the other direction (from the client to the server) in the
SSL protocol.  The effect of this **SSL asymmetry** is that  SSL does not allow
the client to check revocation lists that are meaningful to the client.


> (By the way, you continue to equate SSL with the cert processing
> implemented in the two major browsers, which is inaccurate.)

No, you are perhaps just reading my text segment too narrowly.  The basic
asymmetric fact here is that, using SSL, the client knows which CAs are acceptable
*to the server* for signature validation and CRL verification because the server
*sends* a list of distinguished names in the **SSL** "certificate request"
message. However, there is no corresponding list sent in the other direction in
SSL (from the client to the server).  Thus,  the server is essentially groping in the
dark when trying to supply a certificate that the client can check for its CRL,
because the server is not informed by the client what CAs to best aim for in a
ranking list  (CAs that are directly trusted by the client for signature and CRLs,
untrusted CAs directly trusted by a CA that the client trusts, etc.).

So, SSL denies to browsers what it allows to servers -- to choose who to
trust for what.  Which has the other consequences I wrote below:


> >So, since SSL does not offer a client-mechanism to decide who to trust for
> >what, and since this also translates into an anti-competitive issue built
> >right into the SSL protocol, I see then that the decision of trust is, from the
> >firstmoment, removed from the client. Both for certificates and for CRLs -- which
> >would not have to be provided the issuing CA.  So, there is a second decision
> >of trust removed by the SSL protocol -- the server and the client have no
> >choice for VA and must use the issuing CA.
>
> Your first assertion here is correct, i.e., a shortcoming of the browser
> (not SSL) cert processing

The browser is rendered powerless by the absence of an SSL "certificate
request" message for the client -- though SLL has it for the server, as I
excplained.  So, I disagree with your assertion. This dog won't hunt because
it is tied up.

>
> >So, where should the client look for the CRL? At the CA site that the
> >client does not trust?  Or, cannot reach?  What URL? How about
> > redundancy, alternatives?
> >
> >The conclusion IMO is that which I commented first, but edited to stress the
> >client context. That the major X.509 security application today, SSL, does not
> >allow the client to check revocation lists that the client trusts -- so
> >they are near to useless. Also, the client is  not able to check server certificates
> >(and certificates in the CA chains) against client-defined revocation lists
> > (VAs, for example).
> >
>
> PKIX specifies a means, the AIA extension, that allows a cert to point to
> where to look for the CRL on which it would appear.  Unfortunately, this
> facility has not been used in this environment, perhaps because of the lag
> between standards development and software development, but maybe it will
> be utilized in the future.

What you say shows that you know where to find the CRL for a cert. Now, before
you wade through that (huge) CRL, it may be useful to ponder what is the worth of
checking distrusted CRLs?

As I wrote some two years ago (URI certover.pdf) and still valid even
if the CRLDistributionPoint is specified in the server certificate and is used at
the client -- in SSL, the server is neither informed by the client what CAs to best
aim for in a ranking list  (CAs that are directly trusted by the client for
signature and CRLs, untrusted CAs directly trusted by a CA that
the client trusts, etc.), nor offers the client a list of CAs for the client to
choose which CA is trusted for what.

So, if we agree that checking distrusted CRLs is as worthless as
checking distrusted certificates, then I guess we agree that knowing
where to look for a CRL you distrust is worth nothing.

And, clearly, a confirmed conversation with a thief is not secure just
because it is confirmed by the thief himself. Nor, by his associate ;-)

Cheers,

Ed Gerck
______________________________________________________________________
http://www.mcg.org.br/authors/eg.htm                    [e-mail]




Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA07492 for <[e-mail]>; Wed, 15 Sep 1999 18:39:17 -0700 (PDT)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI4Q3700.TFN for <[e-mail]>; Thu, 16 Sep 1999 01:42:43 +0000 
Received: from nma.com ([209.21.28.112]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI4P7000.H3C; Thu, 16 Sep 1999 01:23:24 +0000 
Message-ID: <[e-mail]>
Date: Wed, 15 Sep 1999 18:42:46 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: [e-mail]
Subject: Re: Huge CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Williams wrote:

> > From: Ed Gerck [mailto:[e-mail]]
>
> > Peter Williams wrote (in part):
> >
> > > SSL does not involve certificates, if you read the design carefully.
> >
> > Sorry to disagree in part, Peter, but the client knows which CAs
> > are acceptable to the server exactly because SSL does not ignore
> > certificates (would that qualify as involve?).
>
> SSL was designed before certificates were added.

It shows that.

Cheers,

Ed Gerck




Received: from chirality.rsa.com (chirality.rsa.com [192.80.211.33]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA06888 for <[e-mail]>; Wed, 15 Sep 1999 17:56:37 -0700 (PDT)
Received: from eagle.rsa.com (eagle.rsa.com [192.80.211.35]) by chirality.rsa.com (8.8.8+Sun/notrash) with SMTP id SAA02115; Wed, 15 Sep 1999 18:01:51 -0700 (PDT)
Received: from tuna.rsa.com by eagle.rsa.com via smtpd (for chirality.rsa.com [192.80.211.33]) with SMTP; 16 Sep 1999 00:59:58 UT
Received: from dnai.com by tuna.rsa.com (SMI-8.6/SMI-SVR4) id RAA23092; Wed, 15 Sep 1999 17:59:53 -0700
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 15 Sep 1999 17:59:42 -0700
From: Michael Sierchio <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 2.2.8-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: [e-mail]
Subject: Re: Huge CRLs
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed Gerck wrote:
> 
> Peter Williams wrote:
> 
> > > > Ed Gerck wrote:
> > > >
> > > > >Further, the major X.509 security application today, SSL, does not
> > > > >check revocation lists -- so they are near to useless. Also,  the user is
> > > > >not able to check server certificates (and certificates in the  CA chains)
> > > > >against revocation lists.
> >
> > SSL does not involve certificates, if you read the design carefully.
> 
> Sorry to disagree in part, Peter, but the client knows which CAs are acceptable to the
> server exactly because SSL does not ignore certificates (would that qualify as involve?).

Peter's definition of a careful reading means that he believes that
no reasonable person can be at variance with his understanding.
Lord knows what he means by design.  SSL exists precisely because it 
was implemented before some IETF task force got its paws on it.  

-- 

Michael Sierchio <[e-mail]>

QUI ME AMET, CANEM MEUM ETIAM AMET.


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA06848 for <[e-mail]>; Wed, 15 Sep 1999 17:55:11 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id RAA07246; Wed, 15 Sep 1999 17:58:35 -0700 (PDT)
Received: from rsalaptop ([192.168.3.229]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id RAA03998; Wed, 15 Sep 1999 17:58:34 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Ed Gerck" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Huge CRLs
Date: Wed, 15 Sep 1999 18:00:34 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>

> -----Original Message-----
> From: Ed Gerck [mailto:[e-mail]]
> Sent: Wednesday, September 15, 1999 4:36 PM
> To: Peter Williams
> Cc: [e-mail]
> Subject: Re: Huge CRLs
> 
> 
> 
> 
> Peter Williams wrote:
> 
> > > > Ed Gerck wrote:
> > > >
> > > > >Further, the major X.509 security application today, SSL, does not
> > > > >check revocation lists -- so they are near to useless. 
> Also,  the user is
> > > > >not able to check server certificates (and certificates in 
> the  CA chains)
> > > > >against revocation lists.
> >
> > SSL does not involve certificates, if you read the design carefully.
> 
> Sorry to disagree in part, Peter, but the client knows which CAs 
> are acceptable to the
> server exactly because SSL does not ignore certificates (would 
> that qualify as involve?).

SSL was designed before certificates were added. Also, if you 
want to make an SSL (2) implementation without support
for the certs messages you can. Client auth is/was not
a required feature. Certs were not intrisic to SSL design.

Thats all Im trying to say. Lets not parse my English
for its philosophical roots.


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA06310 for <[e-mail]>; Wed, 15 Sep 1999 16:57:05 -0700 (PDT)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI4LCU00.HEN for <[e-mail]>; Thu, 16 Sep 1999 00:00:30 +0000 
Received: from nma.com ([209.21.28.121]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI4KFD00.93K; Wed, 15 Sep 1999 23:40:25 +0000 
Message-ID: <[e-mail]>
Date: Wed, 15 Sep 1999 17:00:31 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <v04020a02b4059bc76fed@[128.33.238.12]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed,
>
> Ed Gerck wrote:
> >CRLs, which were first thought to be a positive aspect of relying on CAs
> >as compared to PGP for instance, presents several unsolvable problems.
> >
> >For example, there may be a considerable delay (no warranties can be
> >found on on CAs contracts about upper limits for such delays) between the
> >actual need to revoke a certificate and the reflection of this need in a
> >certificate chain with different CAs.
>
> There also may be considerable delay between a compromise and discovery of
> a compromise, which intrduces delay into ANY revocation method, not just
> CRLs.  Many factors influence how quickly revocation activities will
> proceed, many are adminsitrative and not influenced by the choice of
> method, e.g., CRLs or OCSP.  In some systems with which we have experience,
> these administrative delays take longer, in aggregate, than the mean time
> between CRL issuance, suggesting that the use of CRLs is far from the
> limiting factor in determining timeliness of revocation notification.  As
> for a warranty re timeliness, I think it more relevant to note that several
> major CA service providers offer daily CRL issuance, and some issues new
> CRLs as often as every 6-12 hours.

Still, all that you say offers no justification (besides denying liability for it) why
couldn't CAs provide upper limits for *their* delays.  Forget about "discovery delay"
and other things that you mention and which I consider philosophical since they can
never be even estimated, and forget also about how often will the CA issue the
same stale CRL (maybe, even every second if you wish).  The point I mentioned
above is the delay between a need to revoke a cert (which need is materialized at
the CA as request to revoke, of course), and the reflection of this need in a
certificate chain with different CAs.  This is the real-world issue here -- and one
which is not addressed.

> >Also, requiring the user to check with a CA before sending a message
> >makes the use of multiple CAs much more difficult, unless they can be
> >convinced to work together, an interesting problem for competing
> >businesses.  Constant checking with a single CA also makes traffic
> >analysis much easier. Even if the attacker cannot intercept the
> >message which is sent, if the attacker can monitor the central CA
> >(with a single administrative order and a GAKware system to circumvent
> >any encryption), everyone's communication patterns can be seen.
> >Also, an attacker can fool a CA into revoking a key -- a denial of service
> >attack.
>
> First, one does not "check with a CA" under the traditional CRL model.

Neither did I say so -- but, requiring it won't be so useful because it makes
the use of multiple CAs more difficult and so on.  So, back to point one.

[The other topic you mention, on SSL vs. browsers, was already discussed
in my previous specific reply.]

Cheers,

Ed Gerck
______________________________________________________________________
http://www.mcg.org.br/authors/eg.htm                    [e-mail]




Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA05902 for <[e-mail]>; Wed, 15 Sep 1999 16:32:38 -0700 (PDT)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI4K8300.KFJ for <[e-mail]>; Wed, 15 Sep 1999 23:36:03 +0000 
Received: from nma.com ([209.21.28.121]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI4JBW00.H2Y; Wed, 15 Sep 1999 23:16:44 +0000 
Message-ID: <[e-mail]>
Date: Wed, 15 Sep 1999 16:36:05 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: [e-mail]
Subject: Re: Huge CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Williams wrote:

> > > Ed Gerck wrote:
> > >
> > > >Further, the major X.509 security application today, SSL, does not
> > > >check revocation lists -- so they are near to useless. Also,  the user is
> > > >not able to check server certificates (and certificates in the  CA chains)
> > > >against revocation lists.
>
> SSL does not involve certificates, if you read the design carefully.

Sorry to disagree in part, Peter, but the client knows which CAs are acceptable to the
server exactly because SSL does not ignore certificates (would that qualify as involve?).

First, the server can indeed send a message with a list of distinguished names  in the
SSL "certificate request" message to the client.  If SSL would ignore certs or not involve
them then this list of *certificate request* would have no reason to exist, no?  Second,
if we see what happens protocol-wise in SSL when the client replies  to this SSL message,
we will see that SSL reacts differently as a function of the *certificates* sent by the
client.

However, there is no corresponding list sent in the other direction (from the client to
the server) as allowed by the SSL protocol.  The effect of this **SSL asymmetry** is
that which I summarized above: SSL does not [allow the client] to check revocation lists
[that are meaningful to the client].

The interpolations above, within [ ], are all in the text I cited for context, at
http://www.mcg.org./br/cert.htm -- already some two years ago and still
valid.  I had no intention of being sloppy or msileading in my remark, just to save
space by providing the context by reference... a common technique used in
CAs' CPS ;-)))


> It may be time to standardize https which is a hypermedia security
> service, is really quite complex, and addresses framed security
> contexts, multiple sessions, connection teardown, host-id
> selection of keying material on the server, and various other
> matters peculiar to stateless web behavior in the context
> of hypermedia documents.

Agreed and let's not forget TSL as another element of this letter soup. But
SSL (TSL) is a tool used in https, which means that one should *first* deal
with some SSL (TSL) quirks like the client-server certificate choice
asymmetry I mentioned.

Cheers,

Ed Gerck
______________________________________________________________________
http://www.mcg.org.br/authors/eg.htm                    [e-mail]




Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA05389 for <[e-mail]>; Wed, 15 Sep 1999 15:59:24 -0700 (PDT)
Received: from scv3.apple.com (A17-129-200-139.apple.com [17.129.200.139]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id QAA05097 for <[e-mail]>; Wed, 15 Sep 1999 16:02:29 -0700 (PDT)
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 QAA25308 for <[e-mail]>; Wed, 15 Sep 1999 16:02:47 -0700 (PDT)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Wed, 15 Sep 1999 16:02:46 -0700
Subject: Re: Trust and client choices
From: "Aram Perez" <[e-mail]>
To: [e-mail]
Mime-version: 1.0
X-Priority: 3
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Steve,

> I suggest you review some of the literature on CA models that do not rely on
> global CA registries.

Where could one find such literature?

Thanks,
Aram Perez


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA04137 for <[e-mail]>; Wed, 15 Sep 1999 14:40:28 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id OAA05950; Wed, 15 Sep 1999 14:43:53 -0700 (PDT)
Received: from rsalaptop ([192.168.3.229]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id OAA29026; Wed, 15 Sep 1999 14:43:51 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Ed Gerck" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Huge CRLs
Date: Wed, 15 Sep 1999 14:45:52 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>

> -----Original Message-----
> From: Ed Gerck [mailto:[e-mail]]
> Sent: Wednesday, September 15, 1999 2:13 PM
> To: Stephen Kent
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Huge CRLs
> 
> 
> 
> 
> Stephen Kent wrote:
> 
> > >Further, the major X.509 security application today, SSL, does not
> > >check revocation lists -- so they are near to useless. Also, 
> the user is
> > >not able to check server certificates (and certificates in the 
> CA chains)
> > >against revocation lists.
> >
> > I think you are confusing SSL, the protocol, vs. implementations of SSL
> > (and https, in browsers.  Browsers have a number of defects in their
> > handling of certs, but it is not accurate to attribute this to SSL.


SSL does not involve certificates, if you read the design carefully. Its
processing is independent of the key distribution mechanism; any valid
means of distributing asymmetric keys is acceptable. Cipher suites
do not bind to any particular method of key distribution, in general.
(some of the poorer specification bind cipher suites to kerberos, 
breaking the architecture though; on well, purity has no value of 
itself.)

https is indeed a distinct protocol from SSL. its specification
is "fluid", and is well now well into its 5th version. Its defined largely
as that which Netscape and Microsoft web client/servers are 
interoperable on, with options and value add on each side. Use of 
SSL for secure data conferencing,  white boarding authorization, etc
and  other uses are not standardized. The securing
of the FrontPage protocol is similarly not standardized. These
all have security protocols built over and above SSL layer protocols,
like https.

It may be time to standardize https which is a hypermedia security
service, is really quite complex, and addresses framed security
contexts, multiple sessions, connection teardown, host-id
selection of keying material on the server, and various other
matters peculiar to stateless web behavior in the context
of hypermedia documents. It goes way beyond  just securing the 
TCP channel over which  http messages are exchanged with an few
integrity/confidentiality keys.

The integration of certificate validation with https (forming 
https "5"  if you  like) is an ongoing task, some of which was 
deployed with IE5. It may be better to use w3c to standardize
https, given its hypermedia orientation, however. IETF is
not too good at web stuff. One can perhaps expect https 
"6" to address XML signatures on the media items
that https governs and interacts with, now that these 
are gaining wide acceptance.
 


> 
> No, Steve, I am not confusing either or even both ;-) Pls check 
> the list archives 
> for my exchanges with Ben on this thread, especially those with 
> subjects "Re:
> Trust and client choices, was Re: Huge CRLs".  At least, Ben and 
> I agreed --
> which I must say does not happen so often ;-)
> 
> Cheers,
> 
> Ed Gerck
> ______________________________________________________________________
> http://www.mcg.org.br/authors/eg.htm                    [e-mail]
> 
> 


Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA03702 for <[e-mail]>; Wed, 15 Sep 1999 14:10:07 -0700 (PDT)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI4DME00.VEL for <[e-mail]>; Wed, 15 Sep 1999 21:13:26 +0000 
Received: from nma.com ([209.21.28.77]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI4CQ700.H2M; Wed, 15 Sep 1999 20:54:07 +0000 
Message-ID: <[e-mail]>
Date: Wed, 15 Sep 1999 14:13:28 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <v04020a02b4059bc76fed@[128.33.238.12]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> >Further, the major X.509 security application today, SSL, does not
> >check revocation lists -- so they are near to useless. Also, the user is
> >not able to check server certificates (and certificates in the CA chains)
> >against revocation lists.
>
> I think you are confusing SSL, the protocol, vs. implementations of SSL
> (and https, in browsers.  Browsers have a number of defects in their
> handling of certs, but it is not accurate to attribute this to SSL.

No, Steve, I am not confusing either or even both ;-) Pls check the list archives
for my exchanges with Ben on this thread, especially those with subjects "Re:
Trust and client choices, was Re: Huge CRLs".  At least, Ben and I agreed --
which I must say does not happen so often ;-)

Cheers,

Ed Gerck
______________________________________________________________________
http://www.mcg.org.br/authors/eg.htm                    [e-mail]




Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA03470 for <[e-mail]>; Wed, 15 Sep 1999 14:00:58 -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 OAA10182 for <[e-mail]>; Wed, 15 Sep 1999 14:03:52 -0700 (PDT)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FI4D6G00.O6Y; Wed, 15 Sep 1999 14:03:52 -0700 
Message-ID: <[e-mail]>
Date: Wed, 15 Sep 1999 14:03:46 -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: "Salz Rich" <[e-mail]>
CC: [e-mail]
Subject: Re: Huge CRLs
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------17E861C0368808A78A8447FE"

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

"Salz, Rich" wrote:

> A CA can delegate it's CRL signing to another entity by asserting
> the crlSign keyUsage bit.  The scheme you describe above might have
> efficiencies over CRL's, but it certainly introduces latency. But
> most importantly, I don't see how your scheme is different from
> crlSign delegation.

Whoa!  Is this right?  It's my understanding that the CA can delegate CRL
signing only by including a Distribution Point extension in the
certificates that it issues.  This extension may point at another subject
name that may create and sign CRLs for the CA.

Setting the crlSign bit is normal for creating subordinate CAs, and does
not usually indicate that the original CA means to delegate CRL creation
and signing.

Terry


--------------17E861C0368808A78A8447FE
Content-Type: text/x-vcard; charset=us-ascii;
 name="thayes.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Terry Hayes
Content-Disposition: attachment;
 filename="thayes.vcf"

begin:vcard 
n:Hayes;Terry
tel;work:[phone]
x-mozilla-html:TRUE
org:Netscape Communications Corp.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
x-mozilla-cpt:;-1
fn:Terry Hayes
end:vcard

--------------17E861C0368808A78A8447FE--



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA02834 for <[e-mail]>; Wed, 15 Sep 1999 13:47:19 -0700 (PDT)
Received: from [128.33.238.83] (TC083.BBN.COM [128.33.238.83]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA12669; Wed, 15 Sep 1999 16:50:36 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a08b405b0bc5f9e@[128.33.238.12]>
In-Reply-To:  <[e-mail]>
Date: Wed, 15 Sep 1999 16:25:24 -0400
To: Zahid Ahmed <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Trust and client choices
Cc: [e-mail]

At 5:58 PM -0700 9/14/99, Zahid Ahmed wrote:
>That is true; the whole CA model is based on a root
>level trust hierarchy. Compromising the set of trusted
>CA compromises the security at that site.
>
>However, w/o a global, perhaps even centralized, registry of
>CA Servers, the only way we can implement distributed PKI
>security is by some out-of-band, most likely business
>("trust") relationship with the CA vendor. Obviously such
>a registry should have a certain level of security to protect
>its data and a trusted server (e.g., via SSL/LDAP).
>
>I think we have gone thru this discussion before w.r.t. a DNS like
>model for registering CAs, but I don't see any standard
>specification related with it enabling registering/publishing
>CA identities.
>
>that seems to be fine for some web servers and browser
>vendors, but for many other PKI clients and servers
>this technical and business model is limiting.

Your characterization of "the whole CA model" is unduly narrow, perhaps
influenced too much by the specific choices made in the browsers.  I
suggest you review some of the literature on CA models that do not rely on
global CA registries.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA02771 for <[e-mail]>; Wed, 15 Sep 1999 13:47:03 -0700 (PDT)
Received: from [128.33.238.83] (TC083.BBN.COM [128.33.238.83]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA12629; Wed, 15 Sep 1999 16:50:19 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a06b405a9b4b71f@[128.33.238.12]>
In-Reply-To: <003301befef9$f41289c0$[e-mail]>
References: <[e-mail]>
Date: Wed, 15 Sep 1999 15:57:43 -0400
To: "Ambarish Malpani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Huge CRLs
Cc: <[e-mail]>, <[e-mail]>

Ambarish,

>1. Your mail server could do the validation and only send you
>messages that were validated (assuming you trust your mail server
>*and* your mail server has the same cert validation rules as you
>do).
>
>2. You could use the "Freshness Seal" method, where the sender of
>the mail (or the mail server), gets the revocation status proof
>and sends it to you with the message.
>
>In either case, the proof is obtained by somebody who is online.
>You get the proof when you go online to get the mail message. You
>can digest the proof in the "luxury" of your plane seat!

Note that the S/MIME RFCs describe a facility for the sender to include
CRLs (as well as certs) along with the message.  In many instances this
would provide a pretty reasonable basis for cert validation, and does not
require that one rely on a mail sever to perform the check nor on the
creation of a way to pass an OSCP token.  Of course, big CRLs might be
awkward here, but given the size of many message attachments ...

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA02755 for <[e-mail]>; Wed, 15 Sep 1999 13:47:01 -0700 (PDT)
Received: from [128.33.238.83] (TC083.BBN.COM [128.33.238.83]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA12536; Wed, 15 Sep 1999 16:49:59 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a02b4059bc76fed@[128.33.238.12]>
In-Reply-To: <[e-mail]>
References: <v04020a03b4002a7dc532@[128.89.0.111]>
Date: Wed, 15 Sep 1999 15:09:26 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Huge CRLs
Cc: [e-mail], [e-mail], [e-mail]

Ed,

>CRLs, which were first thought to be a positive aspect of relying on CAs
>as compared to PGP for instance, presents several unsolvable problems.
>
>For example, there may be a considerable delay (no warranties can be
>found on on CAs contracts about upper limits for such delays) between the
>actual need to revoke a certificate and the reflection of this need in a
>certificate chain with different CAs.

There also may be considerable delay between a compromise and discovery of
a compromise, which intrduces delay into ANY revocation method, not just
CRLs.  Many factors influence how quickly revocation activities will
proceed, many are adminsitrative and not influenced by the choice of
method, e.g., CRLs or OCSP.  In some systems with which we have experience,
these administrative delays take longer, in aggregate, than the mean time
between CRL issuance, suggesting that the use of CRLs is far from the
limiting factor in determining timeliness of revocation notification.  As
for a warranty re timeliness, I think it more relevant to note that several
major CA service providers offer daily CRL issuance, and some issues new
CRLs as often as every 6-12 hours.

>Also, requiring the user to check with a CA before sending a message
>makes the use of multiple CAs much more difficult, unless they can be
>convinced to work together, an interesting problem for competing
>businesses.  Constant checking with a single CA also makes traffic
>analysis much easier. Even if the attacker cannot intercept the
>message which is sent, if the attacker can monitor the central CA
>(with a single administrative order and a GAKware system to circumvent
>any encryption), everyone's communication patterns can be seen.
>Also, an attacker can fool a CA into revoking a key -- a denial of service
>attack.

First, one does not "check with a CA" under the traditional CRL model.  One
accesses a directory to acquire CRLs and if directories cache data, one
might access a single directory to acquire CRLs for more than one CA.
Monitoring of CRL: fetches provides some info about communication patterns,
but with local caching, the granularity of this info is not very fine,
e.g., someone at organization X requested the CRL for organization Y.  Many
users at X might then access the cached copy of the CRL prior to sending
messages to a variety of users ar Y.  Finally, one of the reasons that
revocation is often NOT instantaneous is that CAs usually require some form
of authentication by a party requesting revocation, precisely to counter
the denial of service attacks.

>Further, the major X.509 security application today, SSL, does not
>check revocation lists -- so they are near to useless. Also, the user is
>not able to check server certificates (and certificates in the CA chains)
>against revocation lists.

I think you are confusing SSL, the protocol, vs. implementations of SSL
(and https, in browsers.  Browsers have a number of defects in their
handling of certs, but it is not accurate to attribute this to SSL.

>An examplary case regarding  CRLs, is that they are a will to revoke but
>not an actual revocation. Few recognize that CRLS are a solution to a
>non-existent problem ... while the real problem is left utterly unsolved. The
>non-existent problem solved by CRLs is how to communicate that a
>certificate is no longer valid ... because if a certificate were really no
>longer valid (as it should be) then no one would need to find a CRL
>to know about it.

I just love these philosophical musings ...

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA02742 for <[e-mail]>; Wed, 15 Sep 1999 13:46:59 -0700 (PDT)
Received: from [128.33.238.83] (TC083.BBN.COM [128.33.238.83]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA12619 for <[e-mail]>; Wed, 15 Sep 1999 16:50:17 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a05b405a7f44ded@[128.33.238.12]>
In-Reply-To: <0ee101befef6$00d6f550$[e-mail]>
References: <[e-mail]>
Date: Wed, 15 Sep 1999 15:52:05 -0400
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: CPs and CPS

>If PKIX wants to own this stuff formally then the Steve and Warwick might
>want to setup a hit-squad to take the Auditor Guidelines that were submitted
>to the ABA by Pat Cain, et al. and spin that into a PKIX document. I would
>also suggest that the PKIX team be willing to work formally with the ABA on
>its efforts in creating just these documents, to insure that the focus of
>the documents remains anchored in real technology so it is doable.

What Todd seems to be saying is that he is still disappointed that (as a
result of discussions with the security area director, and with the ISOC VP
for standards) I elected to not establish a formal liasion relationship
with the ABA committee.  A formal liasion was rejected because

	- neither a WG nor the IETF establishes such relationships
	- the ISOC, which does establish such relationships, does not do so
with national (vs. international) organizations
	- of the people consulted, only Todd believed that there was
significant benefit to formal relationship, given the informal ties we
already have via cross membership between the two groups.

Apparently this explanation was not satisfactory to Todd.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA02728 for <[e-mail]>; Wed, 15 Sep 1999 13:46:55 -0700 (PDT)
Received: from [128.33.238.83] (TC083.BBN.COM [128.33.238.83]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA12595; Wed, 15 Sep 1999 16:50:03 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a03b405a1d8de51@[128.33.238.12]>
In-Reply-To: <[e-mail]>
References: <v04020a03b4002a7dc532@[128.89.0.111]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 15 Sep 1999 15:33:31 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Huge CRLs
Cc: [e-mail], [e-mail]

Ed,

>The first interesting question raised here is that of trust -- I cannot assume
>or favor the notion that there is only one CA that the client MUST trust,
>which  CA is by the way the ONE that the *other party* (the server) has
>chosen ;-)

In general, two parties are free to choose different CAs as issuers of
their respective certificates.  Thus each party always has to work to find
a path for validating the other party's certificate.  Why is this news to
you, Ed? (By the way, you continue to equate SSL with the cert processing
implemented in the two major browsers, which is inaccurate.)

A client can elect to accept the "root CAs" preconfigured into his browser,
or can remove them and add new ones after performing whatever form of
review that the user deems fit.  Thus a client has the ability to specify
the set of CAs that he will accept as a basis for validating server certs.
In practice, though, only three root CAs issue certs to servers in the
public environment, and just one of these (Verisign) issues the vast
majority of these certs.  So, if one were to choose to not accept server
certs issued by Verisign, one would not be able to communicate security
with many servers that make use of SSL.

>So, since SSL does not offer a client-mechanism to decide who to trust for
>what, and since this also translates into an anti-competitive issue built
>right
>into the SSL protocol, I see then that the decision of trust is, from the
>first
>moment, removed from the client. Both for certificates and for CRLs -- which
>would not have to be provided the issuing CA.  So, there is a second decision
>of trust removed by the SSL protocol -- the server and the client have no
>choice for VA and must use the issuing CA.

Your first assertion here is correct, i.e., a shortcoming of the browser
(not SSL) cert processing is that it does not allow one to specify which
CAs are trusted to vouch for which certs, something that can be better
managed with the use of the NameConstraints extension. However, given the
TTP model on which secure access to public web sites is based, this
extension would not help much.

>So, where should the client look for the CRL? At the CA site that the
>client does
>not trust?  Or, cannot reach?  What URL? How about redundancy, alternatives?
>
>The conclusion IMO is that which I commented first, but edited to stress the
>client context. That the major X.509 security application today, SSL, does not
>allow the client to check revocation lists that the client trusts -- so
>they are near
>to useless. Also, the client is  not able to check server certificates
>(and certificates
>in the CA chains) against client-defined revocation lists (VAs, for example).
>
>The alternative for the client is to proceed manually, outside of SSL. But, we
>know, users do not have the training to use a complicated secure procedure
>if a simpler and unsafe procedure is just a click away.
>
>For the server, however, SSL affords a better procedure since the client knows
>which CAs the server trusts for what, as I commented above

PKIX specifies a means, the AIA extension, that allows a cert to point to
where to look for the CRL on which it would appear.  Unfortunately, this
facility has not been used in this environment, perhaps because of the lag
between standards development and software development, but maybe it will
be utilized in the future.

Steve


Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA29802 for <[e-mail]>; Wed, 15 Sep 1999 09:14:41 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id MAA01297 for <[e-mail]>; Wed, 15 Sep 1999 12:17:28 -0400 (EDT)
Received: from lncora06.firstdata.com ([206.201.60.104]) by mailgw.firstdata.com with SMTP id MAA19239 for <[e-mail]>; Wed, 15 Sep 1999 12:17:27 -0400 (EDT)
Received: from 10.2.52.30 by lncora06.firstdata.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v3.6); Wed, 15 Sep 99 12:15:11 -0400
X-Server-Uuid: 28680605-564e-11d3-99f5-0004ac9d9957
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852567ED.00595233 ; Wed, 15 Sep 1999 12:15:37 -0400
X-Lotus-FromDomain: FDC
To: "Robert Moskowitz" <[e-mail]>
cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 15 Sep 1999 08:16:36 -0700
Subject: Re: Huge CRLs
MIME-Version: 1.0
X-WSS-ID: 1BC11985313215-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

some of the issues in financial infrastructure

certificate binds some set of information which tends to relatively stable
state, certificates don't handle time series aggregation and/or realtime ... the
certificate bound information tends to be a subset of the information found in
accounts records ... which are the mainstay of current financial
infrastructures. the purpose of these certificates is to allow a move away from
centralized, account-record processing to independent, distributed processing.
emerging issue in the consumer world (including consumer financial world) is the
concern about abstracting privacy information for widely distributed processing
(i.e. the inclusion of any information in a certificate that might possibly
identify the consumer).

CRLs is an attempt to address some subset of the problem represented by
certificate information staleness. From a scaling standpoint, CRLs have
shortcoming that they tend to be proportional to the population size ... not
proportional to the work/transactions performed.

>From a financial infrastructure standpoint ... it might be possible to veiw
certificates as a means of distributing relatively stable information from
account records into offline environments ... possibly involving the ability to
perform low-value operations not requiring the timeliness and/or aggregation
information dependent on account record implemenations (especially if no
identity information and/or anything related to a consumer is involved in the
certificate).

However, for financial operations that do have to touch account records (because
of possibly something like transaction aggregation, i.e. the current account
balance or privacy issues) ... then it follows that not only aren't CRLs
approprait but the certificates themselves are superfulous (i.e. we can alwas
show that for any combination of information that can be bound in certificate
...a superset of that can be "bound" in an account record).

This sort of abstraction then can be used to characterize evern Certification
Authority implemenation ... as the Certificate Authority contains "master"
account record copies of the information bound into certificates. Certificates
can propogate this information into a distributed environment involving an
arbritrary large (and possibly unknown) number of locations. CRLs is then an
attempt to contact all of this arbritary large number of locations regarding the
validity &/or staleness of certificate based information. Therefor, CRL
implemenation scaling can be an issue of both proportional to the population
size and also proportional to the possible number of locations (i.e. not actual
number of relying party locations where actually certificate exists but all
possible relying party locations where it might exist).

For arbritrary large certificate population (N) with arbritrary large number of
possible relying parties (M) than CRL processing becomes proporational the NxMxI
product (certificate population size times relying population size times
propability of information becoming stale/invalid).

By comparison a RADIUS and/or centrlized authentication mechanism has processing
overhead proportional to the number of transactions. So for an online
environment, the efficiency issues becomes whether the
     P(NxMxI) > P(trans)

i.e. is the CRL overhead (proportional to size of certificate population times
size of relying party population times probability information changes) greater
than contacting an authentication server on every transaction.

So one at one extreme is online requiring timely, aggregated and/or privacy
information access to the account record ... making use of a certificate (with
replicated, stale, subset  information) superfulous (as well as unnecessary
expense and infrastructure especially when information binding & authentication
infrastructure already exists).

At the other exterme is offline infrastructure with no existing information
binding & authentication infrastructure (aka 1980s offline email) where even
replicated, stale, information (bound in a certificate) may better than no
information.

In between are online environments needing authentication infrastructure with
distributed operation (with possibility of distributed information bound into
certificates) vis-a-vis online direct access with higher degrees of information
timelyness. The trade-offs come down on the side of certificates with low
propability of information staleness, small certificate populations, small
number of relying parties, no privacy issues and very large number of
transactions. The trade-offs would be away from certificates as the probability
of information staleness increases, there are privacy issues, the size of the
certificate population increases, the number of relying parties increases and/or
the number of transactions decrease.

Systems that have overheads/processing proportional to size of population & not
amount of work performed (or number of transactions) tend to run into scaling
problems ... if nothing else funding & processing capability tends to be size
based on amount of work being done  ... as opposed to size of pupulation.

As an aside, one characteristic contrasting the certificate-based processing as
fully distributed (potentially even down to both physical and logical
point-of-sale) and account-based "centralized" processing ... the current
account-based consumer electronic financial processing is hardly centralized.
All transactions against a specific account are routed to the processing unit
responsible for that account ... but there is a large (somewhat mesh) network
interconnecting millions of point-of-sale with possibly tens of thousands of
account-record processing locations.





Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA28708 for <[e-mail]>; Wed, 15 Sep 1999 07:58:14 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 0FD6115532; Wed, 15 Sep 1999 11:01:01 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 72D137C051; Wed, 15 Sep 1999 11:01:01 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2232.9) id <S5N1TNRV>; Wed, 15 Sep 1999 11:01:01 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>
Cc: [e-mail], "Salz, Rich" <[e-mail]>
Subject: RE: Huge CRLs
Date: Wed, 15 Sep 1999 11:00:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

>but if anybody ever
>manages to break into your responder and get access to your private
>key, your whole OCSP response system is open to compromise.

Uh yeah, so?  "If the private key of XXX is compromised than the
service that XXX provides becomes suspect."  Without getting into
the whole recent NR thread, this really does verge on a PK tautology,
doesn't it?

Depending on the protection needed, there are a number of approaches,
including tamper-evident hardware, distributed signing using various
key-splitting methods, etc.

>With CRTs, you can acctually have the Tree Issuer be separate from
>the CRT responders. The Tree Issuer has access to your CRT private
>key and can create new CRTs, which it then distributes to one or
>more CRT responders (which don't have the highly trusted private
>key), which actually provide the CRT responses.

A CA can delegate it's CRL signing to another entity by asserting
the crlSign keyUsage bit.  The scheme you describe above might have
efficiencies over CRL's, but it certainly introduces latency. But
most importantly, I don't see how your scheme is different from
crlSign delegation.

Your initial note on this subject said CRT's are better than OCSP,
but from what I've read so far, I conclude that CRT's essentially the
same as CRL's, except that they're proprietary technology.
	/r$


Received: from caladan.verisign.com (CALADAN.VERISIGN.COM [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA28465 for <[e-mail]>; Wed, 15 Sep 1999 07:52:17 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA12022; Wed, 15 Sep 1999 07:52:32 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA18161; Wed, 15 Sep 1999 07:53:54 -0700 (PDT)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SF5SHVVB; Wed, 15 Sep 1999 07:53:55 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Huge CRLs
Date: Wed, 15 Sep 1999 10:55:47 -0400
Message-ID: <000201beff8a$64abc120$[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]>

> But there is also third case, which is that the server somehow 
> updates my cache of status information for everyone that is in 
> my address book, together with the authoritative status for the 
> current mail (i.e., the address book is updated).  

Two approaches Bob,

1) Make a significantly large OCSP request listing every certificate
that is likely to be used (the whole address book is likely to be
overkill). Cache the response.

2) Use OCDP to chop up the CRLs into reasonably small chunks. Develop
some retrieval mechanism (perhaps an OCSP variant).

Both approaches are equivalent in the limit of a very small CRL.


The case of recieiving email is simpler. The mail server should have
the ability to push the OCSP token or CRL partition down with the email.
[I somehow doubt that this is within the capability of sendmail's
macro language but so what, plenty of better mail servers exist.]

Note that there would be problems with this approach if the signed
message was enclosed in an encrypted email:-)


The key to this problem is to make the validation information compact 
enough. OCSP is therefore a very suitable solution. If we assume that
the mail client and server will be communicating over an encrypted
line (SSL or IPSEC) we can in any case expect a public key operation
to be involved.


	Phill




Received: from web305.yahoomail.com (web305.mail.yahoo.com [128.11.68.236]) by mail.proper.com (8.9.3/8.9.3) with SMTP id GAA27503 for <[e-mail]>; Wed, 15 Sep 1999 06:42:32 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [167.70.219.32] by web305.mail.yahoo.com; Wed, 15 Sep 1999 06:49:00 PDT
Date: Wed, 15 Sep 1999 06:49:00 -0700 (PDT)
From: Dennis Nwaigbo <[e-mail]>
Subject: RE: Trust and client choices
To: Bob Jueneman <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Where is the book in question?

cheers,


--- Bob Jueneman <[e-mail]> wrote:
> The intent of the book is to provide some reasonable
> 
> out-of-band way of verifying the top level CA's
> certificates.
> If you think about it, publishing a CA's certificate
> in their 
> own web site is rather circular logic.  How would
> you know
> that it is really them?
> 
> On the other hand, the book publishers (at the time
> we 
> talked to them) had reasonable levels of assurance
> in their
> procedural mechanisms, but weren't willing to put
> their money 
> where their mouth with any real amount of liability.
> 
> (I don't blame, them, however.  You'd have to sell a
> lot
> of books to cover that much liability.)
> 
> So the major CAs provide their top level roots
> directly 
> to the major vendors to incorporate in their
> software.
> 
> IMPORTANT POINT:  If you don't trust the vendor of
> your
> relying party software, all of the trust that you
> have in all of PKI
> goes straight out the window!
> 
> All I have to do as the vendor is simply answer
> "trusted" to 
> any question you ask, and you are hosed.
> 
> Bob (Trust me -- have I ever lied to you before? 
> Well, recently?) Jueneman
> 
> 
> 
> >>> Zahid Ahmed <[e-mail]>
> 09/14/99 03:49PM >>>
> 
> 
> The attached book's review at amazaon.com claims
> that the
> book contains the public keys of many CA's root
> certificate.
> 
> I think this is nice; but, where is the web sites
> and/or
> publicly accessible LDAP server that is publishing
> all
> (or most of the generally used) CA's public
> certificates
> such that servers can register trusted CAs. E.g.,
> are
> the CA service providers (e.g., Verisign, Entrust,
> GE, Wells Fargo, other european CAs,) publishing
> their
> CA pubic root certificates at their web sites?
> 
> If not, why not?
> 
> 
> thanks,
> Zahid
> 
> 
> > Zahid Ahmed wrote:
> > > 
> > > to trust CAs, the server needs to be aware of
> the
> > > CA's public root certificate.
> > > 
> > > do you know where such root certificate are
> published?
> > > e.g., for verisign, entrust, thwarte, etc.
> > > 
> > > is there a global CA root certificate
> directory/web server?
> > 
> > "The Global Internet Trust Register", pub. MIT
> press?
> > 
> > Cheers,
> > 
> > Ben.
> > 
> > --
> 
> 
> +-------------------------------------------------------------+
> + For information about the cert-talk mailing list,
> including +
> + archives and how to subscribe and unsubscribe,
> visit:       +
> +          http://www.structuredarts.com/cert-talk  
>          +
> +-------------------------------------------------------------+
> 

===
DENNIS NWAIGBO (w-e-e-b-o)
Network Security Engineer
Bank of America Corporation
Work: 214.508.6594
Home: 972.986.5107
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA21971 for <[e-mail]>; Wed, 15 Sep 1999 04:03:48 -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 HAA04174; Wed, 15 Sep 1999 07:06:40 -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-cmp-tcp-00.txt
Date: Wed, 15 Sep 1999 07:06:39 -0400
Sender: [e-mail]

--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		: Using TCP as a Transport Protocol for CMP
	Author(s)	: R. Tschalar,  A. Kapoor, C. Adams
	Filename	: draft-ietf-pkix-cmp-tcp-00.txt
	Pages		: 9
	Date		: 14-Sep-99
	
This document describes how to layer Certificate Management
Protocols [CMP] over [TCP]. A method for doing so is described in
section 5.2 of [CMP], but that method does not solve problems
encountered by implementors. This document specifies an enhanced
method which extends the protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-tcp-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-cmp-tcp-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-cmp-tcp-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-cmp-tcp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmp-tcp-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 ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA15424 for <[e-mail]>; Wed, 15 Sep 1999 02:50:07 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id CAA02128; Wed, 15 Sep 1999 02:53:29 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id CAA15766; Wed, 15 Sep 1999 02:53:29 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Huge CRLs
Date: Wed, 15 Sep 1999 02:57:08 -0700
Message-ID: <006201beff60$acd64760$[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]>

Hi Dave,
    A few incorrect statements in your mail:

1. OCSP can cover multiple certs in a single query (this is *not*
version 2 of the OCSP draft)

2. You could decide to implement an OCSP server that caches its
responses, or have a client cache OCSP responses, allowing you
to deal with stored certs also.

3. You are right about the ability to make CRLs or rather CRLDPs)
as large or small as you want to. If you make it too small (one DP
per cert) you end up with something worse than OCSP (because you
need to create a new DP for every cert, independent of whether
it is revoked or good). If you create responses on the fly, you
are really doing OCSP, but making the format of your responses look
like DPs - actually, OCSP does allow you to specify other response
type formats and I always thought people would want CRLs to be one
of the types - actually remember talking to Carlisle about it).


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, September 14, 1999 2:29 PM
> To: [e-mail]; [e-mail]
> Subject: RE: Huge CRLs
> 
[DELETED STUFF...]
> 
> 
> Phill,
> 
> Referring to last year's discussion is fine, but repeating last year's
> fallacies is not helpful when the topic resurfaces .
> 
> There is no dichotomy between "online" and "blacklist" style 
> revocation.
> Online is on one axis, the opposite end of which is store-and-forward.
> "List" is on an independent axis, namely the integers 1..N.
> 
> An OCSP response is online, and it covers a list of exactly 
> one certificate.
> 
> A CRL could be generated and retrieved online, or could be generated
> and stored for later retreival.  A CRL can cover any number of
> certificates, from N down to one. The requirement space covered
> is thus:
>                  OCSP  CRL
>                  ----  ----
> Online, 1 cert    y     y
> Online, N certs         y
> Stored, 1 cert          y
> Stored, N certs         y
> 
> 
> ---------- [from a later message] ----------
> 
> > The significance of OCSP is this. It is not sensible, practical or
> > ecconomic to build a revocation infrastructure which addresses
> > the planetary scale PKI at present while the size of the largest
> > PKIs is in the small millions. OCSP permits a decoupling of the
> > revocation/validation problem from the client implementation.
> 
> How is OCSP unique in this respect?  If you posit the existence of
> a revocation server findable by and trusted by the client, that server
> could return a CRL, or it could return an OCSP response.  The
> advantage of returning a list is that the client might not have to
> query as frequently.
> 
> 
> --------- [Lynn Wheeler adds] ----------
> 
> > Also, CRL operation tends to be a scaleup issue proportional to the
> > size of the population ...
> 
> Again, a matter of implementation.  The population covered by a CRL is
> a tunable parameter which can be set anywhere between 1 and the entire
> population.
> 
> 
> +-------------------------------------------------------------+
> + For information about the cert-talk mailing list, including +
> + archives and how to subscribe and unsubscribe, visit:       +
> +          http://www.structuredarts.com/cert-talk            +
> +-------------------------------------------------------------+
> 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA14946 for <[e-mail]>; Wed, 15 Sep 1999 02:39:03 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id CAA02093; Wed, 15 Sep 1999 02:42:25 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id CAA15611; Wed, 15 Sep 1999 02:42:21 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Huge CRLs
Date: Wed, 15 Sep 1999 02:46:00 -0700
Message-ID: <006101beff5f$1ef23b80$[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]>

Hi Bob,
    Yes, there is a product that will go through your address
book and try to validate all the certs in them - it is our
Address Book Validator. It works with Outlook only (sorry). Is
installed on your desktop and runs periodically through all the
addresses in your address book.

Doesn't address the issue of you receiving email from somebody with
a cert you don't already have in your address book (our email
validator does that).

Is this what you were interested in?

A

---------------------------------------------------------------------
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 Bob
> Jueneman
> Sent: Tuesday, September 14, 1999 4:53 PM
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Huge CRLs
> 
> 
> I agree with the feasibility of both cases, and we've been thinking 
> about both.
> 
> But the tradeoff of having the server, vs. the client, do the 
> cryptographic
> validation is a very serious server performance issue,.
> 
> In addition, there are even worse issue of trust management. 
> Do I, as the individual who is making the decision, necessarily
> trust my server to make my decisions for me, whether that server 
> is operated by my company, or by an independent ISP?
> 
> What if it is personal mail?
> 
> And clearly the server is not going to apply content-based transaction
> rules -- about the best it can do is the syntactic validation in 
> accordance with the PKIX rules. And I'm not certain I would trust 
> it to enforce Policy OID constraints, etc.
> 
> But there is also third case, which is that the server somehow 
> updates my cache of status information for everyone that is in 
> my address book, together with the authoritative status for the 
> current mail (i.e., the address book is updated).  
> 
> Don't bother sending me the CRL for everyone who ever moved after 
> getting a certificate from VeriSign -- that's like sending me 
> a high priority
> message telling me that the corporate link to Pago Pago is 
> going down --
> I don't care.
> 
> I think that solution places the trust back where it belongs -- on 
> the individual user's desktop, not far away from his eyeballs.
> 
> Is there a protocol that would do that conveniently, without 
> requiring 
> that my ISP become a trusted third party?
> 
> Bob
> 
> 
> >>> "Ambarish Malpani" <[e-mail]> 09/14/99 03:41PM >>>
> Bob, there are actually 2 ways I would address that:
> 
> 1. Your mail server could do the validation and only send you
> messages that were validated (assuming you trust your mail server
> *and* your mail server has the same cert validation rules as you
> do).
> 
> 2. You could use the "Freshness Seal" method, where the sender of
> the mail (or the mail server), gets the revocation status proof
> and sends it to you with the message.
> 
> In either case, the proof is obtained by somebody who is online.
> You get the proof when you go online to get the mail message. You
> can digest the proof in the "luxury" of your plane seat!
> 
> 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: Bob Jueneman [mailto:[e-mail]] 
> > Sent: Tuesday, September 14, 1999 8:29 AM
> > To: [e-mail]; [e-mail]; 
> [e-mail];
> > [e-mail]; [e-mail] 
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail] 
> > Subject: Re: Huge CRLs
> > 
> > 
> > On the other end of the time spectrum, try using OCSP, or any 
> > other protocol other than CRLs, in disconnected mode while 
> > you are on an airplane reading your signed e-mail.
> > 
> > Bob
> > 
> > >>> Robert Moskowitz <[e-mail]> 09/13/99 04:44AM >>>
> > At 10:29 AM 9/10/1999 -0400, [e-mail] wrote:
> > 
> > >CRLs in any form are a fundamentally inadequate approach to 
> > solving practical 
> > >problems and in most cases cannot meet business requirements 
> > for even small 
> > >scale infrastructures.  CRLs were a good idea when the 
> > terribly impractical 
> > >people who developed them were working on paper and not such 
> > a great idea 
> > >when you have to turn paper into production systems.   CA 
> > revocations 
> > >experiments done on practical deployments (real world 
> > machines, apps, and 
> > >users) of even small PKIs will demonstrate that complying 
> > with your own 
> > >policy won't happen in the real world if you base your 
> > revocation hopes on 
> > >CRLS.
> > >Why are you messing with them?
> > >
> > Try addressing REALTIME validation.  OCSP caching MIGHT work, 
> > but an IPsec
> > device has millisecs to validate; no time for network latency 
> > to retrieve info.
> > 
> > Robert Moskowitz
> > ICSA
> > Security Interest EMail: [e-mail] 
> > 
> 
> +-------------------------------------------------------------+
> + For information about the cert-talk mailing list, including +
> + archives and how to subscribe and unsubscribe, visit:       +
> +          http://www.structuredarts.com/cert-talk            +
> +-------------------------------------------------------------+
> 


Received: from fw1b.telekom.de (gw1.telekom.de [194.25.15.11]) by mail.proper.com (8.9.3/8.9.3) with SMTP id XAA06143 for <[e-mail]>; Tue, 14 Sep 1999 23:29:13 -0700 (PDT)
Received: by fw1b.telekom.de; (5.65v4.0/1.3/10May95) id AA14224; Wed, 15 Sep 1999 08:32:33 +0200
Received: from Q8P65.blf01.telekom.de by U8PW4.blf01.telekom.de with ESMTP for [e-mail]; Wed, 15 Sep 1999 08:33:21 +0200
Received: from u8p11.blf01.telekom.de by q8p65.blf01.telekom.de with ESMTP for [e-mail]; Wed, 15 Sep 1999 08:32:26 +0200
Received: by U8P11.blf01.telekom.de with Internet Mail Service (5.5.2448.0) id <R9GTTWLG>; Wed, 15 Sep 1999 08:32:26 +0200
Message-Id: <056BFE552B14D311BD8A0800060D98EC229245@u8p13>
From: "Trenker, Stefan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: subscribe
Date: Wed, 15 Sep 1999 08:32:24 +0200
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAA06145

subscribe

Stefan Trenker
Senior IT-Systemexpert
IT-Directory Services and 
IT-Security Management Systems

DeTeCSM GmbH
TBS/PAM2 Darmstadt
Palaswiesenstraße 182
D-64293 Darmstadt

Tel.: [phone] - 6115
Fax: [phone] - 3887
mailto:[e-mail]
http://www.DeTeCSM.de
http://X500.Telekom.de



Received: from generalserver3.commerceone.com (mail.commerceone.com [204.71.220.19]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA12992 for <[e-mail]>; Tue, 14 Sep 1999 17:58:36 -0700 (PDT)
Received: by ip5-19.5.20.172.in-addr.arpa with Internet Mail Service (5.5.2448.0) id <SVA8V42C>; Tue, 14 Sep 1999 17:57:56 -0700
Message-ID: <[e-mail]>
From: Zahid Ahmed <[e-mail]>
To: Bob Jueneman <[e-mail]>, [e-mail]
Subject: RE: Trust and client choices
Date: Tue, 14 Sep 1999 17:58:02 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="ISO-8859-1"

That is true; the whole CA model is based on a root
level trust hierarchy. Compromising the set of trusted
CA compromises the security at that site.

However, w/o a global, perhaps even centralized, registry of 
CA Servers, the only way we can implement distributed PKI
security is by some out-of-band, most likely business
("trust") relationship with the CA vendor. Obviously such
a registry should have a certain level of security to protect
its data and a trusted server (e.g., via SSL/LDAP).

I think we have gone thru this discussion before w.r.t. a DNS like
model for registering CAs, but I don't see any standard
specification related with it enabling registering/publishing 
CA identities. 

that seems to be fine for some web servers and browser
vendors, but for many other PKI clients and servers
this technical and business model is limiting. 


> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]]
> Sent: Tuesday, September 14, 1999 5:06 PM
> To: Zahid Ahmed; [e-mail]
> Cc: [e-mail]
> Subject: RE: Trust and client choices
> 
> 
> The intent of the book is to provide some reasonable 
> out-of-band way of verifying the top level CA's certificates.
> If you think about it, publishing a CA's certificate in their 
> own web site is rather circular logic.  How would you know
> that it is really them?
> 
> On the other hand, the book publishers (at the time we 
> talked to them) had reasonable levels of assurance in their
> procedural mechanisms, but weren't willing to put their money 
> where their mouth with any real amount of liability.
> 
> (I don't blame, them, however.  You'd have to sell a lot
> of books to cover that much liability.)
> 
> So the major CAs provide their top level roots directly 
> to the major vendors to incorporate in their software.
> 
> IMPORTANT POINT:  If you don't trust the vendor of your
> relying party software, all of the trust that you have in all of PKI
> goes straight out the window!
> 
> All I have to do as the vendor is simply answer "trusted" to 
> any question you ask, and you are hosed.
> 
> Bob (Trust me -- have I ever lied to you before?  Well, recently?)
> Jueneman
> 
> 
> 
> >>> Zahid Ahmed <[e-mail]> 09/14/99 03:49PM >>>
> 
> 
> The attached book's review at amazaon.com claims that the
> book contains the public keys of many CA's root certificate.
> 
> I think this is nice; but, where is the web sites and/or
> publicly accessible LDAP server that is publishing all
> (or most of the generally used) CA's public certificates
> such that servers can register trusted CAs. E.g., are
> the CA service providers (e.g., Verisign, Entrust,
> GE, Wells Fargo, other european CAs,) publishing their
> CA pubic root certificates at their web sites?
> 
> If not, why not?
> 
> 
> thanks,
> Zahid
> 
> 
> > Zahid Ahmed wrote:
> > > 
> > > to trust CAs, the server needs to be aware of the
> > > CA's public root certificate.
> > > 
> > > do you know where such root certificate are published?
> > > e.g., for verisign, entrust, thwarte, etc.
> > > 
> > > is there a global CA root certificate directory/web server?
> > 
> > "The Global Internet Trust Register", pub. MIT press?
> > 
> > Cheers,
> > 
> > Ben.
> > 
> > --
> 


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id RAA12362 for <[e-mail]>; Tue, 14 Sep 1999 17:05:16 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 14 Sep 1999 18:05:44 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Tue, 14 Sep 1999 18:05:39 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Trust and client choices
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 RAA12363

The intent of the book is to provide some reasonable 
out-of-band way of verifying the top level CA's certificates.
If you think about it, publishing a CA's certificate in their 
own web site is rather circular logic.  How would you know
that it is really them?

On the other hand, the book publishers (at the time we 
talked to them) had reasonable levels of assurance in their
procedural mechanisms, but weren't willing to put their money 
where their mouth with any real amount of liability.

(I don't blame, them, however.  You'd have to sell a lot
of books to cover that much liability.)

So the major CAs provide their top level roots directly 
to the major vendors to incorporate in their software.

IMPORTANT POINT:  If you don't trust the vendor of your
relying party software, all of the trust that you have in all of PKI
goes straight out the window!

All I have to do as the vendor is simply answer "trusted" to 
any question you ask, and you are hosed.

Bob (Trust me -- have I ever lied to you before?  Well, recently?) Jueneman



>>> Zahid Ahmed <[e-mail]> 09/14/99 03:49PM >>>


The attached book's review at amazaon.com claims that the
book contains the public keys of many CA's root certificate.

I think this is nice; but, where is the web sites and/or
publicly accessible LDAP server that is publishing all
(or most of the generally used) CA's public certificates
such that servers can register trusted CAs. E.g., are
the CA service providers (e.g., Verisign, Entrust,
GE, Wells Fargo, other european CAs,) publishing their
CA pubic root certificates at their web sites?

If not, why not?


thanks,
Zahid


> Zahid Ahmed wrote:
> > 
> > to trust CAs, the server needs to be aware of the
> > CA's public root certificate.
> > 
> > do you know where such root certificate are published?
> > e.g., for verisign, entrust, thwarte, etc.
> > 
> > is there a global CA root certificate directory/web server?
> 
> "The Global Internet Trust Register", pub. MIT press?
> 
> Cheers,
> 
> Ben.
> 
> --



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id QAA12070 for <[e-mail]>; Tue, 14 Sep 1999 16:50:15 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 14 Sep 1999 17:53:17 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Tue, 14 Sep 1999 17:53:14 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Huge CRLs
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 QAA12072

I agree with the feasibility of both cases, and we've been thinking 
about both.

But the tradeoff of having the server, vs. the client, do the cryptographic
validation is a very serious server performance issue,.

In addition, there are even worse issue of trust management. 
Do I, as the individual who is making the decision, necessarily
trust my server to make my decisions for me, whether that server 
is operated by my company, or by an independent ISP?

What if it is personal mail?

And clearly the server is not going to apply content-based transaction
rules -- about the best it can do is the syntactic validation in 
accordance with the PKIX rules. And I'm not certain I would trust 
it to enforce Policy OID constraints, etc.

But there is also third case, which is that the server somehow 
updates my cache of status information for everyone that is in 
my address book, together with the authoritative status for the 
current mail (i.e., the address book is updated).  

Don't bother sending me the CRL for everyone who ever moved after 
getting a certificate from VeriSign -- that's like sending me a high priority
message telling me that the corporate link to Pago Pago is going down --
I don't care.

I think that solution places the trust back where it belongs -- on 
the individual user's desktop, not far away from his eyeballs.

Is there a protocol that would do that conveniently, without requiring 
that my ISP become a trusted third party?

Bob


>>> "Ambarish Malpani" <[e-mail]> 09/14/99 03:41PM >>>
Bob, there are actually 2 ways I would address that:

1. Your mail server could do the validation and only send you
messages that were validated (assuming you trust your mail server
*and* your mail server has the same cert validation rules as you
do).

2. You could use the "Freshness Seal" method, where the sender of
the mail (or the mail server), gets the revocation status proof
and sends it to you with the message.

In either case, the proof is obtained by somebody who is online.
You get the proof when you go online to get the mail message. You
can digest the proof in the "luxury" of your plane seat!

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: Bob Jueneman [mailto:[e-mail]] 
> Sent: Tuesday, September 14, 1999 8:29 AM
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail] 
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail] 
> Subject: Re: Huge CRLs
> 
> 
> On the other end of the time spectrum, try using OCSP, or any 
> other protocol other than CRLs, in disconnected mode while 
> you are on an airplane reading your signed e-mail.
> 
> Bob
> 
> >>> Robert Moskowitz <[e-mail]> 09/13/99 04:44AM >>>
> At 10:29 AM 9/10/1999 -0400, [e-mail] wrote:
> 
> >CRLs in any form are a fundamentally inadequate approach to 
> solving practical 
> >problems and in most cases cannot meet business requirements 
> for even small 
> >scale infrastructures.  CRLs were a good idea when the 
> terribly impractical 
> >people who developed them were working on paper and not such 
> a great idea 
> >when you have to turn paper into production systems.   CA 
> revocations 
> >experiments done on practical deployments (real world 
> machines, apps, and 
> >users) of even small PKIs will demonstrate that complying 
> with your own 
> >policy won't happen in the real world if you base your 
> revocation hopes on 
> >CRLS.
> >Why are you messing with them?
> >
> Try addressing REALTIME validation.  OCSP caching MIGHT work, 
> but an IPsec
> device has millisecs to validate; no time for network latency 
> to retrieve info.
> 
> Robert Moskowitz
> ICSA
> Security Interest EMail: [e-mail] 
> 


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id QAA11636 for <[e-mail]>; Tue, 14 Sep 1999 16:25:28 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 14 Sep 1999 17:28:01 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Tue, 14 Sep 1999 17:27:53 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Huge CRLs
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 QAA11637

Yes, it is about policy, but I think it is the relying party's policy, and probably 
not the CA's policy.  

The CA's policy might or might not satisfy the RP's requirements, in part because
the RP might literally change his mind based on the value of the transaction
in question.

I THINK I almost completely disagree with your last paragraph, although I'm 
willing to listen and be convinced. But I'm not sure that there IS a trust
model that is negotiated between the CA and the relying party. Although the RP
may decide to trust or not trust the CA, that is his business.  I certainly don't
expect to "negotiate" with VeriSign, Thawte, GTE, Globalsign, etc, etc., 
every time I get a signed e-mail ontaining one of their certificates.  I 
MIGHT be influenced by their CP, but not necessarily.

Bob


>>> "todd@gmtsw" <[e-mail]> 09/14/99 03:35PM >>>
Bob - can I play devil's advocate for a minute?

Isn't the issue of CRL-Use specific to the structure and form of the CPS
<--> CP<--> RPA relationships really? With this in mind, I have to ask the
question "isn't this totally about policy and its operation?"...

What I think is really going on here is that the structure and facility of
CRL use is specific to the operating model and nothing else, unless your
going to implement the control policy in the mechanical form of the protocol
itself (insert laughter here!).

Whether the aged CRL data is too old to be of use to you in your specific
application, is directly defined in the trust model specified in the CPS
<--> RPA agreements and nowhere else. The CP then wraps an operations policy
context around the bigger view to complete the picture.

Todd


----- Original Message -----
From: 
To: ; ; 
Sent: Tuesday, September 14, 1999 12:06 PM
Subject: Re: Huge CRLs



Received: from mail.routing.net ([62.104.62.38]) by mail.proper.com (8.9.3/8.9.3) with SMTP id QAA11387 for <[e-mail]>; Tue, 14 Sep 1999 16:15:25 -0700 (PDT)
Received: from keutel1 (195.90.194.67) by mail.routing.net with MERCUR-SMTP/POP3/IMAP4-Server (v3.10.13 AS-0098316) for <[e-mail]>; Wed, 15 Sep 1999  01:18:41 +0200
From: "Jochen Keutel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: deltaRevocationLists and LDAP
Date: Wed, 15 Sep 1999 01:18:56 +0200
Message-ID: <000201beff07$84adf700$83c25ac3@keutel1>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id QAA11388

Hello David, hello Peter,
  thanks for your responses. You are proposing different approaches - please let me comment and summarize them:

1. David Chadwick:
- Remark: X.509 (97) defines both matching rules - certificateListExactMatch and certificateListMatch. But - the certificateListMatch is not mentioned in the attribute definition of certificateRevocationList or deltaRevocation List - both have only the equality matching rule. So the X.500 servers I know of have implemented only the equality matching rule for CRLs (or nothing).
- Let's assume we are doing pure X.500 - and the X.500 server supports matchedValuesOnly and all matching rules mentioned above. The solution for my problem would be:

a) A client who wants to retrieve a specific Delta-CRL (with "thisUpdate=nnn") ASN.1-encodes a CertificateListExactAssertion with the correct issuer and "thisUpdate=nnn". It performs a Search (scope baseObject) with filter "deltaRevocationList=<CertificateListExactAssertion>" (using the equality matching rule), matchedValuesOnly=TRUE, requestedAttributes=deltaRevocationList.

Correct?

b) A client who wants to retrieve all Delta-CRLs since CRLnumber n ASN.1-encodes a CertificateListAssertion with the correct issuer and CRLnumber=n. It performs a Search (Scope Base) with filter "deltaRevoctionList matches <CertificateListAssertion> using certificateListMatch", matchedValuesOnly=TRUE, requestedAttributes=deltaRevocationList.

Correct?

- Let's assume the LDAP protocol and the LDAP servers have implemented matchedValuesOnly and the matching rules mentioned above. Then the scenario would be like X.500 - the only difference would be (following draft-pkix-ldap-v3-01.txt) that the Search filter in LDAP wouldn't be a ASN.1-encoded structure but a $-separated string.

Correct?

2. Peter Williams:

You are proposing to store each deltaRevocationList as a single-valued attribute of different entries. E.g. if we have "CN=CA,O=company,C=DE" as the CA entry then we could create
- "CN=deltaCRL 1,CN=CA,O=company,C=DE" holding as single-valued attribute the deltaCRL with number 1
- "CN=deltaCRL 2,CN=CA,O=company,C=DE" holding as single-valued attribute the deltaCRL with number 2
- ...
Each of these entries could have an additional indexed attribute "deltaCRLNumber" to make searches simple.

Directory administrators can easily manage that old entries (holding deltaCRLs with CRLnumber less than n) will be removed.

Correct? (Have I interpreted your proposal correctly?)

---

My opinion:
- Peter's proposal works well with any directory - LDAP V2, LDAP V3, X.500 (88), ...
- David's proposal doesn't work with any of currently existing directories.

But: Peter's solution is a good workaround for current directory deficits - but it's not standard. You have to extend the schema (at least with a new structure rule, name form and object class (or content rule)). And X.509 defines objects holding what we need.
  So I'd really like to see a standard solution.

Is it possible that you (LDAPEXT, PKIX) not only define "matchedValuesOnly" and the X.509(97) matching rules but that you (PKIX) define also the complete LDAP V3 protocol how clients should retrieve specific CRLs? I think that would make interoperability much easier.

Bye,
  Jochen.

P.S. My problem ist that I need a solution NOW. (I'm having a customer with about 70000 certificates circulating.) And I don't like the idea of implementing Peter's logic into the clients NOW and implementing other logics some months later.
Are there any other PKI vendors who could describe what they are doing today in their products regarding deltaCRLs?

---
Jochen Keutel
duerr com.soft, Senior Consultant
"Directory Services and Security Solutions"
Berlin, Germany



Received: from generalserver3.commerceone.com (mail.commerceone.com [204.71.220.19]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA10395 for <[e-mail]>; Tue, 14 Sep 1999 14:50:15 -0700 (PDT)
Received: by ip5-19.5.20.172.in-addr.arpa with Internet Mail Service (5.5.2448.0) id <SVA8VTG7>; Tue, 14 Sep 1999 14:49:45 -0700
Message-ID: <[e-mail]>
From: Zahid Ahmed <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Trust and client choices
Date: Tue, 14 Sep 1999 14:49:52 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="ISO-8859-1"

The attached book's review at amazaon.com claims that the
book contains the public keys of many CA's root certificate.

I think this is nice; but, where is the web sites and/or
publicly accessible LDAP server that is publishing all
(or most of the generally used) CA's public certificates
such that servers can register trusted CAs. E.g., are
the CA service providers (e.g., Verisign, Entrust,
GE, Wells Fargo, other european CAs,) publishing their
CA pubic root certificates at their web sites?

If not, why not?


thanks,
Zahid


> Zahid Ahmed wrote:
> > 
> > to trust CAs, the server needs to be aware of the
> > CA's public root certificate.
> > 
> > do you know where such root certificate are published?
> > e.g., for verisign, entrust, thwarte, etc.
> > 
> > is there a global CA root certificate directory/web server?
> 
> "The Global Internet Trust Register", pub. MIT press?
> 
> Cheers,
> 
> Ben.
> 
> --


Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA10371 for <[e-mail]>; Tue, 14 Sep 1999 14:49:53 -0700 (PDT)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI2KSP00.PCF for <[e-mail]>; Tue, 14 Sep 1999 21:53:13 +0000 
Received: from nma.com ([209.21.28.68]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI2JV800.J03; Tue, 14 Sep 1999 21:33:08 +0000 
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 1999 14:53:16 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Laurie <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Trust and client choices, was Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ben Laurie wrote:

> I agree that the issue of trust is not necessarily well addressed by
> X.509. However, in the case where the client does trust the CA, then
> there is a point in the client checking the CRL.

Yes, but perhaps not from that CA. Issuance and revocation are quite
disjoint and there is information-value as well as trust-value in using
different channels for revocation (yes, even more than one for
revocation in different reliance modes).

> In the case where the
> client does not trust the CA, then it matters not whether the CRL is
> checked or not. If the client wants choice about which CA to trust, then
> the server can choose to provide that choice, by, for example, using
> different domain names for difference CAs. This may not be ideal, but it
> addresses real-world cases that people want addressed, and it is
> available now.
>
> That there are other needs that are not addressed is interesting, but
> does not mean we should reject the use of CRLs, X.509 or SSL.

Yes, this is also my opinion.  That is why we need to identify the
problems, not just because it is interesting but also so that we can either
solve them or provide work-arounds.

> Actually, my main interest in CRLs is for servers to check clients,
> anyway.

I imagine ;-) And SSL does offer the needed feature in this case, as
commented some emails ago.

Cheers,

Ed Gerck




Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA09984 for <[e-mail]>; Tue, 14 Sep 1999 14:40:12 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id OAA28915; Tue, 14 Sep 1999 14:41:31 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id OAA03966; Tue, 14 Sep 1999 14:40:28 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Robert Moskowitz'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Huge CRLs
Date: Tue, 14 Sep 1999 14:44:06 -0700
Message-ID: <003401befefa$4569bff0$[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]>

Hi Bob,
    Not sure if you have already heard us talk about this, but we
have been talking about the "Freshness Seal" concept for a pretty
long time now, where, along with your certificate, you can send
along the proof that your certificate has not been revoked. At that
stage, the certificate recipient can verify the status of your
certificate without ever needing to make a network connection.

Also, you can amortize the Freshness Seal over all the connections
you make over a certain amount of time. Works very well for
server kind of applications. Also reduces the load when a busy
server is trying to serve a number of clients.

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: Robert Moskowitz [mailto:[e-mail]]
> Sent: Monday, September 13, 1999 3:45 AM
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: Huge CRLs
> 
> 
> At 10:29 AM 9/10/1999 -0400, [e-mail] wrote:
> 
> >CRLs in any form are a fundamentally inadequate approach to 
> solving practical 
> >problems and in most cases cannot meet business requirements 
> for even small 
> >scale infrastructures.  CRLs were a good idea when the 
> terribly impractical 
> >people who developed them were working on paper and not such 
> a great idea 
> >when you have to turn paper into production systems.   CA 
> revocations 
> >experiments done on practical deployments (real world 
> machines, apps, and 
> >users) of even small PKIs will demonstrate that complying 
> with your own 
> >policy won't happen in the real world if you base your 
> revocation hopes on 
> >CRLS.
> >Why are you messing with them?
> >
> Try addressing REALTIME validation.  OCSP caching MIGHT work, 
> but an IPsec
> device has millisecs to validate; no time for network latency 
> to retrieve info.
> 
> Robert Moskowitz
> ICSA
> Security Interest EMail: [e-mail]
> 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA09932 for <[e-mail]>; Tue, 14 Sep 1999 14:37:05 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id OAA28910; Tue, 14 Sep 1999 14:39:14 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id OAA03904; Tue, 14 Sep 1999 14:38:11 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Huge CRLs
Date: Tue, 14 Sep 1999 14:41:49 -0700
Message-ID: <003301befef9$f41289c0$[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]>

Bob, there are actually 2 ways I would address that:

1. Your mail server could do the validation and only send you
messages that were validated (assuming you trust your mail server
*and* your mail server has the same cert validation rules as you
do).

2. You could use the "Freshness Seal" method, where the sender of
the mail (or the mail server), gets the revocation status proof
and sends it to you with the message.

In either case, the proof is obtained by somebody who is online.
You get the proof when you go online to get the mail message. You
can digest the proof in the "luxury" of your plane seat!

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: Bob Jueneman [mailto:[e-mail]]
> Sent: Tuesday, September 14, 1999 8:29 AM
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: Huge CRLs
> 
> 
> On the other end of the time spectrum, try using OCSP, or any 
> other protocol other than CRLs, in disconnected mode while 
> you are on an airplane reading your signed e-mail.
> 
> Bob
> 
> >>> Robert Moskowitz <[e-mail]> 09/13/99 04:44AM >>>
> At 10:29 AM 9/10/1999 -0400, [e-mail] wrote:
> 
> >CRLs in any form are a fundamentally inadequate approach to 
> solving practical 
> >problems and in most cases cannot meet business requirements 
> for even small 
> >scale infrastructures.  CRLs were a good idea when the 
> terribly impractical 
> >people who developed them were working on paper and not such 
> a great idea 
> >when you have to turn paper into production systems.   CA 
> revocations 
> >experiments done on practical deployments (real world 
> machines, apps, and 
> >users) of even small PKIs will demonstrate that complying 
> with your own 
> >policy won't happen in the real world if you base your 
> revocation hopes on 
> >CRLS.
> >Why are you messing with them?
> >
> Try addressing REALTIME validation.  OCSP caching MIGHT work, 
> but an IPsec
> device has millisecs to validate; no time for network latency 
> to retrieve info.
> 
> Robert Moskowitz
> ICSA
> Security Interest EMail: [e-mail]
> 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA09587 for <[e-mail]>; Tue, 14 Sep 1999 14:29:51 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id OAA28862; Tue, 14 Sep 1999 14:33:08 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id OAA03797; Tue, 14 Sep 1999 14:33:08 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Daniel Lanz'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Huge CRLs
Date: Tue, 14 Sep 1999 14:36:46 -0700
Message-ID: <003201befef9$3f546580$[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: <000001befec1$746657c0$[e-mail]>

Hi Daniel,
    Basically, with OCSP, the responder needs to have its key
available online to sign responses (you can mitigate this risk to
some extent by having a proxy between your responder and the rest
of the world, but it is still an issue). So you need to make your
responder available for people to talk to, but if anybody ever
manages to break into your responder and get access to your private
key, your whole OCSP response system is open to compromise.

With CRTs, you can acctually have the Tree Issuer be separate from
the CRT responders. The Tree Issuer has access to your CRT private
key and can create new CRTs, which it then distributes to one or
more CRT responders (which don't have the highly trusted private
key), which actually provide the CRT responses.

Hope this clarifies the issue,
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: Daniel Lanz [mailto:[e-mail]]
> Sent: Tuesday, September 14, 1999 7:57 AM
> To: 'Ambarish Malpani'
> Cc: [e-mail]
> Subject: RE: Huge CRLs
> 
> 
> 
> 
> >CRTs are a proprietary method to implement OCSP in a more scalable
> >and secure way.
> 
> Ambarish,
> 
> How do CRTs make OCSP more secure?
> 
> Regards,
> 
> Dan Lanz
> 
> 
> 


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA09551 for <[e-mail]>; Tue, 14 Sep 1999 14:28:18 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id RAA08717; Tue, 14 Sep 1999 17:31:32 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id RAA08713; Tue, 14 Sep 1999 17:31:32 -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 RAA00041; Tue, 14 Sep 1999 17:31:15 -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 RAA06183; Tue, 14 Sep 1999 17:29:11 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 14 Sep 1999 17:29:11 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Huge CRLs
To: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: RPK0J1ljEHkYuo/7zGq+ow==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Phillip M Hallam-Baker" <[e-mail]>
> 
> > Not all the world is the financial services sector.  Criticisms of CRL use
> > models based primarily on difficulties encountered in employing them in
> > that environment, or based on poor implementations, or based on poor
> > management parameter choices, etc.  do not necessarily mean that CRLs are
> > unworkable.
> 
> Steve,
> 
> 	I agree with your sentiments but I would prefer to see you saying
> something of the form 'this argument is irrelevant' or 'this argument
> is unproductive'.
> 
> 	We have already argued the case for supporting both online
> and blacklist style revocation. There are applications in which both
> approaches have specific advantages which may well prove critical.
> 
> 	I don't see how the current argument is going to lead to any
> substantive change to the WG drafts or RFCs. We have already advanced
> both sets of drafts to proposed standard status. 
> 
> 	Tempting though it may be to answer the numerous minor and minor
> fallacies in the argument presented I suggest that we just refer the
> combatants to the discussions we had on this topic over a year ago.



Phill,

Referring to last year's discussion is fine, but repeating last year's
fallacies is not helpful when the topic resurfaces .

There is no dichotomy between "online" and "blacklist" style revocation.
Online is on one axis, the opposite end of which is store-and-forward.
"List" is on an independent axis, namely the integers 1..N.

An OCSP response is online, and it covers a list of exactly one certificate.

A CRL could be generated and retrieved online, or could be generated
and stored for later retreival.  A CRL can cover any number of
certificates, from N down to one. The requirement space covered
is thus:
                 OCSP  CRL
                 ----  ----
Online, 1 cert    y     y
Online, N certs         y
Stored, 1 cert          y
Stored, N certs         y


---------- [from a later message] ----------

> The significance of OCSP is this. It is not sensible, practical or
> ecconomic to build a revocation infrastructure which addresses
> the planetary scale PKI at present while the size of the largest
> PKIs is in the small millions. OCSP permits a decoupling of the
> revocation/validation problem from the client implementation.

How is OCSP unique in this respect?  If you posit the existence of
a revocation server findable by and trusted by the client, that server
could return a CRL, or it could return an OCSP response.  The
advantage of returning a list is that the client might not have to
query as frequently.


--------- [Lynn Wheeler adds] ----------

> Also, CRL operation tends to be a scaleup issue proportional to the
> size of the population ...

Again, a matter of implementation.  The population covered by a CRL is
a tunable parameter which can be set anywhere between 1 and the entire
population.



Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with SMTP id OAA09098 for <[e-mail]>; Tue, 14 Sep 1999 14:16:04 -0700 (PDT)
Received: from PC1 by gmtsw.com (SMI-8.6/SMI-SVR4) id OAA09776; Tue, 14 Sep 1999 14:19:55 -0700
Message-ID: <0efc01befef9$16e300c0$[e-mail]>
From: "todd@gmtsw" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Huge CRLs
Date: Tue, 14 Sep 1999 14:35:32 -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.2918.2701
Disposition-Notification-To: todd@gmtsw <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Bob - can I play devil's advocate for a minute?

Isn't the issue of CRL-Use specific to the structure and form of the CPS
<--> CP<--> RPA relationships really? With this in mind, I have to ask the
question "isn't this totally about policy and its operation?"...

What I think is really going on here is that the structure and facility of
CRL use is specific to the operating model and nothing else, unless your
going to implement the control policy in the mechanical form of the protocol
itself (insert laughter here!).

Whether the aged CRL data is too old to be of use to you in your specific
application, is directly defined in the trust model specified in the CPS
<--> RPA agreements and nowhere else. The CP then wraps an operations policy
context around the bigger view to complete the picture.

Todd


----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Tuesday, September 14, 1999 12:06 PM
Subject: Re: Huge CRLs




Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA09076 for <[e-mail]>; Tue, 14 Sep 1999 14:15:24 -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 VAA07518; Tue, 14 Sep 1999 21:18:19 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 WAA29471; Tue, 14 Sep 1999 22:18:44 +0100
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 1999 22:18:19 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.6 [en-gb] (WinNT; I)
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Trust and client choices, was Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I agree that the issue of trust is not necessarily well addressed by
X.509. However, in the case where the client does trust the CA, then
there is a point in the client checking the CRL. In the case where the
client does not trust the CA, then it matters not whether the CRL is
checked or not. If the client wants choice about which CA to trust, then
the server can choose to provide that choice, by, for example, using
different domain names for difference CAs. This may not be ideal, but it
addresses real-world cases that people want addressed, and it is
available now.

That there are other needs that are not addressed is interesting, but
does not mean we should reject the use of CRLs, X.509 or SSL.

Actually, my main interest in CRLs is for servers to check clients,
anyway.

Cheers,

Ben.

Ed Gerck wrote:
> 
> Ben Laurie wrote:
> 
> > Ed Gerck wrote:
> > > The first interesting question raised here is that of trust -- I cannot assume
> > > or favor the notion that there is only one CA that the client MUST trust,
> > > which  CA is by the way the ONE that the *other party* (the server) has
> > > chosen ;-)
> >
> > That is irrelevant. The client can choose to trust or not trust the CA.
> > Whether they do is orthogonal to the question of CRL checking.
> 
> In some reliance models, a CA can be trusted as much but no more than the
> CRL checking service they provide.
> 
> > > The conclusion IMO is that which I commented first, but edited to stress the
> > > client context. That the major X.509 security application today, SSL, does not
> > > allow the client to check revocation lists that the client trusts -- so they are near
> > > to useless. Also, the client is  not able to check server certificates (and certificates
> > > in the CA chains) against client-defined revocation lists (VAs, for example).
> >
> > That is not what you said. You said that there was no way for the client
> > to check CRLs, not that there was no way to check CRLs that the client
> > trusts
> 
> I guess you understood well what I said in the first time.  Now, you just
> need to understand what is the worth of checking distrusted CRLs.
> 
> As I wrote some two years ago (URL certover.pdf) and still valid even
> if the CRLDistributionPoint is specified in the server certificate and is used at
> the client -- in SSL, the server is neither informed by the client what CAs to best
> aim for in a ranking list  (CAs that are directly trusted by the client for
> signature and CRLs, untrusted CAs directly trusted by a CA that
> the client trusts, etc.), nor offers the client a list of CAs for the client to
> choose which CA is trusted for what.
> 
> So, if we agree that checking distrusted CRLs is as worthless as
> checking distrusted certificates, then I guess we achieved closure.
> And, clearly, a confirmed conversation with a thief is not secure just
> because it is confirmed by the thief himself.
> 
> > Furthermore, if the client trusts the CA, then they should trust
> > the CRL.
> 
> No, these two issues are like apples and speedboats.  Are you familiar
> with VAs?
> 
> > If they do not, then it hardly matters whether they check it or
> > not, since they don't trust the certificate anyway.
> 
> The trust in a certificate signed by a CA is a decreasing function of time
> as I have exemplified elsewhere, for a variety of reasons, more than two
> years ago. Thus, a certificate may be trusted with some reliance bar
> for a certain time limit after issuance even without any regard to CRLs,
> but not afterwards (on an average basis).  So, it DOES matter whether
> the CA is trusted for certificates *and* CRLs or only trusted for
> certificates -- as a function of how "stale" the certificate is.
> 
> > > The alternative for the client is to proceed manually, outside of SSL. But, we
> > > know, users do not have the training to use a complicated secure procedure
> > > if a simpler and unsafe procedure is just a click away.
> > >
> > > For the server, however, SSL affords a better procedure since the client knows
> > > which CAs the server trusts for what, as I commented above
> >
> > Again, this is a sidetrack: the client can also choose which CAs it
> > trusts. The fact that it does not communicate them to the server is a
> > different matter.
> 
> Again, this discussion indeed seems like others we had.  But, "to be able to
> choose" must mean to *have* a choice.  And, in current SSLv3, the client
> has no choice for server CA and cannot communciate to the server which
> CAs the client is willing to trust for what order of validation chains -- instead,
> the client must accept the only option that the server provides, and must do
> so also for the CRLs of  that certificate even when the CRLDistributionPoint
> is specified by that server certificate and used at the client.  ;-) Sorry, but the
> client's choice here is to have no choice, twice.
> 
> Cheers,
> 
> Ed Gerck
> ______________________________________________________________________
> Dr.rer.nat. E. Gerck                                    [e-mail]

--
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 gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with SMTP id NAA08678 for <[e-mail]>; Tue, 14 Sep 1999 13:53:51 -0700 (PDT)
Received: from PC1 by gmtsw.com (SMI-8.6/SMI-SVR4) id NAA09551; Tue, 14 Sep 1999 13:57:42 -0700
Message-ID: <0ee101befef6$00d6f550$[e-mail]>
From: "todd@gmtsw" <[e-mail]>
To: <[e-mail]>, "Farrukh Ahmad" <[e-mail]>
References: <[e-mail]>
Subject: Re: CPs and CPS
Date: Tue, 14 Sep 1999 14:13:20 -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.2918.2701
Disposition-Notification-To: todd@gmtsw <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Farrukh,
perhaps it is an issue of the strata of focus. It seems to me that the
problem here is that the PKIX team is a mechanical technologies resource
group and a CPS and the Policies statement are specific to the commercial or
trust envelope of the policy being implemented. They are about policy and
the facility of implementing it which is not something that PKIX really has
much presence in.

With this in mind, perhaps a better place to look for this information would
be from an Auditor or someone that makes their living on "proving the trust
models" of the systems they work on. Some good places to look would be the
Bar Associations Information Security Committee, or try the CPS, CP, and RPA
at Verisign or any of the other commercial trust providers.

Traditionally CPS (certificate practices statements) define the facility and
the process of issuing and managing Certs or other digital trust
instruments, like timestamps for instance. The CP (the Certificate Policies)
then defines the physical operation process policies. Finally, the RPA
(Relying Party Agreement) spells out from the client side what the client's
responsibilities and process is. Somewhere between the RPA and the CPS the
actual definition of the PROVIDER <--> Relying Party requirements are.

If PKIX wants to own this stuff formally then the Steve and Warwick might
want to setup a hit-squad to take the Auditor Guidelines that were submitted
to the ABA by Pat Cain, et al. and spin that into a PKIX document. I would
also suggest that the PKIX team be willing to work formally with the ABA on
its efforts in creating just these documents, to insure that the focus of
the documents remains anchored in real technology so it is doable.

Todd



----- Original Message -----
From: Farrukh Ahmad <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, September 14, 1999 8:30 AM
Subject: CPs and CPS


> Hi, I have searched the mail archives and cannot find a clear definition
> differentiating Certificate Policies and Certification Practice
Statements.
> RFC2527 talks of some of the differences but does not provide details of
> what should be contractually binding for a relying party. Some of the
> categories (e.g. Certificate Application etc.) are not too relevant to
> relying parties either - so why is there not a separate framework for CPs?
> Continuing from this who is the audience for a CPS if CPs are present -
> won't a relying party be content with reading the policy (to which he make
> be contractually bound) and not too interested in the practices the CA
> adopts to implement them?
>
> Some clarification on this would be a great help.
>
> faz
>



Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA08398 for <[e-mail]>; Tue, 14 Sep 1999 13:42:37 -0700 (PDT)
Received: from dfw-mmp2.email.verio.net ([129.250.38.62]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI2HOK00.8C9 for <[e-mail]>; Tue, 14 Sep 1999 20:45:56 +0000 
Received: from nma.com ([209.21.28.85]) by dfw-mmp2.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI2HQH00.SGP; Tue, 14 Sep 1999 20:47:05 +0000 
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 1999 13:45:59 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail], [e-mail]
Subject: Trust and client choices, was Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ben Laurie wrote:

> Ed Gerck wrote:
> > The first interesting question raised here is that of trust -- I cannot assume
> > or favor the notion that there is only one CA that the client MUST trust,
> > which  CA is by the way the ONE that the *other party* (the server) has
> > chosen ;-)
>
> That is irrelevant. The client can choose to trust or not trust the CA.
> Whether they do is orthogonal to the question of CRL checking.

In some reliance models, a CA can be trusted as much but no more than the
CRL checking service they provide.

> > The conclusion IMO is that which I commented first, but edited to stress the
> > client context. That the major X.509 security application today, SSL, does not
> > allow the client to check revocation lists that the client trusts -- so they are near
> > to useless. Also, the client is  not able to check server certificates (and certificates
> > in the CA chains) against client-defined revocation lists (VAs, for example).
>
> That is not what you said. You said that there was no way for the client
> to check CRLs, not that there was no way to check CRLs that the client
> trusts

I guess you understood well what I said in the first time.  Now, you just
need to understand what is the worth of checking distrusted CRLs.

As I wrote some two years ago (URL certover.pdf) and still valid even
if the CRLDistributionPoint is specified in the server certificate and is used at
the client -- in SSL, the server is neither informed by the client what CAs to best
aim for in a ranking list  (CAs that are directly trusted by the client for
signature and CRLs, untrusted CAs directly trusted by a CA that
the client trusts, etc.), nor offers the client a list of CAs for the client to
choose which CA is trusted for what.

So, if we agree that checking distrusted CRLs is as worthless as
checking distrusted certificates, then I guess we achieved closure.
And, clearly, a confirmed conversation with a thief is not secure just
because it is confirmed by the thief himself.

> Furthermore, if the client trusts the CA, then they should trust
> the CRL.

No, these two issues are like apples and speedboats.  Are you familiar
with VAs?

> If they do not, then it hardly matters whether they check it or
> not, since they don't trust the certificate anyway.

The trust in a certificate signed by a CA is a decreasing function of time
as I have exemplified elsewhere, for a variety of reasons, more than two
years ago. Thus, a certificate may be trusted with some reliance bar
for a certain time limit after issuance even without any regard to CRLs,
but not afterwards (on an average basis).  So, it DOES matter whether
the CA is trusted for certificates *and* CRLs or only trusted for
certificates -- as a function of how "stale" the certificate is.

> > The alternative for the client is to proceed manually, outside of SSL. But, we
> > know, users do not have the training to use a complicated secure procedure
> > if a simpler and unsafe procedure is just a click away.
> >
> > For the server, however, SSL affords a better procedure since the client knows
> > which CAs the server trusts for what, as I commented above
>
> Again, this is a sidetrack: the client can also choose which CAs it
> trusts. The fact that it does not communicate them to the server is a
> different matter.

Again, this discussion indeed seems like others we had.  But, "to be able to
choose" must mean to *have* a choice.  And, in current SSLv3, the client
has no choice for server CA and cannot communciate to the server which
CAs the client is willing to trust for what order of validation chains -- instead,
the client must accept the only option that the server provides, and must do
so also for the CRLs of  that certificate even when the CRLDistributionPoint
is specified by that server certificate and used at the client.  ;-) Sorry, but the
client's choice here is to have no choice, twice.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                    [e-mail]




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id MAA07251 for <[e-mail]>; Tue, 14 Sep 1999 12:05:07 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 14 Sep 1999 13:06:31 -0600
Mime-version: 1.0
Date: Tue, 14 Sep 1999 13:06:00 -0600
X-Mailer: Groupwise 5.5.2.1
Subject: Re: Huge CRLs
To: [e-mail], [e-mail], [e-mail]
Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____JCNQSUMWZDKRIFOYICBS____"

--____JCNQSUMWZDKRIFOYICBS____
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

Aram,

I don't know how your mail package works, but what GroupWise does is allow =
me to do a "Hit the Road", which updates my laptop with copies of mail =
that is normally  stored on the server. I suppose either IMAP or POP3 =
could do the same thing.

In any case, I have a bunch of unread messages I want to work through on =
the plane, and I want to confirm their signatures.

It's true that I might not know that a certificate was revoked just after =
I got on the plane, but if I get a current CRL status at the time I hit =
the road, or even when I got the message, that is probably fresh enough =
for most of my purposes.

Ideally, I would like to be able to specify a "freshness" criteria that =
CRLs would have to meet, or at least have the date/time of the last CRL =
update provided.

But except in the case of nonrepudiation (Oh no, Captain Bill, not the =
black hole again! :-), I probably don't care all that much. And I'm =
certainly not going to delay taking action for another two weeks, just to =
see if someone's certificate shows up as revoked.

Remember, just because someone's certificate is revoked, especially for =
relatively innocuous reasons such as a change or name or address, that =
does NOT necessarily invalidate the signature, it just makes it somewhat =
harder to prove that reliance was reasonable.  And in most cases the =
signature is NOT the only type of evidence I have -- I could probably =
recognize a message from Ed Gerck, or Steve Kent, or lots of other people, =
whether they signed it or not.

If, and only if, there is a message of such overwhelming importance that I =
just absolutely have to know that it was valid, I would wait until I could =
reestablish a connection, and then ask for the latest CRL, delta CRL, or =
OCSP.

Presumably the CA doesn't queue up revoked certificates until the time of =
next update.  Next update time is provided in order to signal me that I =
have missed a CRL, but normally I would expect to get an up to date status =
every time I ask for a new CRL.

That's one of the reasons why I can't get very excited about OCSP -- it =
makes the server sign every response, whether or not there was a change =
from the previous one.

Bob


>>> "Aram Perez" <[e-mail]> 09/14/99 10:16AM >>>
Bob,

In either case you are stuck with the same problem: you don't know whether
the signer's certificate is valid until you get the next "certificate
status" update, whether you get the status via a CRL or OCSP.

BTW, if you weren't on-line, how did you get the signed e-mail? ;-)

Regards,
Aram Perez

> On the other end of the time spectrum, try using OCSP, or any other
> protocol other than CRLs, in disconnected mode while you are on an =
airplane
> reading your signed e-mail.
>
> Bob
>
>>>> Robert Moskowitz <[e-mail]> 09/13/99 04:44AM >>>
> At 10:29 AM 9/10/1999 -0400, [e-mail] wrote:
>
>>CRLs in any form are a fundamentally inadequate approach to solving =
practical
>>problems and in most cases cannot meet business requirements for even =
small
>>scale infrastructures.  CRLs were a good idea when the terribly =
impractical
>>people who developed them were working on paper and not such a great =
idea
>>when you have to turn paper into production systems.   CA revocations
>>experiments done on practical deployments (real world machines, apps, =
and
>>users) of even small PKIs will demonstrate that complying with your own
>>policy won't happen in the real world if you base your revocation hopes =
on
>>CRLS.
>>Why are you messing with them?
>>
> Try addressing REALTIME validation.  OCSP caching MIGHT work, but an =
IPsec
> device has millisecs to validate; no time for network latency to =
retrieve
info.
>
> Robert Moskowitz
> ICSA
> Security Interest EMail: [e-mail]=20
>


--____JCNQSUMWZDKRIFOYICBS____
Content-type: application/x-pkcs7-signature; name="smime.p7s"
Content-transfer-encoding: base64
Content-disposition: attachment; filename="smime.p7s"
CONTENT-DESCRIPTION: S/MIME Cryptographic Signature

MIILqQYJKoZIhvcNAQcCoIILmjCCC5YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCekw
ggI8MIIBpQIQMlAzz1DRVvNcga1lXE/IJTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEX
MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkg
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjAwMTA3MjM1OTU5WjBf
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg
UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBW
hBiHmgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJ
Y1zF4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAS0RmYGhk5Jgb
87By5pWJfN17s5XAHS7Y2BnQLTQ9xlCaEIaMqj87qAT8N1KVw9nJ283yhgbEsRvwgogwQo4XUBxk
erg+mUl0l/ysAkP7lgxWBCUMfHyHnSSn2PAyKbWk312iTMUWMqhC9kWmtja54L9lNpPC0tdr3N5Z
1qI1+EUwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgw
NTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu
IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg
SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFB
cHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegP
h7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQD
AgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG
9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEX
fWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA
/Rgg5V+CprGoksVYasGNAzzrw80FopCubjCCBHMwggPcoAMCAQICEF6mQzFngv6Wl+eGgC1QPt4w
DQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkv
UlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz
cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNOTkw
NTExMDAwMDAwWhcNMDAwNTEwMjM1OTU5WjCCARcxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQ
ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jv
c29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1JvYmVydCBKdWVuZW1hbjEjMCEGCSqGSIb3DQEJ
ARYUYmp1ZW5lbWFuQG5vdmVsbC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANW8HQNT
oKMy+VNzL0IEq3SoWmSY2Qlsut0sMwe3fwzJR9DglDQApUf13tJZdU48ZNzRC16QkZs8nFM2gCyF
AAv4QhfAkYymhVqjrBiuNTs7K3O30W0ok6Nv6v/aokHIU6tAzLLuBMuayuN7sS58FDfcXwBvabN/
ePIamR40aQN5AgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsG
AQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBi
eSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4Aw
MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq
hkiG9w0BAQQFAAOBgQBhbRmCI9CSHD2vYJOyQ9JsQ8NKDmTAKUY4qNwGXfsQcE+Wtr/vvhllfHsc
Q/JY4GM0dvR2rYEq/I6nMk5Unlju527qbQYsVoA4FqRdcl1tGQRwBSsSPMS7qTmbnyujc1PA5dEj
QRu9VVNjpDiDc3nAcWFeb7SpjVmqzav5opJvizGCAYgwggGEAgEBMIHhMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQo
Yyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt
UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBepkMxZ4L+lpfnhoAtUD7eMAkGBSsOAwIaBQAwDQYJKoZI
hvcNAQEBBQAEgYBkbKVa0VBeWo4vBmpwsh0LzYkbCXZivrs70bHR2XYAQBpmMbZnL9fmRmv2cZug
cfGe+zdZVRViAlxO/kpwT34LVjiyO1dlihIw9C1sJ1st2MeLExJGeK0xeuXzykgTaikWoOMHizuv
pzIgYxC1NTMArdNRQnNfwG6FCw7qIyzkgQ==

--____JCNQSUMWZDKRIFOYICBS____--


Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA06134 for <[e-mail]>; Tue, 14 Sep 1999 10:34:24 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id KAA14242 for <[e-mail]>; Tue, 14 Sep 1999 10:37:39 -0700 (PDT)
Received: from scv1.apple.com (scv1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 14 Sep 1999 09:16:24 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id JAA04563; Tue, 14 Sep 1999 09:16:23 -0700 (PDT)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 14 Sep 1999 09:16:21 -0700
Subject: Re: Huge CRLs
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

Bob,

In either case you are stuck with the same problem: you don't know whether
the signer's certificate is valid until you get the next "certificate
status" update, whether you get the status via a CRL or OCSP.

BTW, if you weren't on-line, how did you get the signed e-mail? ;-)

Regards,
Aram Perez

> On the other end of the time spectrum, try using OCSP, or any other
> protocol other than CRLs, in disconnected mode while you are on an airplane
> reading your signed e-mail.
>
> Bob
>
>>>> Robert Moskowitz <[e-mail]> 09/13/99 04:44AM >>>
> At 10:29 AM 9/10/1999 -0400, [e-mail] wrote:
>
>>CRLs in any form are a fundamentally inadequate approach to solving practical
>>problems and in most cases cannot meet business requirements for even small
>>scale infrastructures.  CRLs were a good idea when the terribly impractical
>>people who developed them were working on paper and not such a great idea
>>when you have to turn paper into production systems.   CA revocations
>>experiments done on practical deployments (real world machines, apps, and
>>users) of even small PKIs will demonstrate that complying with your own
>>policy won't happen in the real world if you base your revocation hopes on
>>CRLS.
>>Why are you messing with them?
>>
> Try addressing REALTIME validation.  OCSP caching MIGHT work, but an IPsec
> device has millisecs to validate; no time for network latency to retrieve
info.
>
> Robert Moskowitz
> ICSA
> Security Interest EMail: [e-mail]
>



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA05796 for <[e-mail]>; Tue, 14 Sep 1999 10:18:03 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA07336 for <[e-mail]>; Tue, 14 Sep 1999 13:21:20 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA07320 for <[e-mail]>; Tue, 14 Sep 1999 13:21:17 -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 NAA27342 for <[e-mail]>; Tue, 14 Sep 1999 13:21:00 -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, 14 Sep 1999 13:20:53 -0400
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <Q2Z22LM0>; Tue, 14 Sep 1999 13:20:58 -0400
Message-Id: <[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: Farrukh Ahmad <[e-mail]>, "'Sean Turner'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: CPs and CPS
Date: Tue, 14 Sep 1999 13:20:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BEFED5.81E3696A"

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_01BEFED5.81E3696A
Content-Type: text/plain

Farrukh and Sean:

I agree with what Sean wrote.

X.509 defines a Certificate Policy as:

"A named set of rules that indicates the applicability of a certificate to a
particular community and/or class of application with common security
requirements."

The American Bar Association (ABA) Digital Signature Guidelines defines a
CPS as:

"A statement of the practices which a certification authority applies in
issuing certificates."

I expect that within the DoD, we will be using the CP as a statement of the
intended certificate using community and certificate applicability, as well
as a statement of the security requirements associated with certificate
issuance and management.

The CPS documents associated with a CP states the methods CAs and
Registration Authorities will use to meet the requirements of one or more
CPs.  So I think CP documents will be associated with procurement requests
from the government, and CPS documents will be used to judge a CA's
compliance with policy.  I expect compliance audits will be performed
against CPS documents, rather than against CP documents.

There are many other models for the relationship between a CP and a CPS, but
this is the one on which the current draft DoD Certificate Policy was based.

Dave Fillingham
> ----------
> From: 	Sean Turner[SMTP:[e-mail]]
> Sent: 	Tuesday, September 14, 1999 12:34 PM
> To: 	Farrukh Ahmad
> Cc: 	'[e-mail]'
> Subject: 	Re: CPs and CPS
> 
> Farrukh,
> 
> In the PKIX Roadmap ID we define the as:
> 
> - Certificate Policy (CP) - a named set of rules that indicates the
> applicability of a certificate to a particular community and/or class of
> application with common security requirements. For example, a particular
> certificate policy might indicate applicability of a type of certificate
> to the
> authentication of electronic data interchange transactions for the trading
> of
> goods within a given price range.
> 
> - Certification Practice Statement (CPS) - A statement of the practices
> which a
> certification authority employs in issuing certificates.
> 
> Granted I think we lifted these from RFC2527.
> 
> spt
> 
> Farrukh Ahmad wrote:
> 
> > Hi, I have searched the mail archives and cannot find a clear definition
> > differentiating Certificate Policies and Certification Practice
> Statements.
> > RFC2527 talks of some of the differences but does not provide details of
> > what should be contractually binding for a relying party. Some of the
> > categories (e.g. Certificate Application etc.) are not too relevant to
> > relying parties either - so why is there not a separate framework for
> CPs?
> > Continuing from this who is the audience for a CPS if CPs are present -
> > won't a relying party be content with reading the policy (to which he
> make
> > be contractually bound) and not too interested in the practices the CA
> > adopts to implement them?
> >
> > Some clarification on this would be a great help.
> >
> > faz
> 

------_=_NextPart_001_01BEFED5.81E3696A
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: CPs and CPS</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Farrukh and =
Sean:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I agree with what =
Sean wrote.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">X.509 defines a =
Certificate Policy as:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&quot;A named set of =
rules that indicates the applicability of a certificate to a particular =
community and/or class of application with common security =
requirements.&quot;</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The American Bar =
Association (ABA) Digital Signature Guidelines defines a CPS as:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&quot;A statement of =
the practices which a certification authority applies in issuing =
certificates.&quot;</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I expect that within =
the DoD, we will be using the CP as a statement of the intended =
certificate using community and certificate applicability, as well as a =
statement of the security requirements associated with certificate =
issuance and management.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The CPS documents =
associated with a CP states the methods CAs and Registration =
Authorities will use to meet the requirements of one or more CPs.&nbsp; =
So I think CP documents will be associated with procurement requests =
from the government, and CPS documents will be used to judge a CA's =
compliance with policy.&nbsp; I expect compliance audits will be =
performed against CPS documents, rather than against CP =
documents.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">There are many other =
models for the relationship between a CP and a CPS, but this is the one =
on which the current draft DoD Certificate Policy was based.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave =
Fillingham</FONT>
<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">Sean =
Turner[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">Tuesday, September 14, 1999 12:34 =
PM</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">Farrukh =
Ahmad</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: CPs and CPS</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Farrukh,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the PKIX Roadmap ID we define the =
as:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- Certificate Policy (CP) - a named =
set of rules that indicates the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">applicability of a certificate to a =
particular community and/or class of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">application with common security =
requirements. For example, a particular</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certificate policy might indicate =
applicability of a type of certificate to the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">authentication of electronic data =
interchange transactions for the trading of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">goods within a given price =
range.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- Certification Practice Statement =
(CPS) - A statement of the practices which a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certification authority employs in =
issuing certificates.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Granted I think we lifted these from =
RFC2527.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">spt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Farrukh Ahmad wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Hi, I have searched the mail =
archives and cannot find a clear definition</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; differentiating Certificate =
Policies and Certification Practice Statements.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; RFC2527 talks of some of the =
differences but does not provide details of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; what should be contractually =
binding for a relying party. Some of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; categories (e.g. Certificate =
Application etc.) are not too relevant to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; relying parties either - so why =
is there not a separate framework for CPs?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Continuing from this who is the =
audience for a CPS if CPs are present -</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; won't a relying party be content =
with reading the policy (to which he make</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; be contractually bound) and not =
too interested in the practices the CA</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; adopts to implement them?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Some clarification on this would =
be a great help.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; faz</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BEFED5.81E3696A--


Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA05123 for <[e-mail]>; Tue, 14 Sep 1999 09:35:01 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id MAA11115; Tue, 14 Sep 1999 12:42:49 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 1999 12:34:02 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Farrukh Ahmad <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: CPs and CPS
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Farrukh,

In the PKIX Roadmap ID we define the as:

- Certificate Policy (CP) - a named set of rules that indicates the
applicability of a certificate to a particular community and/or class of
application with common security requirements. For example, a particular
certificate policy might indicate applicability of a type of certificate to the
authentication of electronic data interchange transactions for the trading of
goods within a given price range.

- Certification Practice Statement (CPS) - A statement of the practices which a
certification authority employs in issuing certificates.

Granted I think we lifted these from RFC2527.

spt

Farrukh Ahmad wrote:

> Hi, I have searched the mail archives and cannot find a clear definition
> differentiating Certificate Policies and Certification Practice Statements.
> RFC2527 talks of some of the differences but does not provide details of
> what should be contractually binding for a relying party. Some of the
> categories (e.g. Certificate Application etc.) are not too relevant to
> relying parties either - so why is there not a separate framework for CPs?
> Continuing from this who is the audience for a CPS if CPs are present -
> won't a relying party be content with reading the policy (to which he make
> be contractually bound) and not too interested in the practices the CA
> adopts to implement them?
>
> Some clarification on this would be a great help.
>
> faz



Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA04344 for <[e-mail]>; Tue, 14 Sep 1999 08:54:30 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail-ewr-3.pilot.net with ESMTP id LAA07251 for <[e-mail]>; Tue, 14 Sep 1999 11:57:11 -0400 (EDT)
Received: from lncora06.firstdata.com ([206.201.60.104]) by mailgw.firstdata.com with SMTP id LAA07747 for <[e-mail]>; Tue, 14 Sep 1999 11:57:10 -0400 (EDT)
Received: from 10.2.52.30 by lncora06.firstdata.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v3.6); Tue, 14 Sep 99 11:54:54 -0400
X-Server-Uuid: 28680605-564e-11d3-99f5-0004ac9d9957
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852567EC.0057766B ; Tue, 14 Sep 1999 11:55:19 -0400
X-Lotus-FromDomain: FDC
To: "Bob Jueneman" <[e-mail]>
cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 1999 08:54:44 -0700
Subject: Re: Huge CRLs
MIME-Version: 1.0
X-WSS-ID: 1BC0B044205867-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

i believe, the claim is, that is exactly the original design point for
certificates
... back when it was assumed that was the only operational method of networks,
i.e. offline, disconnected, email processing i.e. the "phonenet" method
mentioned
at

http://www.garlic.com/~lynn/internet.htm

in the internet history thread.

to some extent, the problems are occuring trying to extend something originated
for offline, disconnected email authentication into online business processes.






"Bob Jueneman" <[e-mail]> on 09/14/99 08:28:37 AM


On the other end of the time spectrum, try using OCSP, or any other protocol
other than CRLs, in disconnected mode while you are on an airplane reading your
signed e-mail.

Bob











Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id IAA03787 for <[e-mail]>; Tue, 14 Sep 1999 08:26:06 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 14 Sep 1999 09:28:46 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Tue, 14 Sep 1999 09:28:37 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Huge CRLs
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 IAA03788

On the other end of the time spectrum, try using OCSP, or any other protocol other than CRLs, in disconnected mode while you are on an airplane reading your signed e-mail.

Bob

>>> Robert Moskowitz <[e-mail]> 09/13/99 04:44AM >>>
At 10:29 AM 9/10/1999 -0400, [e-mail] wrote:

>CRLs in any form are a fundamentally inadequate approach to solving practical 
>problems and in most cases cannot meet business requirements for even small 
>scale infrastructures.  CRLs were a good idea when the terribly impractical 
>people who developed them were working on paper and not such a great idea 
>when you have to turn paper into production systems.   CA revocations 
>experiments done on practical deployments (real world machines, apps, and 
>users) of even small PKIs will demonstrate that complying with your own 
>policy won't happen in the real world if you base your revocation hopes on 
>CRLS.
>Why are you messing with them?
>
Try addressing REALTIME validation.  OCSP caching MIGHT work, but an IPsec
device has millisecs to validate; no time for network latency to retrieve info.

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



Received: from mx3.mail.uk.psi.net (mx3-old.mail.uk.psi.net [154.32.109.150]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA03751 for <[e-mail]>; Tue, 14 Sep 1999 08:25:06 -0700 (PDT)
Received: from mailhost.baltimore.com ([195.152.140.4] helo=stonewall.baltimore.com) by mx3.mail.uk.psi.net with smtp (Exim 2.12 #2) id 11QuUV-0000PA-00 for [e-mail]; Tue, 14 Sep 1999 16:27:31 +0100
To: "'[e-mail]'" <[e-mail]>
Subject: CPs and CPS
Date: Tue, 14 Sep 1999 16:30:35 +0100
Importance: low
X-Priority: 5
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
From: Farrukh Ahmad <[e-mail]>
Message-ID: <[e-mail]>

Hi, I have searched the mail archives and cannot find a clear definition
differentiating Certificate Policies and Certification Practice Statements.
RFC2527 talks of some of the differences but does not provide details of
what should be contractually binding for a relying party. Some of the
categories (e.g. Certificate Application etc.) are not too relevant to
relying parties either - so why is there not a separate framework for CPs?
Continuing from this who is the audience for a CPS if CPs are present -
won't a relying party be content with reading the policy (to which he make
be contractually bound) and not too interested in the practices the CA
adopts to implement them?

Some clarification on this would be a great help.

faz


Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA03532 for <[e-mail]>; Tue, 14 Sep 1999 08:18:06 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id LAA28881 for <[e-mail]>; Tue, 14 Sep 1999 11:20:49 -0400 (EDT)
Received: from lncora06.firstdata.com ([206.201.60.104]) by mailgw.firstdata.com with SMTP id LAA04125 for <[e-mail]>; Tue, 14 Sep 1999 11:20:47 -0400 (EDT)
Received: from 10.2.52.30 by lncora06.firstdata.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v3.6); Tue, 14 Sep 99 11:18:33 -0400
X-Server-Uuid: 28680605-564e-11d3-99f5-0004ac9d9957
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852567EC.0054234A ; Tue, 14 Sep 1999 11:19:00 -0400
X-Lotus-FromDomain: FDC
To: "Phillip M Hallam-Baker" <[e-mail]>
cc: "Robert Moskowitz" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 1999 08:16:32 -0700
Subject: RE: Huge CRLs
MIME-Version: 1.0
X-WSS-ID: 1BC0B8C3200613-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

note also that  for the router/vpn/ipsec scenerio ... that direct analogy for
badged entry systems exists which come in both offline (aka certificate) on
online (possibly OCSP but also AADS ... i.e. certificate-less) deployments.

Both offline and online versions of badged entry systems currently exist meeting
different security and price objectives.

Also, CRL operation tends to be a scaleup issue proportional to the size of the
population ... and somewhat independent to the number of transactions &/or
connections. Online scaleup (at least for the router) tends to be much more
insensitive to the size of the population ... but more proportional to the
number of transactions.

However, the online flavor, is in fact, the scenerio used by 99% of the internet
routers today for authenticating connections ... i.e. RADIUS and like ilk use
online protocol for determining authentication ... and so an online protocol
would not be an enormous business process leap to the existing deployed
infrastructure (whether it was certificate or certificate-less based online
digital signature).





Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA03154 for <[e-mail]>; Tue, 14 Sep 1999 07:54:37 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 813C915531; Tue, 14 Sep 1999 10:57:25 -0400 (EDT)
Received: from camcostello (camcostello.ma.certco.com [10.200.200.94]) by haggis.ma.certco.com (Postfix) with SMTP id 3EF1C7C051; Tue, 14 Sep 1999 10:57:25 -0400 (EDT)
From: "Daniel Lanz" <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Huge CRLs
Date: Tue, 14 Sep 1999 10:57:23 -0400
Message-ID: <000001befec1$746657c0$[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: <026201befe44$a89438f0$[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0

>CRTs are a proprietary method to implement OCSP in a more scalable
>and secure way.

Ambarish,

How do CRTs make OCSP more secure?

Regards,

Dan Lanz





Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA02457 for <[e-mail]>; Tue, 14 Sep 1999 07:18:58 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA21370; Tue, 14 Sep 1999 07:19:36 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA06034; Tue, 14 Sep 1999 07:20:49 -0700 (PDT)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SF5SHL55; Tue, 14 Sep 1999 07:20:52 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Robert Moskowitz" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Huge CRLs
Date: Tue, 14 Sep 1999 10:22:35 -0400
Message-ID: <002101befebc$97446020$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

> Try addressing REALTIME validation.  OCSP caching MIGHT work, but an IPsec
> device has millisecs to validate; no time for network latency to
> retrieve info.

The conclusion might be valid but the argument cannot be.

Consider the performance characteristics of two configurations, in the
first we have an IPSEC firewall behind a cheap router box at the border
of the corporate network. the IPSEC firewall uses CRLs for revocation
information checking.

In the second configuration we have an IPSEC firewall in the same position
as the cheap router. Directly connected to the cheap router is an
OCSP server which communicates with some backend run by the CA by
some irrelevant mechanism.

I submit that if the first configuration is feasible then the second
cannot be infeasible for reasons of latency.


As I said earlier the OCSP/CRL thing is a question of balance and
appropriateness. A truck can move pretty much anything, but it is
more comfortable to ride in a passenger car. Even so it is possible
to bamboozle folk into driving a truck when a car would be better,
just give it wrap arround bumpers, big headlights and call it an
SUV.

If we want to talk about scale then we have to set the target at
a significant level - like a few billion. It is clear that CRTs
cannot scale at that level, consider the difficulty of replicating
an entire trust tree over muliple distributors in real time. With
CRTs you lose one delta in your synchronization and your trust
tree is irreconcilably corrupted.

I presented a very large scale example at RSA'99 employing aspects
of both OCSP and OCDP CRLs. Nobody argued then that it was infeasible
although there were questions as to why scalling to billions was
necessary.

The reason scalling to billions was necessary was to try to show
that this is an unnecessary argument. It is possible to scale revocation
technology to global scale WITHOUT using proprietary technology.


The significance of OCSP is this. It is not sensible, practical or
ecconomic to build a revocation infrastructure which addresses
the planetary scale PKI at present while the size of the largest
PKIs is in the small millions. OCSP permits a decoupling of the
revocation/validation problem from the client implementation. This
in turn means that when it is necessary and usefull to build
revocation/validation infrastructures with planetary scale the
legacy client (ie working, deployed client) issue is not going
to block progress.


		Phill



Received: from imo19.mx.aol.com (imo19.mx.aol.com [198.81.17.9]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA17969 for <[e-mail]>; Mon, 13 Sep 1999 21:14:30 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo19.mx.aol.com (mail_out_v22.4.) id sVNUa06249 (4260); Tue, 14 Sep 1999 00:15:52 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 14 Sep 1999 00:15:51 EDT
Subject: Re: Huge CRLs
To: [e-mail]
CC: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 243

Steve,

I freely acknowlege the fact that I am biased because of my experience, 
sector focus, and sunk costs.   I did not intend to defame or diss anyone or 
their ideas.  Some financial services applications may have requirements and 
profiles that are unique, but I believe that in many cases the early lessons 
learned by the financial services sector will be required reading for others 
who are trying to scale up their systems or engage in high value transactions.

I have tons of reasons for wanting to see revocation issues addressed to the 
satisfaction of a pretty demanding set of customers in the financial services 
sector.    Almost everyone already knows by now that I am working on CRL 
alternatives and have both policy, personal, and economic interests in this 
issue.  What has bothered me for quite some time is that despite everyone's 
best efforts, PKI technology has so far fallen short of delivering on its 
promises and underreturned on investments in part because of inflexible 
technology and models.  Even the most immature solutions have a lot of merit 
and are producing risk reduction results, but it has been extraordinarily 
difficult to integrate PKI into traditional entities production systems 
because of the inflexibility of many models and technologies.  I find more 
potential within PKI to transform business (strategy, policy)  models and 
processes than even TCPIP, but the practical work of infrastructure (legal, 
technical) development is painful.  A lot of effort and other resources are 
being invested and progress is being made.  I have committed significant 
personal resources to support my previous investments in PKI policy, and 
technology.    Much of my time is focused on defining the policy space (law, 
regulation, standards); helping people and institutions understand the policy 
space, business requirements, and technology; and providing technology 
solutions to fill gaps.

I have been working on Federal digital signature legislation for four years 
and believe that we will get another bill this year.  I can only hope that 
the technical infrastructure will be sufficiently robust when the legal 
infrastructure is made partly ready.  The technology and practitioners must 
deliver the goods as promised or the markets and governments will punish 
everyone however tangentially involved.


SPECIFICS

Sometimes certificates are used purely for comfort and possession of a 
certificate from a recognized issuer is acceptable as a superfeatherweight 
identification.  In this case revocation information is likely to be never 
sought and frequency is not a real concern.  In some cases systems do not 
support checking at all.  Many systems in pilot and production that have 
requirements for heavyweight authentication resemble the above pictures when 
subjected to close evaluation.   While this may be abhorrent to some minds, 
it is true that in practice, "effective revocation" is not an option for 
many.  In this case policy must be made to conform to the capability of the 
systems relied upon.  In the long run these suboptimal practices are 
unsatisfactory and unacceptable. Maturation will solve these problems.

In other cases, information must be a fresh as possible.   Recency 
specification between fifteen minutes to two hours are not uncommon policy 
driven requirements.   The transactional environments in the financial 
services sector can be split into wholesale (relatively few participants, 
uncountable dollars, many transactions) and retail (the population, huge 
dollars in total, uncountable transactions.)   Today it is easier by far for 
PKI to meet the requirements of the superfeatherweight and wholesale 
segments, than the retail segment because of gaps between business 
requirements and practical technological capability.  The liability exposures 
and allocation models the banking and securities industry must face present 
tremendous challenges to PKI solutions and practitioners.


Look at the following two extremes:

1.  A CRL is issued every day (or pick some other time period, say every 
week, or every two hours).  Users can go pick this up, and use it for a day 
without having to interact with the repository to get the CRL again.  This 
ignores a few points, for example - you don't want to jam things up when the 
CRL is issued by having everyone go retrieve it at once (Dave Cooper of NIST 
presented several papers on this at recent FPKI-TWG meetings).  (Business 
practices and policy requirements may cause this problem to occur in spades)

Also, different certificates may be issued by different CAs, and so will the 
CRLs, so
you might have to get several CRLs during the day.  (a near certainty) But
basically you have a list of revoked certs that's good for a day or two hours 
or whatever.  Of course, most of the entries on the list are ones you 
probably (almost certaintly) don't care about (depending on how many signed 
messages you get per day, and from whom), so there is "wasted" space and 
bandwidth for the revoked
certs which you don't care about (because you don't get any messages using 
those certs often or ever).

Correspondence not involving authorization of financial transactions or the 
disclosure of sensitive business information is an example of an acceptable 
use of a daily CRL.   Frequently issued CRLS from small scale PKI's are easy 
to implement and rational to support.   Huge frequently isssued CRLs from 
large scale PKIs are another thing altogether.

2.  At the opposite extreme, you could make an OCSP query every time you 
verify a signature.  This can be justified for wholesale transactions, but 
not for ordinary activities.   The response is small (on the order of several 
hundred to 1K bytes including signature of the OCSP responder), and contains 
just the info you want.  But now you are doing a realtime query every time 
you get a signed message, rather than one query for a CRL once a day.  And 
the responder has to sign each response, vs. the CA signing one CRL a day.
This is a serious performance issue.

So #1 and #2 are the two extremes.  Depending on your risk analysis, based on 
transaction volume, transaction  amount, traffic patterns (e.g. # of 
messages/day between two specific parties), bandwidth and storage 
constraints, and so forth, maybe one of these two extremes might be suitable. 
 But there are lots of things in the middle:

3.  If CRLs become large, you can partition them using the CRL distribution 
point mechanism; this handles, to some extent, the bandwidth and storage 
problems.

I have done this.

4.  Many small CRLs can be combined into one indirect
CRL.

I have done this.

5.  If you want more up-to-date information, without issuing a whole new CRL, 
you can use delta CRLs, issued (say) every two hours.  But now the user has 
to keep track of the full original CRL (which he had to do anyway, for one 
day), and apply the delta CRL contents (updates) to that CRL.   So the user 
software gets more complicated. 

I have asked people to do this for me.

6.  OCSP can also precompute responses (maybe driving off full and delta 
CRLs), so an OCSP response can be (using the above example) good for one day, 
two hours, or whatever. This eliminates the need to make an OCSP query for 
every
received message; the downside is you no longer have absolutely current 
results (of course this same downside occurs with all CRL-based mechanisms).  
But that's usually OK.

I have asked people to do this as well.

OR YOU CAN DO ALL OF THE ABOVE AND MORE!

I am focusing on the more part and trying to make the rest work where the 
solution can be made to fit the requirements.

There are other solutions that are not currently practiced and I am convinced 
that none of the solutions (above or unlisted) will emerge the undefeated 
champion of the PKI  revocation world because business requirements, public 
policy driven requirements, server, client, and other system capabilities 
will fail to converge.

Perhaps I should have said that CRLS are inadequate for many applications.

Respectfully,

(x)

...kawika daguio...


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id UAA16766 for <[e-mail]>; Mon, 13 Sep 1999 20:35:10 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Mon, 13 Sep 1999 23:40:03 -0500
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 13 Sep 1999 06:44:37 -0400
To: [e-mail], [e-mail], [e-mail], [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: Huge CRLs
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:29 AM 9/10/1999 -0400, [e-mail] wrote:

>CRLs in any form are a fundamentally inadequate approach to solving practical 
>problems and in most cases cannot meet business requirements for even small 
>scale infrastructures.  CRLs were a good idea when the terribly impractical 
>people who developed them were working on paper and not such a great idea 
>when you have to turn paper into production systems.   CA revocations 
>experiments done on practical deployments (real world machines, apps, and 
>users) of even small PKIs will demonstrate that complying with your own 
>policy won't happen in the real world if you base your revocation hopes on 
>CRLS.
>Why are you messing with them?
>
Try addressing REALTIME validation.  OCSP caching MIGHT work, but an IPsec
device has millisecs to validate; no time for network latency to retrieve info.

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


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id UAA16723 for <[e-mail]>; Mon, 13 Sep 1999 20:34:12 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Mon, 13 Sep 1999 23:40:03 -0500
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 13 Sep 1999 07:48:44 -0400
To: Russ Housley <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: Certificate Polilcy Criticality
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:17 PM 9/10/1999 -0400, Russ Housley wrote:
>
>I suggest that the Internet PKI Profile be updated to always mark 
>certificate policy extensions as critical.  This will ensure the correct 
>behavior by all implementations.

Policy is always critical to me.

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


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA12508 for <[e-mail]>; Mon, 13 Sep 1999 16:57:58 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id RAA23139; Mon, 13 Sep 1999 17:00:28 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id RAA13348; Mon, 13 Sep 1999 17:00:28 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Huge CRLs
Date: Mon, 13 Sep 1999 17:04:04 -0700
Message-ID: <026201befe44$a89438f0$[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]>

Hi Daniel,
    I would think OCSP (and for that matter, CRTs) is such an
alternative (tweaking of) to CRLs. Were you thinking about that
in your mail?

Regards,
Ambarish

P.S.
For those who might not have been following PKIX actively over the
last few months - there is a protocol - OCSP (RFC 2560) that
enables rapid checking of the revocation status of certs, without
the overhead of needing to download full CRLs. It is currently
being used in quite a few pilots (including some at banks) and even
in a production environment in a few places.

CRTs are a proprietary method to implement OCSP in a more scalable
and secure way.


---------------------------------------------------------------------
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]]
Sent: Monday, September 13, 1999 12:27 PM
Cc: [e-mail]
Subject: Re: Huge CRLs


Stephen Kent wrote:
Not all the world is the financial services sector.  Criticisms of CRL use
models based primarily on difficulties encountered in employing them in
that environment, or based on poor implementations, or based on poor
management parameter choices, etc.  do not necessarily mean that CRLs are
unworkable.
Thank God for that! What a boring world it would be if everyone was a
banker.
But the importance of privacy and cryptography to financial services cannot
be overlooked or ignored. It is no coincidence that the largest drivers of
cryptography deployment have been banks and investment firms (and markets).
Just recently, only banks were allowed to distribute greater-than-export
strength crypto for their clientele.
If CRLs are unsuitable for that environment, they should be tweaked until
they are suitable (or until another means of similar functionality is
developed). Ignoring this very large share of the market would be foolish;
if you do, you'll lose a lot of customers. After all, PKI has been around
for a while now and still hasn't "taken off." Many of us believe that PKI as
we know it isn't "it," and something else will inevitably turn up that
succeeds where PKI failed. Vendors clearly haven't produced anything usable
for this sector, leaving the firms themselves to develop next-generation
security. And why shouldn't we be successful? We've done it before.

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




Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4-ext.email.verio.net [129.250.36.44]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA09853 for <[e-mail]>; Mon, 13 Sep 1999 12:27:21 -0700 (PDT)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout4.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI0JIZ00.0A1 for <[e-mail]>; Mon, 13 Sep 1999 19:30:35 +0000 
Received: from nma.com ([209.21.28.93]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI0IMQ00.3FK; Mon, 13 Sep 1999 19:11:14 +0000 
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 1999 12:30:35 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: Ben Laurie <[e-mail]>, [e-mail], [e-mail], [e-mail], Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Huge CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:

> Isn't this problem solved by the use of the CRLDistributionPoint
> mechanism?
>
> Is thought IE5 was already checking CRLs, if the CRLDistributionPoint
> was specified?

Bob:

It seems that Entrust.net certs + IE 5.0 affords the CRL verification process.  There
also other specialized combinations I am aware of  and it would be good to
hear about current work in this front, especially on CRLs for cross-certification.
But,  still, SSL in current browsers does  not allow a client to send a list of
trusted CAs to the server.  So, if we believe that the decision of trust should
be verifier-centric then  it does not help much to be able to verify what you are
told to trust.  And yet, providing this capability would not seem to be
rocket-science for the client side (since the server already has it)

So, what the user community might desire is a SSL protocol improvement
in order to have the necessary trust freedom to choose browser and CA
from the client side.  I for example, without any bias against Microsoft,
refuse to trust the IE browser for a variety of reasons -- even though I
would trust an Entrust.net cert for some purposes.

The first nail to bang on seems thus to be the SSL protocol, the second one
the CRL process itself for the other reasons mentioned in this thread. And,
I agree with Phil that banging on the CRL nail right now might be quite
unproductive.

Cheers,

Ed Gerck

PS: enjoyed your disclaimer ;-)

> DISCLAIMER:
>   If this message (with or without attached documents) is digitally
> signed, and/or if certificates are attached, the intended purpose is to
>
>    (1) Ensure that e-mail came from the apparent sender
>    (2) Protect e-mail from tampering
>    (3) Ensure that the content of e-mail sent to me and encrypted in
> my dual-use key cannot be viewed by others.
>   It is explicitly NOT the intent of any such signed message or
> document to represent any type or form of legally binding contract or
> other representation, and any such interpretation should not be
> considered commercially reasonable and WILL BE REPUDIATED,
> notwithstanding any wording or implications to the opposite effect in
> the text of the message itself; due in part, but not exclusively, to the
> fact that the security of my workstation and its associated cryptography
> is not judged adequately strong for such purposes at present.



Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA09691 for <[e-mail]>; Mon, 13 Sep 1999 12:24:32 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xma009680; Mon, 13 Sep 99 15:27:26 -0400
Received: from siac.com (localhost [127.0.0.1]) by charley.wisdom.siac.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA06445 for <[e-mail]>; Mon, 13 Sep 1999 15:27:16 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 1999 15:27:16 -0400
From: Daniel Alex Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61C-SGI [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]>
Content-Type: multipart/alternative; boundary="------------EA9053B9127D6D5CDCC0F704"

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

Stephen Kent wrote:

> Not all the world is the financial services sector.  Criticisms of CRL use
> models based primarily on difficulties encountered in employing them in
> that environment, or based on poor implementations, or based on poor
> management parameter choices, etc.  do not necessarily mean that CRLs are
> unworkable.

Thank God for that! What a boring world it would be if everyone was a banker.

But the importance of privacy and cryptography to financial services cannot be
overlooked or ignored. It is no coincidence that the largest drivers of
cryptography deployment have been banks and investment firms (and markets). Just
recently, only banks were allowed to distribute greater-than-export strength
crypto for their clientele.

If CRLs are unsuitable for that environment, they should be tweaked until they
are suitable (or until another means of similar functionality is developed).
Ignoring this very large share of the market would be foolish; if you do, you'll
lose a lot of customers. After all, PKI has been around for a while now and still
hasn't "taken off." Many of us believe that PKI as we know it isn't "it," and
something else will inevitably turn up that succeeds where PKI failed. Vendors
clearly haven't produced anything usable for this sector, leaving the firms
themselves to develop next-generation security. And why shouldn't we be
successful? We've done it before.


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



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Stephen Kent wrote:
<blockquote TYPE=CITE>Not all the world is the financial services sector.&nbsp;
Criticisms of CRL use
<br>models based primarily on difficulties encountered in employing them
in
<br>that environment, or based on poor implementations, or based on poor
<br>management parameter choices, etc.&nbsp; do not necessarily mean that
CRLs are
<br>unworkable.</blockquote>
Thank God for that! What a boring world it would be if everyone was a banker.
<p>But the importance of privacy and cryptography to financial services
cannot be overlooked or ignored. It is no coincidence that the largest
drivers of cryptography deployment have been banks and investment firms
(and markets). Just recently, only banks were allowed to distribute greater-than-export
strength crypto for their clientele.
<p>If CRLs are unsuitable for that environment, they should be tweaked
until they are suitable (or until another means of similar functionality
is developed). Ignoring this very large share of the market would be foolish;
if you do, you'll lose a lot of customers. After all, PKI&nbsp;has been
around for a while now and still hasn't "taken off." Many of us believe
that PKI&nbsp;as we know it isn't "it,"&nbsp;and something else will inevitably
turn up that succeeds where PKI failed. Vendors clearly haven't produced
anything usable for this sector, leaving the firms themselves to develop
next-generation security. And why shouldn't we be successful? We've done
it before.
<br>&nbsp;
<pre>--&nbsp;
Daniel Alex Finkelstein
Shared IT Services
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>

--------------EA9053B9127D6D5CDCC0F704--



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA09221 for <[e-mail]>; Mon, 13 Sep 1999 11:51:08 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 13 Sep 1999 12:53:36 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Mon, 13 Sep 1999 12:53:31 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Huge CRLs
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_EABC0D20.36573F12"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_EABC0D20.36573F12
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Isn't this problem solved by the use of the CRLDistributionPoint mechanism?=


Is thought IE5 was already checking CRLs, if the CRLDistributionPoint =
was=20
specified?

Bob

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

DISCLAIMER:
  If this message (with or without attached documents) is digitally =
signed, and/or if certificates are attached, the intended purpose is to=20
   (1) Ensure that e-mail came from the apparent sender
   (2) Protect e-mail from tampering
   (3) Ensure that the content of e-mail sent to me and encrypted in  my =
dual-use key cannot be viewed by others.
  It is explicitly NOT the intent of any such signed message or document =
to represent any type or form of legally binding contract or other =
representation, and any such interpretation should not be considered =
commercially reasonable and WILL BE REPUDIATED, notwithstanding any =
wording or implications to the opposite effect in the text of the message =
itself; due in part, but not exclusively, to the fact that the security of =
my workstation and its associated cryptography is not judged adequately =
strong for such purposes at present.

>>> Ed Gerck <[e-mail]> 09/13/99 05:33AM >>>


Ben Laurie wrote:

> Ed Gerck wrote:
> > Further, the major X.509 security application today, SSL, does not
> > check revocation lists -- so they are near to useless. Also, the user =
is
> > not able to check server certificates (and certificates in the CA =
chains)
> > against revocation lists.
>
> That depends on the implementation. It is entirely possible for an SSL
> implementation to check CRLs, and some do.

In SSL, the client knows which CAs are acceptable *to the server* for =
signature
validation and CRL verification because the server *sends* a list of =
distinguished
names in the "certificate request" message. However, there is no correspond=
ing
list sent in the other direction in SSL (from the client to the server).  =
Thus,  the
server is essentially groping in the dark when trying to supply a =
certificate that
the client can check for its CRL, because the server is not informed by =
the client
what CAs to best aim for in a ranking list  (CAs that are directly trusted =
by the
client for signature and CRLs, untrusted CAs directly trusted by a CA that
the client trusts, etc.).

So,  SSL indeed does not offer a mechanism to allow clients to effectively =
check
CRLs for server certs.  Thus, as I commented, "the user is not able to =
check
*server certificates* (and certificates in the CA chains) against =
revocation lists"
-- BTW, as we can see in current browsers.

But, your remark does apply to client certs that are sent to the server =
and I am
thankful for your clarification.  The major use of SSL is however in =
securing
servers and in this case CRLs are oftentimes useless for clients.

BTW, my text was a segment from the paper "Overview of Certification =
Systems"
at http://www.mcg.org.br/certover.pdf -- and even though there the context =
of
users checking *server certificates* seems clear throughout, I will =
further clarify
it with your comment in mind.

Thanks,

Ed Gerck



--=_EABC0D20.36573F12
Content-Type: text/x-vcard
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="Bob Jueneman.vcf"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Robert R. Jueneman
TEL;WORK:1-801-861-7387, 1-800-453-1267
ORG:Novell, Inc.;Network Security Development
TEL;PREF;FAX:[phone]
EMAIL;WORK;PREF;NGW:[e-mail]
N:Jueneman;Bob
TITLE:Security Architect
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;US=
A
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. =
Jueneman=3D0A=3D
PRV-F331=3D0A=3D
122 E. 1700 South=3D0A=3D
Provo, Utah  84606=3D0A=3D
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. =
Jueneman=3D0A=3D
PRV-F331=3D0A=3D
122 E. 1700 South=3D0A=3D
Provo, Utah  84606
TEL;HOME:1-801-765-4378
TEL;CELL:1-801-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
X-GWUSERID:BJUENEMAN
END:VCARD


--=_EABC0D20.36573F12--


Received: from jade. ([164.124.96.60]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA08493; Mon, 13 Sep 1999 11:21:59 -0700 (PDT)
From: [e-mail]
Received: from 164.124.96.60 by jade. (SMI-8.6/SMI-SVR4) id DAA15226; Tue, 14 Sep 1999 03:09:15 +0900
Message-Id: <199909131809.DAA15226@jade.>
To: [e-mail]
Date: Mon, 13 Sep 99 18:21:07 EST
Subject: Missing Links

Want to find your missing links ?

Want to get more Web Site traffic ?

Want the Secrets of the search Engines ?

Webmaster Free Business Links has them all.

Check it out on : http://209.234.163.159/

Webmaster Free Business Links





++++ Sender & Remove Instructions ++++
Free Business Links
Bevere Close
Worcester
Tel [phone]
++++++++++++++++++++++++++++++++++++
To get removed from our email list please go to
http://www.domainname.com/cleanlist.html
++++++++++++++++++++++++++++++++++++



Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA08302 for <[e-mail]>; Mon, 13 Sep 1999 11:17:45 -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 SAA25903; Mon, 13 Sep 1999 18:20:41 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 TAA21478; Mon, 13 Sep 1999 19:21:02 +0100
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 1999 19:20:40 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.6 [en-gb] (WinNT; I)
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed Gerck wrote:
> 
> Ben Laurie wrote:
> 
> > Ed Gerck wrote:
> >
> > > In SSL, the client knows which CAs are acceptable *to the server* for signature
> > > validation and CRL verification because the server *sends* a list of distinguished
> > > names in the "certificate request" message. However, there is no corresponding
> > > list sent in the other direction in SSL (from the client to the server).  Thus,  the
> > > server is essentially groping in the dark when trying to supply a certificate that
> > > the client can check for its CRL, because the server is not informed by the client
> > > what CAs to best aim for in a ranking list  (CAs that are directly trusted by the
> > > client for signature and CRLs, untrusted CAs directly trusted by a CA that
> > > the client trusts, etc.).
> > >
> >
> > But since most SSL servers have but a single certificate, surely all the
> > client has to do is check the CRL once it has received the server
> > certificate?
> 
> The first interesting question raised here is that of trust -- I cannot assume
> or favor the notion that there is only one CA that the client MUST trust,
> which  CA is by the way the ONE that the *other party* (the server) has
> chosen ;-)

That is irrelevant. The client can choose to trust or not trust the CA.
Whether they do is orthogonal to the question of CRL checking.

> So, since SSL does not offer a client-mechanism to decide who to trust for
> what, and since this also translates into an anti-competitive issue built right
> into the SSL protocol, I see then that the decision of trust is, from the first
> moment, removed from the client. Both for certificates and for CRLs -- which
> would not have to be provided the issuing CA.  So, there is a second decision
> of trust removed by the SSL protocol -- the server and the client have no
> choice for VA and must use the issuing CA.
> 
> So, where should the client look for the CRL? At the CA site that the client does
> not trust?  Or, cannot reach?  What URL? How about redundancy, alternatives?
> 
> The conclusion IMO is that which I commented first, but edited to stress the
> client context. That the major X.509 security application today, SSL, does not
> allow the client to check revocation lists that the client trusts -- so they are near
> to useless. Also, the client is  not able to check server certificates (and certificates
> in the CA chains) against client-defined revocation lists (VAs, for example).

That is not what you said. You said that there was no way for the client
to check CRLs, not that there was no way to check CRLs that the client
trusts. Furthermore, if the client trusts the CA, then they should trust
the CRL. If they do not, then it hardly matters whether they check it or
not, since they don't trust the certificate anyway.

> The alternative for the client is to proceed manually, outside of SSL. But, we
> know, users do not have the training to use a complicated secure procedure
> if a simpler and unsafe procedure is just a click away.
> 
> For the server, however, SSL affords a better procedure since the client knows
> which CAs the server trusts for what, as I commented above

Again, this is a sidetrack: the client can also choose which CAs it
trusts. The fact that it does not communicate them to the server is a
different matter.

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 dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA07610 for <[e-mail]>; Mon, 13 Sep 1999 10:30:55 -0700 (PDT)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI0E4W00.I9E for <[e-mail]>; Mon, 13 Sep 1999 17:34:08 +0000 
Received: from nma.com ([209.21.28.110]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FI0E4K00.TA9; Mon, 13 Sep 1999 17:33:56 +0000 
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 1999 10:34:09 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Laurie <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ben Laurie wrote:

> Ed Gerck wrote:
>
> > In SSL, the client knows which CAs are acceptable *to the server* for signature
> > validation and CRL verification because the server *sends* a list of distinguished
> > names in the "certificate request" message. However, there is no corresponding
> > list sent in the other direction in SSL (from the client to the server).  Thus,  the
> > server is essentially groping in the dark when trying to supply a certificate that
> > the client can check for its CRL, because the server is not informed by the client
> > what CAs to best aim for in a ranking list  (CAs that are directly trusted by the
> > client for signature and CRLs, untrusted CAs directly trusted by a CA that
> > the client trusts, etc.).
> >
>
> But since most SSL servers have but a single certificate, surely all the
> client has to do is check the CRL once it has received the server
> certificate?

The first interesting question raised here is that of trust -- I cannot assume
or favor the notion that there is only one CA that the client MUST trust,
which  CA is by the way the ONE that the *other party* (the server) has
chosen ;-)

So, since SSL does not offer a client-mechanism to decide who to trust for
what, and since this also translates into an anti-competitive issue built right
into the SSL protocol, I see then that the decision of trust is, from the first
moment, removed from the client. Both for certificates and for CRLs -- which
would not have to be provided the issuing CA.  So, there is a second decision
of trust removed by the SSL protocol -- the server and the client have no
choice for VA and must use the issuing CA.

So, where should the client look for the CRL? At the CA site that the client does
not trust?  Or, cannot reach?  What URL? How about redundancy, alternatives?

The conclusion IMO is that which I commented first, but edited to stress the
client context. That the major X.509 security application today, SSL, does not
allow the client to check revocation lists that the client trusts -- so they are near
to useless. Also, the client is  not able to check server certificates (and certificates
in the CA chains) against client-defined revocation lists (VAs, for example).

The alternative for the client is to proceed manually, outside of SSL. But, we
know, users do not have the training to use a complicated secure procedure
if a simpler and unsafe procedure is just a click away.

For the server, however, SSL affords a better procedure since the client knows
which CAs the server trusts for what, as I commented above

Cheers,

Ed Gerck




Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA07269 for <[e-mail]>; Mon, 13 Sep 1999 10:13:05 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA15406; Mon, 13 Sep 1999 10:14:12 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA05688; Mon, 13 Sep 1999 10:15:06 -0700 (PDT)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SF5SH1XT; Mon, 13 Sep 1999 10:15:07 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Huge CRLs
Date: Mon, 13 Sep 1999 13:16:45 -0400
Message-ID: <001201befe0b$c15ac7c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <v04020a03b4002a7dc532@[128.89.0.111]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

> Not all the world is the financial services sector.  Criticisms of CRL use
> models based primarily on difficulties encountered in employing them in
> that environment, or based on poor implementations, or based on poor
> management parameter choices, etc.  do not necessarily mean that CRLs are
> unworkable.

Steve,

	I agree with your sentiments but I would prefer to see you saying
something of the form 'this argument is irrelevant' or 'this argument
is unproductive'.

	We have already argued the case for supporting both online
and blacklist style revocation. There are applications in which both
approaches have specific advantages which may well prove critical.

	I don't see how the current argument is going to lead to any
substantive change to the WG drafts or RFCs. We have already advanced
both sets of drafts to proposed standard status. 

	Tempting though it may be to answer the numerous minor and minor
fallacies in the argument presented I suggest that we just refer the
combatants to the discussions we had on this topic over a year ago. 

		Phill



Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA05964 for <[e-mail]>; Mon, 13 Sep 1999 08:45:32 -0700 (PDT)
Received: from [212.140.3.101] (helo=dwc-acer) by tungsten.btinternet.com with smtp (Exim 2.05 #1) id 11QYLR-00004c-00; Mon, 13 Sep 1999 16:48:42 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: "Jochen Keutel" <[e-mail]>, [e-mail]
Date: Mon, 13 Sep 1999 16:48:24 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: deltaRevocationLists and LDAP
Reply-to: [e-mail]
Priority: normal
In-reply-to: <000001befddc$adb7f820$21c35ac3@keutel1>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-Id: <[e-mail]>

From:           	"Jochen Keutel" <[e-mail]>

> Hello,
>   following problem:
> 
Help is on its way. But..
Unfortunately there is no solution for LDAPv2, as it is a "dead 
protocol" i.e. it cannot be extended in any way, and the IETF have 
stopped its standardisation. But there is a solution on its way for 
LDAPv3. A new Internet Draft has been released that gives LDAPv3 
the X.500 DAP matchedValuesOnly facility. See:

<draft-ldapext-matchedval-01.txt>

for details. This will allow you to retrieve a 
single attribute value providing the matching 
rule is fine tuned enough. The matching rule you 
want is the certificateList matching rule. THis 
allows you to select on CRL number. Now whilst 
you cannot select a delta CRL with a particular 
delta indicator (base crl number) and crl number, 
being able to select a delta CRL with a 
particular crl number (or range of numbers) 
should be sufficient. Of course, first you have 
to have an LDAP implementation that supports the 
matching rule (which is currently only defined in 
X.500). My LDAPv3 profile 

<draft-pkix-ldap-v3-01.txt>

has started to define this matching rule in LDAP 
terms, but is not yet complete. Mark Wahl has 
said that he will take this work into the update 
of LDAPv3 when it is issued.

David


David

> - On day 1 a CA issues a complete CRL with number 1 and stores it in an
> LDAP server - Entry "CN=CA,O=company,C=DE", attribute
> certificateRevocationList (no special crlDistribution points are used). -
> On day 2 this CA issues again a complete CRL with number 2 and
> additionally a deltaRevocationList (number 2, deltaCRLIndicator 1) and
> stores it in the LDAP server - the attribute value of
> certificateRevocationList will be overwritten, and the deltaCRL ist stored
> in the attribute deltaRevocationList - On day 3 this CA issues again a
> complete CRL with number 3 and additionally a deltaRevocationList (number
> 3, deltaCRLIndicator 2) and stores it in the LDAP server - the attribute
> value of certificateRevocationList will be overwritten, and the deltaCRL
> ist stored in the attribute deltaRevocationList. So the attribute
> deltaRevocationList has two values now.
> 
> (This problem is simplified, of course - just to demonstrate the problem.
> E.g. the CRL is assumed to be valid one day.)
> 
> What does a PKI user do?
> 
> On day 1 it loads the complete CRL from the LDAP server.
> 
> On day 2 it checks "next Update" - therefore it has to load either a new
> complete CRL or the delta. Let's assume the policy is "load deltas". So it
> performs - in LDAP terms - a
>  ldapsearch -h host -p port -b "CN=CA,O=company,C=DE" \
>  -s base 'objectClass=*' deltaRevocationList
> OK - exactly one deltaCRL is returned.
> 
> On day 3 it checks again "nextUpdate" - and again it has to get a new
> delta from the LDAP server.
> 
> Now the question: How can the client specify (in the LDAP protocol - V2
> and V3) that it wants to get exactly the DeltaCRL number 3 ???
> 
> Next question: Let's assume another client loads the complete CRL on day
> 1, on day 2 he does nothing (vacations, ...). On day three he wants to
> load "all Deltas since day 1". Again - how can this be formulated in LDAP
> terms?
> 
> ---
> 
> I'm familiar with X.500 and LDAP V2 and V3. I know the X.500 search
> control "matchedValuesOnly"; I know the special matching rules from X.509
> (97). Still this problem doesn't seem to be easy.
> 
> So: Is there any standard describing the answer? (I haven't found anything
> in the PKIX RFCs - esp. 2459 and 2559.) How do implementors of PKI
> products (which use LDAP) solve this problem?
> 
> I guess the problem is not new - the scenario seems very basic, and it
> should happen quite often at many companies using PKIs ...
> 
> Bye,
>   Jochen.
> ---
> Jochen Keutel
> duerr com.soft, Senior Consultant
> "Directory Services and Security Solutions"
> Berlin, Germany
> 
> 


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

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
*NEW* Email [e-mail] *NEW*
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 eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA02946 for <[e-mail]>; Mon, 13 Sep 1999 05:34: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 MAA10064; Mon, 13 Sep 1999 12:37:25 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 NAA19536; Mon, 13 Sep 1999 13:37:40 +0100
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 1999 13:37:25 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.6 [en-gb] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
CC: Stephen Kent <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed Gerck wrote:
> 
> Ben Laurie wrote:
> 
> > Ed Gerck wrote:
> > > Further, the major X.509 security application today, SSL, does not
> > > check revocation lists -- so they are near to useless. Also, the user is
> > > not able to check server certificates (and certificates in the CA chains)
> > > against revocation lists.
> >
> > That depends on the implementation. It is entirely possible for an SSL
> > implementation to check CRLs, and some do.
> 
> In SSL, the client knows which CAs are acceptable *to the server* for signature
> validation and CRL verification because the server *sends* a list of distinguished
> names in the "certificate request" message. However, there is no corresponding
> list sent in the other direction in SSL (from the client to the server).  Thus,  the
> server is essentially groping in the dark when trying to supply a certificate that
> the client can check for its CRL, because the server is not informed by the client
> what CAs to best aim for in a ranking list  (CAs that are directly trusted by the
> client for signature and CRLs, untrusted CAs directly trusted by a CA that
> the client trusts, etc.).
> 
> So,  SSL indeed does not offer a mechanism to allow clients to effectively check
> CRLs for server certs.  Thus, as I commented, "the user is not able to check
> *server certificates* (and certificates in the CA chains) against revocation lists"
> -- BTW, as we can see in current browsers.
> 
> But, your remark does apply to client certs that are sent to the server and I am
> thankful for your clarification.  The major use of SSL is however in securing
> servers and in this case CRLs are oftentimes useless for clients.
> 
> BTW, my text was a segment from the paper "Overview of Certification Systems"
> at http://www.mcg.org.br/certover.pdf -- and even though there the context of
> users checking *server certificates* seems clear throughout, I will further clarify
> it with your comment in mind.

But since most SSL servers have but a single certificate, surely all the
client has to do is check the CRL once it has received the server
certificate?

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 mail.routing.net ([62.104.62.38]) by mail.proper.com (8.9.3/8.9.3) with SMTP id EAA02256 for <[e-mail]>; Mon, 13 Sep 1999 04:36:53 -0700 (PDT)
Received: from keutel1 (195.90.195.33) by mail.routing.net with MERCUR-SMTP/POP3/IMAP4-Server (v3.10.13 AS-0098316) for <[e-mail]>; Mon, 13 Sep 1999  13:39:30 +0200
From: "Jochen Keutel" <[e-mail]>
To: <[e-mail]>
Subject: deltaRevocationLists and LDAP
Date: Mon, 13 Sep 1999 13:39:45 +0200
Message-ID: <000001befddc$adb7f820$21c35ac3@keutel1>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01BEFDED.7140C820"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MS-TNEF-Correlator: 0000000003E8329F1CE1BE118DA0D2C472F94BD9E4692000
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01BEFDED.7140C820
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
  I asked the following on the cert-talk mailing list some days ago but =
haven't got any response yet ...

Thanks for any hint.

Bye,
		Jochen.
---
Hello,
  following problem:

- On day 1 a CA issues a complete CRL with number 1 and stores it in an =
LDAP server - Entry "CN=3DCA,O=3Dcompany,C=3DDE", attribute =
certificateRevocationList (no special crlDistribution points are used).
- On day 2 this CA issues again a complete CRL with number 2 and =
additionally a deltaRevocationList (number 2, deltaCRLIndicator 1) and =
stores it in the LDAP server - the attribute value of =
certificateRevocationList will be overwritten, and the deltaCRL ist =
stored in the attribute deltaRevocationList
- On day 3 this CA issues again a complete CRL with number 3 and =
additionally a deltaRevocationList (number 3, deltaCRLIndicator 2) and =
stores it in the LDAP server - the attribute value of =
certificateRevocationList will be overwritten, and the deltaCRL ist =
stored in the attribute deltaRevocationList. So the attribute =
deltaRevocationList has two values now.

(This problem is simplified, of course - just to demonstrate the =
problem. E.g. the CRL is assumed to be valid one day.)

What does a PKI user do?

On day 1 it loads the complete CRL from the LDAP server.

On day 2 it checks "next Update" - therefore it has to load either a new =
complete CRL or the delta. Let's assume the policy is "load deltas". So =
it performs - in LDAP terms - a
	ldapsearch -h host -p port -b "CN=3DCA,O=3Dcompany,C=3DDE" \
	-s base 'objectClass=3D*' deltaRevocationList
OK - exactly one deltaCRL is returned.

On day 3 it checks again "nextUpdate" - and again it has to get a new =
delta from the LDAP server.

Now the question: How can the client specify (in the LDAP protocol - V2 =
and V3) that it wants to get exactly the DeltaCRL number 3 ???

Next question: Let's assume another client loads the complete CRL on day =
1, on day 2 he does nothing (vacations, ...). On day three he wants to =
load "all Deltas since day 1". Again - how can this be formulated in =
LDAP terms?

---

I'm familiar with X.500 and LDAP V2 and V3. I know the X.500 search =
control "matchedValuesOnly"; I know the special matching rules from =
X.509 (97). Still this problem doesn't seem to be easy.

So: Is there any standard describing the answer? (I haven't found =
anything in the PKIX RFCs - esp. 2459 and 2559.)
How do implementors of PKI products (which use LDAP) solve this problem?

I guess the problem is not new - the scenario seems very basic, and it =
should happen quite often at many companies using PKIs ...

Bye,
		Jochen.
---
Jochen Keutel
duerr com.soft, Senior Consultant
"Directory Services and Security Solutions"
Berlin, Germany


------=_NextPart_000_0001_01BEFDED.7140C820
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+Ii4LAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAAM8HCQANAA0AJwAAAAEAIQEB
A5AGAPwKAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAHgAAAGRlbHRhUmV2b2NhdGlvbkxpc3RzIGFuZCBMREFQAAAAAgFxAAEAAAAWAAAAAb793Juu
FayY82ngEdOLewAA6F4+DwAAAgEdDAEAAAAWAAAAU01UUDpKT0NIRU5AS0VVVEVMLkRFAAAACwAB
DgAAAABAAAYOAOIsktz9vgECAQoOAQAAABgAAAAAAAAAA+gynxzhvhGNoNLEcvlL2cKAAAALAB8O
AQAAAAMABhD/itc6AwAHEGIIAAAeAAgQAQAAAGUAAABIRUxMTyxJQVNLRURUSEVGT0xMT1dJTkdP
TlRIRUNFUlQtVEFMS01BSUxJTkdMSVNUU09NRURBWVNBR09CVVRIQVZFTlRHT1RBTllSRVNQT05T
RVlFVFRIQU5LU0ZPUkFOWUhJAAAAAAIBCRABAAAAhQYAAIEGAAD5CwAATFpGdYiVwOwDAAoAcmNw
ZzEyNRYyAPgLYG4OEDAzMZ0B9yACpAPjAgBjaArAYHNldDAgBxMCgH0ZCoF1YwBQCwN1bG6FAiBl
C6YgSGVsCQAGLAqiCoAgIEkgYQRzawmAIHRoZSBvAhAT0QPwDyAgAiAVA2OJBJB0LQGQbGsgAMDX
AxAVshcwcwVAcwNwFTAIZGF5BCBhZ28grGJ1BUARAHYJ8CcFQCcYgAVAAHB5IAlwc3CTAiARMCB5
EUAgLhrAyxQUFBRUEQBuawQgAhCrBcAZsmgLgHQa60IagMcUBQyEAaAgSm8Q8AnwfRrlLR+wGvgU
8BO8FVhwIwNgAmBlbToa+i0gJk8DoBghIDEUoCBD/EEgBAEKUBhRFlADcAtQwxFAFTBDUkwgA/AV
ELggbnUG0ASQI+JuFPB/F6AFsAeRJdAkUAOgA5FM+ERBUBfABJAZEAXAI2AKRQIwchnQIkNOPTEk
MCxPPSTyGbEsQ+A9REUiLBSgAkAFEB8YsRZEBpAN4CqgZVJlVnYe8CqgaQIgTBeSKDsS4BfAcAWQ
BzEWUHJs3kQXkSrTLGEiEG8csRhRyQlwIHURMGQpH0Yjdu4yFQEEACQqZwtxJM8l2eMwoCaiYWRk
JdAsYQdA7mwZ0CQQAQBsAZAr/zNldyqANRMlgUkmsCuiBbExvikmnxUDJ+wVEiqodgdA+wpQFeBm
Kz8sSAPwE9AYoPs7oShhdwUQAkAJ8CqBJrH/FRI3BiRRF7Em8hTwOTUqqPc1HxegIw0zML8xzyWd
Q9C3M+80/zYLMzbvBbEyOD//OU86XztvPH89jz6fP69Av/9IXxzQBgAYkFQPSH8RAAQgvHR3GJBO
kwQgEuB3Guv+KBuwRBEiJSRRF8AHcAtQf09hCYAqgE7yCGEaUSNgav8vUAVAJvBXMQRgAIAo4E+h
xxUDIiVWEEUuZ1YQFRJ/UuQUoSSAB4AU8RiRTnNppxTwEvEYEi4pGvpXEQDJBUBkbySjUEsUkC9R
+wXAYvA/GvojhydRCQBHUP9YoRYyRXoDUkyOGuswNydRVR8BYxvxIhMAeAVAVfZwGCBFwCJNhAlw
HCEVMM8nUViDGJBloiBlJdEmUX8kEBMAB+BFawWxUldWEEz9EUAnX/ZeNAbwDeAZ0EQR5iJsk1dD
cyJWEydRLTD6chwhbQQgI2AngSfjRcDdcrRhHfgXcBggcBEwCsAnEPAokCXwaG8XoS1w/y6RACAo
kB7AKS8qMwMweCC1dDgtBCBiFLAVMCciQDJqBZB0QwtgBBA9KuYnVz9Ct09LKJFqcADQ3nRH8WFT
UqgZ4XQIcBMA/mRoX0OjabhE5GpTarhHE/tE82v4ZxqRbVR6c2cPaB+2ThWQFQNxJJEsUjoToH+G
AU+QFgUXMAnwF7EtMmZ9GdAoTGoiISbwCOEokVZ5M8RWM0tgFRBiwSdRd98AcC7hgrV8VhUSRFKm
Rof+P44ghTtqcoZ4b2sAcBmA/20Sh9Vlr24lI5VcITBGUmK3YwKQ4hWyKE6QLDRzKoD/GsEvkCN2
FRAJ0ZRSi3dsk+4iR9GM9FtibhZgI6Rx0f5BRPMjYHWwhzZEEVERcpJ/EsBPoVOzc0hkGx+7CoBJ
4idbMGZhbRchCsElw/BYLjUwEWBLgifjikf7VhAUkGtZcRUDn+R1FQWgKyjRifEiAMB0HwFkVudZ
EyOAR/AiO6F6LSajk70VsnISwAeRg+Of4jks0PQ5N5ZRU09QUOFD81rWv2LyGTIRMFshYJR1IHNh
sPca+lYwhvBJkgMvIRmyF6DvS4EgYgEABPJiFbJNswCAencEkD8s0BSQGPYCEHVfRyIZwJUETGVj
YVgH8EaOQ3LSGgFWEDI0NaeA/0uCDjCxwGHGhxJi8CRQRYJ/B4ACMAWwBCBO8WNiIiFk8xIwLuEo
dxygdVEvUSfTe0tgF9BsGRCoW2QbFJBn/ySRkgRa2ZDhbWNNlATwCfD/CsAsYKmjBCAoYRnQeSEN
4HtR9CdRc3WwEsAU8BEAcP8tMAOghnAl0E7SUcEqkRbx/xnBKbQIkAQgL1AVsmNhBCAfGs0dvx7P
H9XCNCBLZX8rAQlQFCO00ASQkTEDcC7/F9ABgCqABmADAAWxCFAAgPcSwKyRQtUiLdAJcHnABbB7
GdAGYXYN4CSiJrEGYGP9CHF0x8EG8C5DccDApQSQ+xcxKoBHc6EZsR/pFBQR8QIAzIAAAAADABAQ
AAAAAAMAERAAAAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADA
AAAAAAAARgAAAAAQhQAAAAAAAAMACYAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAAwA1gAgg
BgAAAAAAwAAAAAAAAEYAAAAAUoUAAPATAAALAEKACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAA
AAMARIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwBFgAggBgAAAAAAwAAAAAAAAEYAAAAA
GIUAAAAAAAAeAF+ACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjUACwBggAggBgAA
AAAAwAAAAAAAAEYAAAAABoUAAAAAAAAeAHOACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEA
AAAAAAAAHgB0gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AdYAIIAYAAAAA
AMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAHuACCAGAAAAAADAAAAAAAAARgAAAACChQAA
AQAAAAsAfoALIAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwCAgAsgBgAAAAAAwAAAAAAAAEYA
AAAABYgAAAAAAAACAfgPAQAAABAAAAAD6DKfHOG+EY2g0sRy+UvZAgH6DwEAAAAQAAAAA+gynxzh
vhGNoNLEcvlL2QIB+w8BAAAAXwAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAA
AAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XEVpZ2VuZSBEYXRlaWVuXEpvY2hlblxNYWlsc1xqay5w
c3QAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDAzRTgzMjlGMUNFMUJFMTE4
REEwRDJDNDcyRjk0QkQ5RTQ2OTIwMDAAAAAANgI=

------=_NextPart_000_0001_01BEFDED.7140C820--



Received: from smtppop3.gte.net (smtppop3.gte.net [207.115.153.22]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA02090 for <[e-mail]>; Mon, 13 Sep 1999 04:32:36 -0700 (PDT)
Received: from gte.net (1Cust237.tnt10.alameda.ca.da.uu.net [63.10.112.237]) by smtppop3.gte.net  with ESMTP ; id GAA8485112 Mon, 13 Sep 1999 06:33:10 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 1999 04:33:25 -0700
From: Ed Gerck <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Laurie <[e-mail]>
CC: [e-mail], Stephen Kent <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ben Laurie wrote:

> Ed Gerck wrote:
> > Further, the major X.509 security application today, SSL, does not
> > check revocation lists -- so they are near to useless. Also, the user is
> > not able to check server certificates (and certificates in the CA chains)
> > against revocation lists.
>
> That depends on the implementation. It is entirely possible for an SSL
> implementation to check CRLs, and some do.

In SSL, the client knows which CAs are acceptable *to the server* for signature
validation and CRL verification because the server *sends* a list of distinguished
names in the "certificate request" message. However, there is no corresponding
list sent in the other direction in SSL (from the client to the server).  Thus,  the
server is essentially groping in the dark when trying to supply a certificate that
the client can check for its CRL, because the server is not informed by the client
what CAs to best aim for in a ranking list  (CAs that are directly trusted by the
client for signature and CRLs, untrusted CAs directly trusted by a CA that
the client trusts, etc.).

So,  SSL indeed does not offer a mechanism to allow clients to effectively check
CRLs for server certs.  Thus, as I commented, "the user is not able to check
*server certificates* (and certificates in the CA chains) against revocation lists"
-- BTW, as we can see in current browsers.

But, your remark does apply to client certs that are sent to the server and I am
thankful for your clarification.  The major use of SSL is however in securing
servers and in this case CRLs are oftentimes useless for clients.

BTW, my text was a segment from the paper "Overview of Certification Systems"
at http://www.mcg.org.br/certover.pdf -- and even though there the context of
users checking *server certificates* seems clear throughout, I will further clarify
it with your comment in mind.

Thanks,

Ed Gerck



Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA28386 for <[e-mail]>; Mon, 13 Sep 1999 02:31:50 -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 JAA01835; Mon, 13 Sep 1999 09:34: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 KAA18339; Mon, 13 Sep 1999 10:34:27 +0100
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 1999 10:34:16 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.6 [en-gb] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
CC: Stephen Kent <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed Gerck wrote:
> Further, the major X.509 security application today, SSL, does not
> check revocation lists -- so they are near to useless. Also, the user is
> not able to check server certificates (and certificates in the CA chains)
> against revocation lists.

That depends on the implementation. It is entirely possible for an SSL
implementation to check CRLs, and some do.

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 fgwmail3.fujitsu.co.jp (fgwmail3.fujitsu.co.jp [192.51.44.33]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA27654 for <[e-mail]>; Mon, 13 Sep 1999 01:26:32 -0700 (PDT)
Received: from m1.gw.fujitsu.co.jp by fgwmail3.fujitsu.co.jp (8.9.3/3.7W-MX9909-Fujitsu Gateway) id RAA25298; Mon, 13 Sep 1999 17:29:40 +0900 (JST)
Received: from vishnu.ec.cs.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-9909-Fujitsu Domain Master) id RAA21376; Mon, 13 Sep 1999 17:29:39 +0900 (JST)
Received: from ec.cs.fujitsu.co.jp ([10.34.199.168]) by vishnu.ec.cs.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.4W5-04/12/98 EC domain mail master) with ESMTP id RAA14726; Mon, 13 Sep 1999 17:29:39 +0900 (JST)
Message-ID: <[e-mail]>
Date: Mon, 13 Sep 1999 17:29:38 +0900
From: "Tamura, Takuya" <[e-mail]>
Organization: Devlpmnt Dept. II, Entrprs Midware Div., FUJITSU LIMITED
X-Mailer: Mozilla 4.6 [ja] (Win95; I)
X-Accept-Language: ja
MIME-Version: 1.0
To: [e-mail], Aram Perez <[e-mail]>
CC: [e-mail]
Subject: Re: New Internet Draft on Non-Repudiation Requirements
References: <[e-mail]>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

Hello Tom & Aram

Subject: Re: New Internet Draft on Non-Repudiation Requirements
   Date:Tue, 7 Sep 1999 11:26:30 -0400
   From: [e-mail]
     To:"Aram Perez" <[e-mail]>
     CC: [e-mail]
> 1.1  Definitions
> 
> 2-way NR: A service in which the relying party submits
> sufficient evidence to permit the verifier to perform a verification
> to a third party, known as the "escrow holder". [AP: I had to read
> this definition several times before understanding it. How about
>  defining escrow holder first and then defining 2-way NR as "A service
>  in which the r-p submits sufficient evidence to an escrow holder that
> allows a verifier to perform a verification at a later time."?]
> [TG: I'll wait to see if others are confused by 2-way vs. 1-way NR.  Your
> suggestion about order might be easier to understand and doesn't damage the
> meaning.]

  I was also confused when I read this definition for the first time.
  (This may be because I didn't know the word "escrow", though)

> Subject: Re: New Internet Draft on Non-Repudiation Requirements
>    Date: Tue, 07 Sep 1999 17:02:30 -0700
>    From: "Aram Perez" <[e-mail]>
>     To: PKIX <[e-mail]>
> [AP1: I think you need a better explanation of the differences between 1 and
> 2-way NR and why they are needed.]

 I would like to know what Aram wrote above.
 I didn't understand why 2 types of NR are necessary from the draft.
  (I'm reading this mailing list for about one month.
   Do I miss something?)

 Best Regards,
 Tak


Received: from smtppop1.gte.net (smtppop1.gte.net [207.115.153.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id XAA26220 for <[e-mail]>; Sun, 12 Sep 1999 23:14:39 -0700 (PDT)
Received: from gte.net (1Cust183.tnt12.alameda.ca.da.uu.net [63.10.214.183]) by smtppop1.gte.net  with ESMTP ; id BAA15763320 Mon, 13 Sep 1999 01:15:12 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Sun, 12 Sep 1999 23:15:59 -0700
From: Ed Gerck <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> >Revocation is one of the most critical problems that must be addressed and
> >tons of smart people are working on it.  Some of my team/partners/members are
> >spending nearly all of their time trying to make revocation work the way we
> >need it to work.   The financial services sector is providing significant
> >input on requirements, technology, and resources to try to make PKI work for
> >us.
> >
> >No offense intended, but the nature of our businesses and the limitations of
> >the technology do not lend themselves to the use of CRLs.  The how and why
> >will have to wait for a later message (tonight).
>
> Not all the world is the financial services sector.  Criticisms of CRL use
> models based primarily on difficulties encountered in employing them in
> that environment, or based on poor implementations, or based on poor
> management parameter choices, etc.  do not necessarily mean that CRLs are
> unworkable.

CRLs, which were first thought to be a positive aspect of relying on CAs
as compared to PGP for instance, presents several unsolvable problems.

For example, there may be a considerable delay (no warranties can be
found on on CAs contracts about upper limits for such delays) between the
actual need to revoke a certificate and the reflection of this need in a
certificate chain with different CAs.

Also, requiring the user to check with a CA before sending a message
makes the use of multiple CAs much more difficult, unless they can be
convinced to work together, an interesting problem for competing
businesses.  Constant checking with a single CA also makes traffic
analysis much easier. Even if the attacker cannot intercept the
message which is sent, if the attacker can monitor the central CA
(with a single administrative order and a GAKware system to circumvent
any encryption), everyone's communication patterns can be seen.
Also, an attacker can fool a CA into revoking a key -- a denial of service
attack.

Further, the major X.509 security application today, SSL, does not
check revocation lists -- so they are near to useless. Also, the user is
not able to check server certificates (and certificates in the CA chains)
against revocation lists.

An examplary case regarding  CRLs, is that they are a will to revoke but
not an actual revocation. Few recognize that CRLS are a solution to a
non-existent problem ... while the real problem is left utterly unsolved. The
non-existent problem solved by CRLs is how to communicate that a
certificate is no longer valid ... because if a certificate were really no
longer valid (as it should be) then no one would need to find a CRL
to know about it.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                    [e-mail]




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA16896 for <[e-mail]>; Sun, 12 Sep 1999 16:44:39 -0700 (PDT)
Received: from [128.33.238.90] (TC090.BBN.COM [128.33.238.90]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA18819; Sun, 12 Sep 1999 19:47:39 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a03b4002a7dc532@[128.89.0.111]>
In-Reply-To: <[e-mail]>
Date: Sat, 11 Sep 1999 11:52:36 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Huge CRLs
Cc: [e-mail], [e-mail]

>Revocation is one of the most critical problems that must be addressed and
>tons of smart people are working on it.  Some of my team/partners/members are
>spending nearly all of their time trying to make revocation work the way we
>need it to work.   The financial services sector is providing significant
>input on requirements, technology, and resources to try to make PKI work for
>us.
>
>No offense intended, but the nature of our businesses and the limitations of
>the technology do not lend themselves to the use of CRLs.  The how and why
>will have to wait for a later message (tonight).

Not all the world is the financial services sector.  Criticisms of CRL use
models based primarily on difficulties encountered in employing them in
that environment, or based on poor implementations, or based on poor
management parameter choices, etc.  do not necessarily mean that CRLs are
unworkable.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA16883 for <[e-mail]>; Sun, 12 Sep 1999 16:44:34 -0700 (PDT)
Received: from [128.33.238.90] (TC090.BBN.COM [128.33.238.90]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA18810; Sun, 12 Sep 1999 19:47:36 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a02b40025b21e3f@[128.89.0.111]>
In-Reply-To: <[e-mail]>
Date: Sat, 11 Sep 1999 11:48:47 -0400
To: Michael Versace <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re[2]: Huge CRLs
Cc: [e-mail], [e-mail]

Mike,

I think one encounters different perspectives on CRL use in different quarters.

For example,  I never suggest that ALL relying parties should try to fetch
ALL relevant CRLs frmo directories in conjunction with processing EVERY
blob of digitally signed data, establishing every secure connection, etc.
Instead, I usually suggest that an RP acquire certs and CRLs and cache them
locally.  Since CRLs have explicit lifetimes, one may often decide that
there is no need to see if a new (emergency) CRL has been issued before the
next scheduled issue date.

Not all uses of certificates involve NR, e.g., certs used in SSL and IPsec
for authentication and/or authorization, of for authentication in S/MIME.
In these environments one is already accustomed to some delay in
propogation of changes of authentication data.  Also, servers receiving
certs as part of a user authentication process may have especially good
access to the CRLs for those user certs, because they may be locally
issued, thus changing the complexion of CRL distribution dramatically.

In these contexts, claims that models for CRL use are unrealistic don't
strike me as valid.  Yes, I have heard others make unrealistic suggestions
re CRL use models. Everyone is free to make bad suggestions all the time;
we have to be selective in whose suggestions we pay attention to.

Steve


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA18191 for <[e-mail]>; Sat, 11 Sep 1999 11:54:28 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id LAA08961; Sat, 11 Sep 1999 11:55:25 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA04418; Sat, 11 Sep 1999 11:57:01 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <SF5SHAA3>; Sat, 11 Sep 1999 11:56:37 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: [e-mail]
Subject: Re: LAST CALL:draft-ietf-pkix-dhpop-01.txt
Date: Sat, 11 Sep 1999 11:56:31 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

There being no substantive comments in WG last call, this document has been
forwarded to the IESG with a recommendation for progression to Proposed
Standard.  Thanks to the Editors for their hard work.

Warwick

-----Original Message-----
From: Warwick Ford [mailto:[e-mail]] 
Sent: Friday, August 20, 1999 3:11 PM
To: '[e-mail]'
Subject: LAST CALL:draft-ietf-pkix-dhpop-01.txt


This document is brought to your attention for 14-day PKIX WG Last Call....

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, August 19, 1999 4:07 AM
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dhpop-01.txt


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

	Title		: Diffie-Hellman Proof-of-Possession Algorithms
	Author(s)	: H. Prafullchandra, J. Schaad
	Filename	: draft-ietf-pkix-dhpop-01.txt
	Pages		: 23
	Date		: 18-Aug-99
	
This document describes two methods for producing a signature from a
Diffie-Hellman key pair.  This behavior is needed for such
operations as creating a signature of a PKCS #10 certification
request.  These algorithms are designed to provide a proof-of-
possession rather than general purpose signing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-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-dhpop-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-dhpop-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.



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA00632 for <[e-mail]>; Fri, 10 Sep 1999 11:50:35 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id LAA09462; Fri, 10 Sep 1999 11:53:33 -0700 (PDT)
Received: from rsalaptop ([192.168.3.229]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id LAA21484; Fri, 10 Sep 1999 11:53:33 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Date: Fri, 10 Sep 1999 11:55:21 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>

> Since the certificate validation algorithm does not use
> certificate policy
> qualifiers, how do certificate policy qualifiers in CA certificates help
> the certificate user?


Every so often, I receive in my S/MIME client a msg originated
by someone belonging to a certification domain that
I neither know, or trust. In general, they are RFC 2459 complying
CAs, doing what RFC 2459 seeks.

The fact that I receive these  is probably based on the fact that
I co-authored an applied digital certificates book,
suggesting people go out and deploy RFC 2459 and SET
CAs (horror!): It  helped provide lots or practical know-how
enabling cheap experimental deployment using mass-market software. People
sometimes send me their results, proudly. (I rarely,
if ever, see their names on this list.)

Anyway, my S/MIME tool (which uses a well-known mass market
certificate manager tool and crypto library) enables me to
label the inbound certificates as trusted. I can learn a
root, if you like. Some of the CA certs are self-signed, some
are intermediate  CAs in a chain that does not happen to
include the TLCA for  their domains.

To decide to trust it, I inspect the certificate.  I,
and my "auditor" make an accreditation judgment on
its trustworthiness, much like CAs confirm the identify
and obligations of CAs during PKIX3-specified
cross-certification.

Acting much as a professional security administrator in any
large enterprise, I am as capable of taking this
accreditation decision as any commercial CA might do on
my behalf.

To finalize the decision, I sign a list of my
trusted roots which controls their use in my S/MIME client.
The signed trust list acts, effectively, as my personal CA
which controls inter-domain trust; conforming path
processing ensures both trusted interworking and
policy recognition during  S/MIME msg handling, when
I choose to use conforming rules. As per 2459, I
can turn off conforming rule processing, when
required.

What use are the qualifier? Russ asks.

During inspection, the CPS pointer identifies to
me the PEM-style policy elements which I used to evaluate
the trustworthiness of the domain, as recommended by
the designers of RFC 1422, whose basic ideas are incorporated
into RFC 2459 by charter directive.

In some cases, the certificate identifies
one or more certificate policies.  In other
cases it identifies one or more combined certificate policy
and CPSs. I have to wade through the various declarations to make my
decision deciding whether or not
to extend trust, given goals of my own security program.
The know-how to do this is about as complex as designing
for NR. I use the PKIX-IV recommendations to do this,
as one would expect.

I understand from friends in companies who
use other mass-market software, and who use the
other RFC 2459 qualifier which points to
Warwick Ford's (WG-ratified) scheme for locating
policy description fragments embedded in compound
documents, that they use that facility for purposes
similar to those that I described for the CA-cert
hosted URL.

So, if nothing else, CA qualifiers are very valuable
in the actual Internet PKI for learning trust-points,
and taking accreditation decisions based on evaluation
and recognition of policy. The use of explicit
accreditation is a well-established technique,
advised by reputable organizations such as NIST.

It is true that I never use certificate path processing
during this inspection and accreditation process; but then
path processing was not designed for, and is not
useful for, such an accreditation process. I would never
use mandatory access control lattice implementation when
accrediting a certified B2 OS product for use in my site,
either!

Hope this helps; its reality, and it works using at least
two different mass-market software implementations that work
largely according to the design and specification of RFC2459.
The scheme is voluntary and optional. Only those
interworking parties that recognize the (qualified) policy
are affected. Those that do not recognize the a (qualified)
policy, are  unaffected, if they use conforming implementations.

Therefore policy controls interworking by instrumenting
the accreditation, which is aided by the qualifiers, just as
one would expect. Much of the experience of NIST (and NSA)
is now implemented in the Internet PKI environment, supporting,
as is culturally required: autonomous operations, experimentation,
and multi-vendor implementations that interwork at least
a minimal level, and by default.

"I find qualifiers useful to provide exact information about certain policy
elements." [another]

Peter.



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA00268 for <[e-mail]>; Fri, 10 Sep 1999 11:37:40 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA19099; Fri, 10 Sep 1999 14:40:29 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id OAA19095; Fri, 10 Sep 1999 14:40:28 -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 OAA01729; Fri, 10 Sep 1999 14:40:12 -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 OAA05194; Fri, 10 Sep 1999 14:38:16 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 10 Sep 1999 14:38:16 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Re[2]: Huge CRLs
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: zc4SRsyNLhs4iGfP7GFNzA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

"Centers around one, impractical model"???

Perhaps you mean one impractical implementation.  A CRL is just an object
signed by a revocation authority listing the certs within a specific
scope that have been revoked.  If your CRLs are "Huge", perhaps your
scope needs to be narrowed.  If your window is too short, perhaps the
revocation authority's nextUpdate period needs to be tuned.  If you can't
find the right CRL in a directory, perhaps the schema needs adjusting,
or perhaps the CRL should be distributed via http or pushed with the
transaction rather than being looked up via LDAP.

Look at your requirements, look at the CRL object, and then ask yourself
what it is about the object that is preventing you from meeting the
requirements.  My guess is that you will find ... nothing.




> Date: Fri, 10 Sep 1999 13:48:43 -0400
> From: Michael Versace <[e-mail]>
> Subject: Re[2]: Huge CRLs
> To: [e-mail], [e-mail], [e-mail], 
[e-mail]
> Cc: [e-mail], [e-mail], [e-mail], [e-mail]
> 
>      Timing is important.  In payment systems, for example, there are 
>      certain time windows within which users can revoke authorization 
>      and processors can deny payment transactions.  Some payment systems 
>      have very short windows (fedwire), some have very long windows 
>      (checks, ACH, cards).
>      
>      It seems that most theoretical talk about CRLs centers around one, 
>      impractical model, as Kawika points out.  That is - as soon as I 
>      get a cert in a transaction, I need to immediately determine if it 
>      is fresh.  Building infrastructure to support new business 
>      practices 
>      like this are difficult to justify.
>      
>      Public key, no infrastructure, yet
>      
>      Mike Versace
> 
> 
> ______________________________ Reply Separator 
_________________________________
> Subject: Re: Huge CRLs 
> Author:  <[e-mail]> at Internet
> Date:    9/10/99 10:29 AM
> 
> 
> Good point!
> But...
> CRLs in any form are a fundamentally inadequate approach to solving practical 
> problems and in most cases cannot meet business requirements for even small 
> scale infrastructures.  CRLs were a good idea when the terribly impractical 
> people who developed them were working on paper and not such a great idea 
> when you have to turn paper into production systems.   CA revocations 
> experiments done on practical deployments (real world machines, apps, and 
> users) of even small PKIs will demonstrate that complying with your own 
> policy won't happen in the real world if you base your revocation hopes on 
> CRLS.
> Why are you messing with them?
>      
> ..kawika daguio...
>      
> 



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29813 for <[e-mail]>; Fri, 10 Sep 1999 11:17:35 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA09018 for <[e-mail]>; Fri, 10 Sep 1999 11:13:55 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 10 Sep 1999 14:17:25 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Certificate Polilcy Criticality
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

An update to X.509 is presently being balloted.  This update fixes defects 
that have been identified.  One of these defects is the certificate policy 
mapping that was discussed at the IETF Meeting in Oslo. The X.509 update 
handles all certificate policy extensions in the same manner (whether they 
are marked critical or non-critical).

I suggest that the Internet PKI Profile be updated to always mark 
certificate policy extensions as critical.  This will ensure the correct 
behavior by all implementations.  Old implementations that do not know 
about the update will naturally handle the certificate policy extensions as 
critical because they are marked critical.

Any concerns?

Russ


Received: from imo22.mx.aol.com (imo22.mx.aol.com [198.81.17.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29540 for <[e-mail]>; Fri, 10 Sep 1999 11:06:39 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo22.mx.aol.com (mail_out_v22.4.) id 3JHMa06600 (4257); Fri, 10 Sep 1999 14:08:31 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 10 Sep 1999 14:08:30 EDT
Subject: Re: Huge CRLs
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 21

Thanks Steve,

I will reply with specifics (technical) tonight.  Thanks for not ignoring me 
because  of the *.aol.com thing (I am stuck using my family AOL account 
because 3 of my servers (and domains) are often down (my ISP is killing me 
and I will return the favor when I return to home base) and AOLmailservers 
are never down.

I work closely with some of the earliest commercial x509 players and some of 
the folks who have done early implementations (govt and commercial pkis) and 
most of them freely acknowledge that the practical requirements and 
approaches necessary to practice policy compliant PKI in a realworld setting 
is nothing like their early imaginings [zero criticism applicable].   The 
true test of brilliant ideas is not whether they are implemented and built 
into practical life as a whole and as originally imagined, but that they 
become relied upon parts of production systems in practical applications.  
Everyone involved in the early days has contributed a lot of time, money, 
great ideas, and technology.  To a person they should feel good about their 
work.  Foresight cannot be 20 20 and no one can be blamed for vision issues 
that could not be anticipated.

However, having architected and directed implementation of infrastructure and 
enterprise PKIs and after stress testing most of the technology solutions, I 
am comfortable saying that it is often quite difficult and in some cases 
practically infeasible to make the technology solutions support business and 
policy requirements.  This must change and I am confident that it will if 
people and companies are open to customer input and innovation.  

Revocation is one of the most critical problems that must be addressed and 
tons of smart people are working on it.  Some of my team/partners/members are 
spending nearly all of their time trying to make revocation work the way we 
need it to work.   The financial services sector is providing significant 
input on requirements, technology, and resources to try to make PKI work for 
us.

No offense intended, but the nature of our businesses and the limitations of 
the technology do not lend themselves to the use of CRLs.  The how and why 
will have to wait for a later message (tonight).

...kawika daguio...


Received: from fed-ef1.frb.gov ([e-mail] [132.200.32.32]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA28973 for <[e-mail]>; Fri, 10 Sep 1999 10:48:33 -0700 (PDT)
Received: by fed-ef1.frb.gov; id NAA28797; Fri, 10 Sep 1999 13:51:15 -0400 (EDT)
Received: from m1pmdf.frb.gov(192.168.3.38) by fed.frb.gov via smap (V4.2) id xmaa28072; Fri, 10 Sep 99 13:50:26 -0400
Date: Fri, 10 Sep 1999 13:48:43 -0400
From: Michael Versace <[e-mail]>
Subject: Re[2]: Huge CRLs
To: [e-mail], [e-mail], [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: ccMail Link to SMTP R8.31.00.5
Content-type: text/plain; charset=US-ASCII
Content-description: "cc:Mail Note Part"
Content-transfer-encoding: 7bit

     Timing is important.  In payment systems, for example, there are 
     certain time windows within which users can revoke authorization 
     and processors can deny payment transactions.  Some payment systems 
     have very short windows (fedwire), some have very long windows 
     (checks, ACH, cards).
     
     It seems that most theoretical talk about CRLs centers around one, 
     impractical model, as Kawika points out.  That is - as soon as I 
     get a cert in a transaction, I need to immediately determine if it 
     is fresh.  Building infrastructure to support new business 
     practices 
     like this are difficult to justify.
     
     Public key, no infrastructure, yet
     
     Mike Versace


______________________________ Reply Separator _________________________________
Subject: Re: Huge CRLs 
Author:  <[e-mail]> at Internet
Date:    9/10/99 10:29 AM


Good point!
But...
CRLs in any form are a fundamentally inadequate approach to solving practical 
problems and in most cases cannot meet business requirements for even small 
scale infrastructures.  CRLs were a good idea when the terribly impractical 
people who developed them were working on paper and not such a great idea 
when you have to turn paper into production systems.   CA revocations 
experiments done on practical deployments (real world machines, apps, and 
users) of even small PKIs will demonstrate that complying with your own 
policy won't happen in the real world if you base your revocation hopes on 
CRLS.
Why are you messing with them?
     
..kawika daguio...
     



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA26718 for <[e-mail]>; Fri, 10 Sep 1999 08:10: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 LAA26065; Fri, 10 Sep 1999 11:12:48 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a09b3fecd06a6b2@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Fri, 10 Sep 1999 11:03:06 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Huge CRLs
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]

I think your message would be better received if you cited specific
technical reasons for criticizing CRLs, rather than the broad statements
you made dispoaraging them and the authors of X.509.

For example, I might be tempted to say that one should never pay attention
to messages from folks who have AOL mailbox addresses, since they are
probably technical illiterates, but that would be an inappropriate and
unsubstantiated comment.


Received: from kekec.e5.ijs.si (IDENT:[e-mail] [193.138.1.2]) by mail.proper.com (8.9.3/8.9.3) with SMTP id HAA26191 for <[e-mail]>; Fri, 10 Sep 1999 07:39:30 -0700 (PDT)
From: [e-mail]
Received: (qmail 1059 invoked by uid 507); 10 Sep 1999 14:42:24 -0000
Message-ID: <[e-mail]>
Subject: Re: End-Entity Certificate Policies
To: [e-mail] (Russ Housley)
Date: Fri, 10 Sep 1999 16:42:24 +0200 (CEST)
Cc: [e-mail]
In-Reply-To: <[e-mail]> from "Russ Housley" at Sep 09, 1999 02:00:22 PM
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Few thoughts about this subject...
 
> First, I have been convinced that there are times when it is appropriate to 
> include more than one certificate policy OID in an end 
> entity-certificate.  However, it is clear to me that some policies should 
> not be combined in one certificate.  I guess that there are many errors 
> that a CA could make, and that this is just one more.  Can anyone suggest a 
> subjective rule for the types of policies that might appear in one 
> end-entity certificate?  If not, how about a subjective rule for the types 
> of policies that should not appear in one end-entity certificate?

I think you can include every type of certificate policies, as long as
they are not in contradiction. A comparison of policies or verification that
they are not in contradiction is not an easy task, but must be done by a CA.
Even one policy can have contradicting rules, and must be carefully checked.
 

> While the X.509 path validation algorithm does not prohibit an 
> implementation from returning information that tells which certificate 
> provided particular qualifiers, the algorithm does not require that this 
> information be provided.  Therefore, we must assume that this information 
> is not available to the certificate user.
> 
> I still think that it is important that the set of certificate policy 
> qualifiers not include contradictions.
> 
> I belive that it is possible that two CAs can support the same certificate 
> policy using different CPSs.  Thus, certificates issued by the two CAs 
> would have the same certificate policy OID, but they would include 
> different values for the CPS pointer qualifier.  If a path includes 
> certificates from both of these CAs, the output of the certificate path 
> validation algorithm would include the common certificate policy OID and 
> two different CPS pointer qualifiers.
 
Qualifiers do not change the meaning of the policies, so I don't see the 
problem if you have a single policy and two CPSs that support this policy. 
CPSs can't be in contradiction if they support the same policy, that specifies
the rules and is the basis for evaluation of certificates. 

I find qualifiers useful to provide exact information about certain policy 
elements. CAs or other policy authorities specify (in advance) in the policy 
minimum requirements or conditions that must be met, for example minimal key 
storage quality or minimal identity verification procedures. These requirements 
do not change over time. However, with qualifiers you can include exact values 
of some elements at the time the certificate is issued, which can provide more 
information to end users for an evaluation of certificates or comparison with 
their personal security policy. Am I wrong?

Regards, Tomaz 




Received: from imo27.mx.aol.com (imo27.mx.aol.com [198.81.17.71]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA25902 for <[e-mail]>; Fri, 10 Sep 1999 07:28:00 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo27.mx.aol.com (mail_out_v22.4.) id xWVUa01404 (4183); Fri, 10 Sep 1999 10:29:57 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 10 Sep 1999 10:29:55 EDT
Subject: Re: Huge CRLs
To: [e-mail], [e-mail], [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 21

Good point!
But...
CRLs in any form are a fundamentally inadequate approach to solving practical 
problems and in most cases cannot meet business requirements for even small 
scale infrastructures.  CRLs were a good idea when the terribly impractical 
people who developed them were working on paper and not such a great idea 
when you have to turn paper into production systems.   CA revocations 
experiments done on practical deployments (real world machines, apps, and 
users) of even small PKIs will demonstrate that complying with your own 
policy won't happen in the real world if you base your revocation hopes on 
CRLS.
Why are you messing with them?

...kawika daguio...


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA24888 for <[e-mail]>; Fri, 10 Sep 1999 06:14:12 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA01897 for <[e-mail]>; Fri, 10 Sep 1999 06:10:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 09 Sep 1999 14:00:22 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: End-Entity Certificate Policies
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I want to send a quick message to summarize the impact that this thread has 
had on my thinking.  This thoughts have not been coordinated with the other 
RFC 2459 authors.

First, I have been convinced that there are times when it is appropriate to 
include more than one certificate policy OID in an end 
entity-certificate.  However, it is clear to me that some policies should 
not be combined in one certificate.  I guess that there are many errors 
that a CA could make, and that this is just one more.  Can anyone suggest a 
subjective rule for the types of policies that might appear in one 
end-entity certificate?  If not, how about a subjective rule for the types 
of policies that should not appear in one end-entity certificate?

Second, I remain concerned about the use of qualifier with certificate 
policies in CA certificates.

The certificate policy qualifiers do not impact the certificate path 
validation algorithm.  Rather, the certificate policy qualifiers are 
provided as an output of the algorithm to the certificate user (a.k.a. 
relying party) to help determine whether or not the end-entity certificate 
is appropriate for the task at hand.

While the X.509 path validation algorithm does not prohibit an 
implementation from returning information that tells which certificate 
provided particular qualifiers, the algorithm does not require that this 
information be provided.  Therefore, we must assume that this information 
is not available to the certificate user.

I still think that it is important that the set of certificate policy 
qualifiers not include contradictions.

I belive that it is possible that two CAs can support the same certificate 
policy using different CPSs.  Thus, certificates issued by the two CAs 
would have the same certificate policy OID, but they would include 
different values for the CPS pointer qualifier.  If a path includes 
certificates from both of these CAs, the output of the certificate path 
validation algorithm would include the common certificate policy OID and 
two different CPS pointer qualifiers.

Since the certificate validation algorithm does not use certificate policy 
qualifiers, how do certificate policy qualifiers in CA certificates help 
the certificate user?

Russ


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA23335 for <[e-mail]>; Fri, 10 Sep 1999 03:53:04 -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 GAA27537; Fri, 10 Sep 1999 06:55:30 -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-roadmap-03.txt
Date: Fri, 10 Sep 1999 06:55:30 -0400
Sender: [e-mail]

--NextPart

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

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA19964 for <[e-mail]>; Fri, 10 Sep 1999 02:53:48 -0700 (PDT)
Received: from nec.oleane.com  (dyn-1-1-210.Cor.dialup.oleane.fr [62.161.8.210])  by s2.smtp.oleane.net  with SMTP id LAA85004 for <[e-mail]>; Fri, 10 Sep 1999 11:56:44 +0200 (CEST)
Message-ID: <023c01befb72$f1c64920$[e-mail]>
From: "Peter lewis" <[e-mail]>
To: <[e-mail]>
Subject: From Firewall to IPSec VPNs
Date: Fri, 10 Sep 1999 11:57:47 +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

Security services and protection mechanisms
IPv6 promises regarding IPSec
Certification infrastructure 
Standardization update
Case Studies: ISPs, carriers, private networks
AH and ESP protocols description
Possible future extensions and modifications of the IKE protocol
Complementarity between IPSec and firewalls
Global Site-to-Site IPSec VPN's with End-to-End SLA's
Managing widespread IPSEC virtual private networks
Solving IPSec VPNs scalability
Results of some interoperability tests
IPSec architectures and non-standardized aspects of IPSec
Adding IPSec VPN functions in an existing router network
Impact of fragmentation on the performance of IPSec coding

IPSEC 99 Conference
>From Firewall to IPSec VPNs

October 26, 27, 28, 29, 1999
Paris - France

More infos: www.upperside.fr/baipsec.htm

Sorry to post this message on the list.

Thanks





Received: from bbmail1.unisys.com (bbmail1.unisys.com [192.63.108.35]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA02375 for <[e-mail]>; Thu, 9 Sep 1999 12:38:06 -0700 (PDT)
Received: from trsvrbk.tr.unisys.com (trsvrbk.tr.unisys.com [192.63.236.1]) by bbmail1.unisys.com (8.8.5/8.8.5) with ESMTP id TAA28633; Thu, 9 Sep 1999 19:40:00 GMT
Received: from us-tr-exch-2.tr.unisys.com by trsvrbk.tr.unisys.com (8.8.5/8.8.5) id TAA19623 ; Thu, 9 Sep 1999 19:39:35 GMT
Received: by us-tr-exch-2.tr.unisys.com with Internet Mail Service (5.5.2448.0) id <RZZAW2A1>; Thu, 9 Sep 1999 15:37:42 -0400
Message-ID: <8E37550684B3D211A20B0090271EC59D026761CE@TR-EXCHANGE-1>
From: "Salter, Thomas A" <[e-mail]>
To: =?iso-8859-1?Q?Martin_Lindstr=F6m?= <[e-mail]>, [e-mail]
Subject: RE: Huge CRLs
Date: Thu, 9 Sep 1999 15:37:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA02377

See RFC 2459, sec. 3.3:
   An entry is added to the CRL as part of the next update
   following notification of revocation. An entry may be removed from
   the CRL after appearing on one regularly scheduled CRL issued beyond
   the revoked certificate's validity period.

 > -----Original Message-----
 > From: Martin Lindström [mailto:[e-mail]]
 > Sent: Thursday, September 09, 1999 10:53 AM
 > To: [e-mail]; [e-mail]
 > Cc: [e-mail]; [e-mail]; [e-mail];
 > [e-mail]
 > Subject: Huge CRLs
 > 
 > 
 > 
 > I have been searching the PKIX RFCs and X.509 standard for
 > a text that mandates something like:
 > "A certificate that has revoked should only have an entry in a
 >  CRL as long as its validity period indicates that it has not
 >  expired"
 > ...but I haven't been able to find it.
 > 
 > Given the problem with CRL scalability, things get even worse
 > if some CAs issue CRLs with entries that point at already invalid
 > certificates. If a system needs the possibility to verify 
 > certificates
 > back in time, shouldn't the CRLs be archived instead of getting
 > larger and larger?
 > 
 > Comments?
 > 
 > /Martin Lindström
 > 
 > ______________________________________
 >          Entegrity Solutions
 > 
 >   Martin Lindström
 >   Systems Designer 
 > 
 >   Finlandsgatan 60 
 >   S-164 74 Kista, Sweden
 >   Direct: [phone]
 >   Fax:    [phone]
 >   Cell:   [phone]
 > ______________________________________
 > 


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA01504 for <[e-mail]>; Thu, 9 Sep 1999 11:37:03 -0700 (PDT)
Received: by balinese.baltimore.ie; id TAA11163; Thu, 9 Sep 1999 19:39:54 +0100 (GMT/IST)
Received: from bobcat.irl.emea(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma011150; Thu, 9 Sep 99 19:39:19 +0100
Received: from sage.baltimore.ie (IDENT:[e-mail] [192.168.21.125]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id TAA04371 for <[e-mail]>; Thu, 9 Sep 1999 19:39:18 +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 UAA04609 for <[e-mail]>; Thu, 9 Sep 1999 20:39:19 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Huge CRLs 
Date: Thu, 09 Sep 1999 20:39:19 +0100
From: Keith Brady <[e-mail]>

 "Martin" == Martin Lindström <[e-mail]> writes:

Martin> certificates. If a system needs the possibility to verify
Martin> certificates back in time, shouldn't the CRLs be archived instead
Martin> of getting larger and larger?

Unfortunately, of course one can end up with an ever increasing collection
of CRLs. I believe the reason the behaviour is unspecified is that it is
left up to the CA policy to decide what it does with expired certs in this
case. I believe most current implementations act as you suggest.

Worse is that, arguably, one would have a multi-valued CRL attribute in a
directory with the historical CRLs retained there but no way of selecting
only the attribute value corresponding to the current CRL. This would, of
course cause the same problem that excluding expired certs was meant to
solve.


cheers,

Keith

--
Keith Brady,                                    Phone: [phone] 
Baltimore Technologies,                           Fax: [phone]
61-62 Fitzwilliam Lane,                      <http://www.baltimore.com>
Dublin 2, Ireland

--
Company Standard Disclaimer
--------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorised use, disclosure, copying or alteration of this message is
strictly forbidden. This message and any attachments have been scanned for
viruses. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus
being passed on.
--------------------------------------------------------------------------


Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA28005 for <[e-mail]>; Thu, 9 Sep 1999 07:49:24 -0700 (PDT)
Received: from roger (roger.cost.se [10.0.0.31]) by marcellus.cost.se (8.9.3/8.9.3) with SMTP id QAA22378; Thu, 9 Sep 1999 16:51:38 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 09 Sep 1999 16:53:10 +0200
To: [e-mail], [e-mail]
From: Martin Lindström <[e-mail]>
Subject: Huge CRLs
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

I have been searching the PKIX RFCs and X.509 standard for
a text that mandates something like:
"A certificate that has revoked should only have an entry in a
 CRL as long as its validity period indicates that it has not
 expired"
...but I haven't been able to find it.

Given the problem with CRL scalability, things get even worse
if some CAs issue CRLs with entries that point at already invalid
certificates. If a system needs the possibility to verify certificates
back in time, shouldn't the CRLs be archived instead of getting
larger and larger?

Comments?

/Martin Lindström

______________________________________
         Entegrity Solutions

  Martin Lindström
  Systems Designer 

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


Received: from ns.koscom.co.kr (ns.koscom.co.kr [128.134.148.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA10503 for <[e-mail]>; Wed, 8 Sep 1999 19:20:15 -0700 (PDT)
Received: from drk ([128.134.151.25]) by ns.koscom.co.kr (8.9.1/8.9.1) with SMTP id LAA26815 for <[e-mail]>; Thu, 9 Sep 1999 11:18:20 +0900 (KST)
Message-ID: <00e801befa6a$225c3c20$[e-mail]>
From: "=?euc-kr?B?sei/7Mf2?=" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Thu, 9 Sep 1999 11:22:15 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E5_01BEFAB5.92024740"
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

This is a multi-part message in MIME format.

------=_NextPart_000_00E5_01BEFAB5.92024740
Content-Type: text/plain;
	charset="euc-kr"
Content-Transfer-Encoding: base64

dW5zdWJzY3JpYmUNCg0K

------=_NextPart_000_00E5_01BEFAB5.92024740
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz
X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjAwLjIzMTQuMTAwMCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFkgYmdDb2xv
cj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+dW5zdWJzY3JpYmU8L0ZPTlQ+PC9ESVY+DQo8
RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo=

------=_NextPart_000_00E5_01BEFAB5.92024740--



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA22531 for <[e-mail]>; Wed, 8 Sep 1999 05:47:14 -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 OAA11695; Wed, 8 Sep 1999 14:49:49 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 08 Sep 1999 14:50:09 +0200
To: Russ Housley <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Cc: [e-mail]
In-Reply-To: <[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 FAA22533

Russ,

We mean almost the same thing, I give some comments though:

At 10:32 AM 9/7/99 -0400, you wrote:
>Stefan:
>
> >>Single Certificate Policy OID
> >>
> >>When an end-entity certificate contains more than one certificate policy
> >>OID, there is ambiguity about the intent of a signer.  On the other hand,
> >>if the end-entity certificate contains only one certificate policy OID,
> >>there is no ambiguity.  If an end-entity certificate contains two policies,
> >>one that says the certificate id for use with non-binding e-mail and
> >>another that says the certificate is intended for purchases up to $10,000,
> >>then it is not clear the signer intends when a signature is generated.
> >
> >This is to me a bad way to view certificate policies. Certificate Policies
> >are assertions by the CA to relying parties. It is NOT an assertion by the
> >signer. When a signer signs a message, the intention of the signer is only
> >expressed in that message, not in any certificate.
>
>Certificate policies are defined in X.509, Section 3.3.5.  Is says: "A 
>named set of rules that indicates the applicability of a certificate to a 
>particular community and/or class of application with common security 
>requirements. For example, a particular certificate policy might indicate 
>applicability of a type of certificate to the authentication of electronic 
>data interchange transactions for the trading of goods within a given price 
>range."
>
>So, what do these words mean?  They do not seem to exclude any of the 
>parties: the CA, the subject, and the certificate user (a.k.a. relying party).
>

Yes, but whatever it says about anyone, it is still an assertion by the CA
and not by the signer of the message.

> >Even if there are many certificates out there for the signers public key,
> >the signer goes free of liability for any "bad" certificate. And if some of
> >these certificates has ambiguous policy OIDs, that says nothing about the
> >signers intent. It just points out a bad CA and that CA may get into
trouble.
>
>In my view, the certificate user should reject a transaction that is 
>associated with an inappropriate certificate policy.  The certificate user 
>states which certificate policies are acceptable for the pending 
>transaction in the initial-policy-set input to the certificate path 
>validation algorithm.  If the path does not support this policy or 
>policies, then validation fails.  Further, a set of certificate policy 
>qualifier is returned for each valid policy.  These qualifiers are supposed 
>to help the certificate user determine if a valid path is appropriate for 
>the specific transaction at hand.

I agree to all of this.

>
> >What you are talking about seams to be more appropriate for signature
> >policies, which would be asserted by the signer.
>
>We do not have such a thing....

No but others define it. ETSI is defining a structure for a electronic
signature policy in their signature standard. The fact is that this would
be an assertion by the signer, while the certificate policy, by inclusion
in the certificate, is an assertion by the CA.

>
> >>One solution for this problem is specified in  RFC 2634, Section 5.4
> >>(Signing Certificate Attribute Definition).  Here, the signer can state the
> >>policy that was intended at the time the signature is generated.  Other
> >>protocols that use the PKIX Certificate Profile do not have similar
> >>mechanisms.
> >
> >With all respect to the attacks expressed in section 5, any attempt to
> >solve this by having the signer assert appropriate certificate content, is
> >to address the issue from the wrong angle. These attacks do in the first
> >place assume that a relying party trusts any bad CA.
> >
> >If that is so (i.e. the relying parties trust hierarchy is broken) or a CA
> >within that trust hierarchy is bad. Then there are so many other potential
> >problems, that you basically are sucked any way.
> >
> >These problems must be treated by each relying party by having working
> >trust models originating from trusted roots. If you have that, then you are
> >fixing non-existing problems. If you don't have that, you can't fix
> >anything anyway.
>
>I grant you that some of the attacks are a result of a certificate user 
>trusting a "bad" CA.  However, if the same public key is in more than one 
>certificate, similar issues arise.  This provides a mechanism for the 
>signer to assert which of those certificates should be used to validate the 
>message.  (Using a different public key in each certificate is even better.)
>

I think you are wrong here, As long as relying parties have working trust
models and as long as they know what issuing CA:s, or other characteristics
of a certificate, they require for acceptance of the certificate, there is
absolutely no threat arising from the fact that there are other
certificates out there of other types, certifying the same key.

If this would be a real threat, then that would be the same as saying that
no CA can have control over the reliability in their issued certificates,
since they don't have control over other CA:s issuing certificates for the
same keys.

The only simple and general mechanism that can work here is to recognize
the responsibility of the relying party to determine if a certain
certificate is appropriate for the intended usage. If this is so, then no
one will have to worry about if there are other certificates out there as well.

Trying to twist this around by having the signer to assert the appropriate
certificate, will add a new dimension of trust with new endless "if-based"
requirements.

> >>I understand the desires expressed by Mack Hicks and Dave Solo for multiple
> >>certificate policy OIDs in a certificate.  And, I can imagine environments
> >>where there would not be a problem with this practice.  Perhaps we need
> >>some guidance about when it is acceptable and when it is not.
> >
> >many OIDs are acceptable. The CA must however make sure that no certificate
> >contains conflicting policies. But I hope all CAs understand that.
>
>By including multiple OIDs in a certificate, the CA is stating that the 
>certificate was issues in accordance with each of the policies.  If the 
>certificate policy states a particular use, then the certificate is 
>appropriate for that use.  If the certificate policy states a particular 
>means of validating identity, then that means was used.
>

Agreed.

> >>Limiting Certificate Policy Qualifiers to End-Entity Certificates
> >>
> >>A review of the certificate path validation algorithm shows that one of
> >>it's outputs is a set of certificate policy qualifiers.  X.509-1997 says
> >>that a successful validation returns "a set of policies constrained by the
> >>CAs in the certification path, together with all qualifiers for these
> >>policies encountered in the certification path."
> >>
> >>This means that the certificate user cannot tell which qualifier goes with
> >>which certificate in the path.  Rather, an unordered set of the qualifiers
> >>is provided. Since the purpose of qualifier is to provide additional policy
> >>information to the certificate user (a.k.a. the relying party), it seems
> >>important that the set of qualifiers not provide
> >>contradictions.  Especially in the case of the qualifiers specified in RFC
> >>2459.
> >
> >I believe you read X.509 wrong here. The full text of that section
continues:
> >
> >"Unless any-policy is returned, the certificate user shall ONLY use the
> >certificate in accordance with ONE of the identified policies and shall
> >process all qualifiers for THAT policy present in the certification path."
> >
> >Now how is that possible if you return an un-ordered set of the qualifiers,
> >not related to their associated policies.
>
>The algorithm gathers the qualifiers associated with each certificate 
>policy as it processes the path.  The algorithm returns a set of valid 
>certificate policies and a set of qualifiers for each of those certificate 
>policies.  I do not see anything in the algorithm that keeps a binding 
>between the qualifiers and the certificates that provided them.
>

Does it have to state that explicitly? The PolicyInformation object carried
in the certificate policies extension contains the policy OID together with
the qualifier.

Obviously you must accept at least one of the policies in the EE
certificate. I would suggest then that it is the qualifier in that
EE-certificate that are to be examined and accepted, thus eliminating this
problem of interpreting the output of the path algorithm.

In this case qualifiers in CA-certificates are never used in path
validation, but may be used in other situations, e.g. when only examining a
CA-certificate or a cross certificate pair.

> >The path processing algorithm does further not use separate variables for
> >policies and for qualifiers. A reasonable interpretation of the algorithm,
> >given these facts, must be that all policy objects in the process is
> >handled together with their associated qualifiers, and thus should be
> >presented that way in the output.
>
>I think we just said the same thing.  There is no binding.  A certificate 
>may provide multiple qualifiers, or it could provide one, or it could 
>provide zero.  Can't tell by the output of the algorithm.
>
> >Your interpretation must be wrong here, or do you have an installed base of
> >softwares to back your view?
>
>I do not think that there is any installed base backs any 
>view.  Certificate policy handling is absent in most certificate using 
>applications and primitive in the rest.  CAs may be more advanced, but you 
>cannot really tell given the state of certificate using applications.
>
> >>Mike Myers suggests that CA certificates should be permitted to include the
> >>CPS pointer qualifier.  Let's assume that there is a simple path of two
> >>certificates, the CA certificate and the end-entity certificate.  The CA
> >>certificate has two certificate policy OIDs, each with a CPS pointer
> >>qualifier.  The end-entity certificate has a single certificate policy OID,
> >>also with a CPS pointer qualifier.  When the certificate path validation
> >>algorithm is executed, one of the outputs will be the certificate policy
> >>OID that is common to both certificates and the two qualifiers (one from
> >>the CA certificate and one from the end-entity certificate).  What is the
> >>certificate user expected to do?  If the URLs are different, the
> >>certificate user really has no idea what to do.
> >
> >See above +
> >This example suggest that a CA issue a certificate under two different
> >CPSs, That seams to be a false case.
> >
> >If there would be a guideline it should say that a certificate may include
> >many policy OIDs but should only indicate one CPS. One CPS may very well
> >reflect multiple policies.
>
>I belive that it is possible that two CAs can support the same certificate 
>policy using different CPSs.  This certificates issued by the two CAs would 
>have the same OID but a different CPS pointer.  Now, if one CA issues a 
>certificate to the other, the resulting path to an end-entity will have one 
>certificate policy OID throughout, but two different CPS pointer qualifiers.
>
>Russ

I still believe this is illegal in some way, but anyway...
the relying party should use the CPS pointer included in the EE-certificate
qualifier when validating the EE-certificate.

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

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


Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA09104 for <[e-mail]>; Tue, 7 Sep 1999 16:59:50 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id RAA16251 for <[e-mail]>; Tue, 7 Sep 1999 17:02:34 -0700 (PDT)
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 07 Sep 1999 17:02:30 -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 RAA09624 for <[e-mail]>; Tue, 7 Sep 1999 17:02:30 -0700 (PDT)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 07 Sep 1999 17:02:30 -0700
Subject: Re: New Internet Draft on Non-Repudiation Requirements
From: "Aram Perez" <[e-mail]>
To: PKIX <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Tom,

My comments are bracketed with [AP1: comments].

[snip]
> 
> ABSTRACT
>
> This document describes those features of a service which processes
> signed doucments which must be present in order for that service to
> constitute a "technical non-repudiation" service.  A technical
> non-repudiation service must permit an independent verifier to
> determine whether a given signature was applied to a given data object
> by the private key associated with a given valid certificate, at a time
> later than the signature.  The features of a technical non-repudiation
> service are expected to be necessary for a full non-repudiation service,
> although they may not be sufficient.
> [AP: You've defined a "'technical non-repudiation' service", but not a "full
> non-repudiation service". I'll use the acronym "TNR" for technical
> non-repudiation and "FNR" for full non-repudiation.]
>
> This document is intended to clarify the definition of the
> "non-repudiation" service in RFC 2459.  It should thus serve as a guide
> to when the nonRepudiation bit of the keyUsage extension should be used
> [AP: We should be consistent with either "nonrepudiation" or
"non-repudiation".
> Also, does "used" mean the same thing as "set"?]
> [TG: "when the nonRepudiation bit should be used" could easily be "... set"
> without any real change in meaning.]
> and to when a Certificate Authority is required to archive CRL's.
> [AP: Does the CA only have to archive CRL's for TNR? Does the CA need to
perform
> a higher due diligence before setting the NR bit? Can the CA set the NR bit
> without the subject requesting that the bit be set?]
> [TG: It is stated above, that FNR incorporates TNR as a core set of
> requirements.  Thus, CRL archiving is only directly mandated for TNR - but
that
> mandates it for FNR as well.]

[AP1: Above you state that TNR is "expected to be necessary" for FNR. This
is different from "FNR incorporates TNR as a core set of requirements". Is
it SHOULD or MUST? Like I commented before, you defined TNR but not FNR.]

> [TG: Higher levels of due diligence are probably needed for FNR.  I doubt if
> they are needed for TNR.]
> [TG: The CA can set the bit if it wishes.  This service does not have the kind
> of heavy-duty legal requirements that FNR is likely to.]

[AP1: So my abuelita (grandmother) may get a cert with the NR bit set
without her requesting it or knowing what it means and inadvertently sell
her house? ]

>
> 1 Introduction
>
> RFC 2459 [1] specifies a bit within the KeyUsage extension called the
> nonRepudiation bit which is "asserted when the subject public key is
> used to verify digital signatures used to provide a non-repudiation
> service which protects against the signing entity falsely denying some
> action, excluding certificate or CRL signing."  Extensive discussions
> in the PKIX WG have revealed that the description of the non-repudiation
> service contained in this passage is not widely enough understood or
> agreed upon to characterize any given service as providing or not
> providing a non-repudiation service.  Two major categories of service
> have been proposed as potentially providing a non-repudiation service:
> the technical non-repudiation service, which this draft attempts to
> define with greater precision, and a full non-repudiation service
> which is intended to prevent all possible repudiations of a signed
> object or document.  Since a full non-repudiation service is required
> to meet all the requirements of this technical non-repudiation service
> as a prerequisite, the technical non-repudiation service's definition
> is necessary for both [AP: I disagree if you require the NR bit to be set].
> [TG: I'm not defining FNR here.  An FNR set of requirements is likely to
define
> a needed keyPurpose ID in the XKU extension, anyway.  My question is whether
you
> and the other FNR supporters believe that there needs to be some indication in
> the certificate that a given certificate is intended for NR or FNR use.]

[AP1: Wow, I didn't know I was an "FNR supporter" ;-)  When you state
"intended for NR or FNR use" does "NR" mean "TNR"? I can't speak for the
other "FNR supporters", but what I believe is that you can have legally
binding digital signatures that do not have the NR bit set.]

[snip]
> , that the signer has been adequately informed of the content which is signed,
> that the signer is not acting
> under duress, etc. [AP: I think the scope should only include when the NR bit
is
> set, but clearly state that you can have FNR with the NR bit not set (as have
> been stated in the WG).][TG: That is fairly controversial in the WG, and I'm
not
> doing the FNR definition].

[AP1: I'm confused about the scope of the document then. You are not
defining FNR but you state that FNR requires (or is a superset of) TNR. And
for TNR you state that the NR bit must be set.]

>
> 2    Requirements for both 1-way and 2-way NR
>
> 2.1  The signer must submit, with the signature, the signing
> certificate or an unambiguous identifier of that certificate.
> Unambiguous identifiers of certificates include the combination of a
> certificate serial number with an issuer name [AP: You've only given 1
> identifier.][TG: So far, that's right.  I wasn't trying to be exhaustive.]

[AP1: I think you should give at least two since you state "Unambiguous
identifiers of certificates include..."]

[snip]
>
> 2.3  The signer must include, in the base over which the signature
> is calculated, the time at which the signature was created.[AP: I think this
>  opens up a can of worms: local time, GMT, precision, trusted, etc.]
> [TG: Format is not, and does not have to be, specified for this.  The signer
has
> to trust this time, but either the RP or the escrow holder (depending on 1-way
> vs. 2-way) will be adding a time stamp of their own.]

[AP1: How does the RP or EH (escrow holder) know the signer that the time
was included in the signature?]

[snip]
>
> 3.2  The relying party must save the identity of the signing
> certificate, along with the content of the signature.[AP: Isn't the
>  certificate self-identifiable? Isn't is sufficient to save the certificate?]
> [TG: Content of the signature, not of the certificate.  The full certificate
is
> acceptable, of course, since it contains its own ID.]

[AP1: I'm not sure what you mean by "content of the signature"?]

>
> 3.3  The relying party must check that the signing certificate
> contains a keyUsage extension.  If the extension is not present or does
> not contain the nonRepudiation bit, and the version of the certificate
> is v3 or higher, the submission must be rejected.[AP: I (and others in the WG)
>  believe this is wrong. Above you state the TNR is a requirement for FNR,
> but I think it has been shown in the recent discussions that the NR bit is NOT
> required for FNR.]
> [TG: 1-way NR is not a basis for FNR.  We can discuss this under 4.3,
however.]

[AP1: Ditto above confusion on TNR and FNR.]

[snip]
>
> 4.3  The relying party must check whether or not the signing
> certificate contains a keyUsage extension.  If the keyUsage extension
> is present and the nonRepudiation bit is not set the submission must be
> rejected.[AP: ditto comment as in 3.3]
> [TG: If the group really wants this, I'll put in some wording about how
"larger
> services extending this one may dispense from this requirement".  Note that
> missing keyUsage's are allowed here although not for 1-way.]

[AP1: I think you need a better explanation of the differences between 1 and
2-way NR and why they are needed.]

Regards,
Aram Perez


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA07400 for <[e-mail]>; Tue, 7 Sep 1999 15:42:36 -0700 (PDT)
Received: from nma.com (pm07-01.sac.verio.net [209.162.65.20]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id PAA28902; Tue, 7 Sep 1999 15:45:18 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 07 Sep 1999 15:45:13 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: PKIX non-repudiation
References: <v04020a01b3fb3411f9ad@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed,
>
> >It might be useful to view what others have understood
> >from  the X.509v2-3 and PKIX RFC 2459 definitions of
> >"non-repudiation", in order to see what was conveyed
> >by those texts -- before changes are introduced.  By
> >refering to "the reader's eyes" so to say, as reflected in
> >spontaneous renderings by those readers of what they
> >read in the specs, we can grade the specs' objectivity by
> >a metric based on neutral observers.
>
> There are lots of folks writing about PKIs, NR, etc. who don't necessarily
> know what they are talking about.  We see this often, in a variety of
> venues.  While it is worthwhile to try to clarify our definitions, I would
> not measure our success by what we see written by these folks, e.g., in
> online, unreviewed documents, trade magazines, etc.  Still, I agree that it
> may be worthwhile noting how people have misunderstood what we and others
> are saying, and use that as input to examples, but even here one cannot
> cover all the "wrong" bases.

Clearly not, nor I implied so.  But, as you agree, as a useful tool.  Especially,
to know what the policy-makers and the lawyers can understand ;-) or not.

Cheers,

Ed Gerck




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA06434 for <[e-mail]>; Tue, 7 Sep 1999 14:35:48 -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 RAA16418; Tue, 7 Sep 1999 17:38:24 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a01b3fb3411f9ad@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Tue, 7 Sep 1999 17:33:07 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: PKIX non-repudiation
Cc: "[e-mail]" <[e-mail]>

Ed,

>It might be useful to view what others have understood
>from  the X.509v2-3 and PKIX RFC 2459 definitions of
>"non-repudiation", in order to see what was conveyed
>by those texts -- before changes are introduced.  By
>refering to "the reader's eyes" so to say, as reflected in
>spontaneous renderings by those readers of what they
>read in the specs, we can grade the specs' objectivity by
>a metric based on neutral observers.

There are lots of folks writing about PKIs, NR, etc. who don't necessarily
know what they are talking about.  We see this often, in a variety of
venues.  While it is worthwhile to try to clarify our definitions, I would
not measure our success by what we see written by these folks, e.g., in
online, unreviewed documents, trade magazines, etc.  Still, I agree that it
may be worthwhile noting how people have misunderstood what we and others
are saying, and use that as input to examples, but even here one cannot
cover all the "wrong" bases.

Steve



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA04481 for <[e-mail]>; Tue, 7 Sep 1999 11:38:33 -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 LAA10883; Tue, 7 Sep 1999 11:41:15 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 07 Sep 1999 11:41:13 -0700
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: NR bit absence, was Re: Deprecate the NR bit?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 08:53 AM 9/7/99 -0400, David P. Kemp wrote:
>
>> From: Tony Bartoletti <[e-mail]>
>> 
>> By "signs a message as NR", I am sure Ed simply means "signs a message
>> with the key in question", which can subsequently be shown to have been
>> certified with "NR=1".  Thus the relying party, or who-knows-who, may
>> attempt to assert NR even though the application may not have cared.
>> 
>> Is this point in dispute?
>
>No.  I'm not sure what you intend by "the application may not have cared",
>but what I mean by it is that the application generated a signed object,
>period.

Yes, this is exactly my meaning as well.  An application does not "sign as NR"
per se, but the key used in the operation may certainly (later) be shown to
have been "NR certified".  To what effect...?

>> According to your earlier post, a PKIX-conforming application could apply
>> "signature" if the signature bit is set, and ignore any possible NR-bit
>> setting.  This is at least a clear position.  You also write that a PKIX-
>> conforming CA would not issue certain combinations of key usage bits.
>
>I hope I didn't write that!  I did write that I agreed with the current
>PKIX wording that explicitly does not restrict the combinations of key
>usage bits, and that such restrictions, if any, should be placed in
>community-specific certificate profiles.

Sorry if it looks like I attributed those exact words to you.  But the
terms "PKIX wording that explicitly does not restrict the combinations"
and my "PKIX-conforming application could apply" are in rough agreement.

You gave 3 instances of application key-usage, and indicated that each
usage need only be concerned (PKIX conformance-wise) that its particular
bit is set, and may ignore all others.  But your 3 examples specifically
left out the "interesting one" being debated, and Ed added it to extend
your argument.  This was the DS=1, ignore NR-bit example.

In essence, Ed argues that the "independence" of the individual key-usage
bits does not imply that all key-usages need only examine one bit, nor
that seeking only a proper collection of "bits=1" is sufficient.
 
Perhaps, beyond "PKIX conformance" (and beyond this WG) there need to be
a "Good Housekeeping Seal of Approval" for applications that adhere to
particular behaviors regarding key-usage bit-combos.  But then the PKIX
profile needs to be really neutral on these issues, and not step into it
halfway.

___tony___

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


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA03895 for <[e-mail]>; Tue, 7 Sep 1999 11:06:25 -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 LAA20827; Tue, 7 Sep 1999 11:07:54 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 07 Sep 1999 11:07:52 -0700
To: [e-mail], "Aram Perez" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: New Internet Draft on Non-Repudiation Requirements
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:26 AM 9/7/99 -0400, [e-mail] wrote:

>3    Requirements for 1-way NR
>
>3.1  The relying party must save a copy of the content being signed.[AP: Is a
> URI sufficient as in 2.2 above?]
>[TG: A URI isn't good enough.  It says "content" not "content or reference".]

[TB: What about the (crypto-strength) hash of a content?  Not that we often sign
100 MB documents, but perhaps digital photographs, video, sound recordings, ...
Of course, it would behoove the RP to keep a full copy so that the hash could be
reproduced at their discretion.  A URI is simply a pointer, right? and certainly
would not suffice alone.]


[TB: Overall, kudos for a well thought out exposition!]

___tony___


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


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA03081 for <[e-mail]>; Tue, 7 Sep 1999 10:09:32 -0700 (PDT)
Received: from nma.com (pm03-40.sac.verio.net [209.162.64.106]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id KAA29105; Tue, 7 Sep 1999 10:12:12 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 07 Sep 1999 10:12:15 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Table of four NR types, was Re: NR bit absence
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:

> I agree with you that "support for legal NR" is related to the binding
> between 1) private key and a single individual, and 2) public key/subject
> name to a single individual.

Dave:

Perhaps too much emphasis has been placed here on "single individual",
in both terms.  If we accept that non-repudiation (in whatever form) is
exactly useful when an individual "who" denies signing, then "who" is not
as important as "what", "when" and "how".

Besides, since X.509/PKIX never intended to cover the level of detail
needed to verify "who" (such verification depends on each CA's CPS),
I believe the "who" approach will also lack protocol support unless
it is entirely referenced to the CPS (and, entirely solved there).


>  I also believe that "support for legal NR"
> is also related to the generation of verifiable evidence, and that PKIX
> should declare that applications which produce signed objects generate
> verifiable evidence,

Agree, but "may generate verifiable evidence".

> and that applications which sign protocol-internal
> data for the purpose of establishing symmetric keys or other ephemeral
> data do not generate verifiable evidence.

I think this declaration is far too strong, since the signed evidence may
be asymmetric and thus provide evidence of an act by the other party.

> Thus, I would put a table such as the following into Tom's draft:

Dave: your tables are the best ;-) I would make the following change,
which would accommodate the four types of NR we talked about here --
including the need to have purely syntactical signatures (for example,
to prevent tampering en route):

Application      DS NR      Result
-----------      -----   -----------------------------------------
signed object:    0  0    SYN -- unknown presumption when signing [1]
                  1  0    DS  -- no presumption when signing [2]
                  0  1    POA -- rebuttable presumption when signing [3]
                  1  1    NR  -- irrebuttable presumption when signing [4]
authenticated
connection:       0  x    no presumption of authentication
                  1  x    rebuttable presumption of authentication

where:

[1] SYN (syntactic): signature presumption is unknown (for example,
    unreliable and inaccurate attributions), but the signature
    verifies syntactically. Application: signer is defined by an
    email alias, signs automatically.  Provides message integrity.

[2] DS (digital signature): signature presumptions are denied. The
    signer provides reliable evidence of attribution to itself but
    denies any signing context, even that it knows what was being
    signed. Application: signer wants to send email msgs that are
    both tamperproof and with origin authentication but which do
    not imply any presumed commitment nor liability in case of key
    compromise. Provides authentication.

[3] POA (proof of authentication): signature presumptions are affirmed
    by signer but can be rebutted by signer if insufficient proof of
    authentication is provided by the relying-party.  Application:
    e-commerce when signer needs to affirm a buying order but does
    not want to incur in the liability issues of virus, hackers,
    etc.  NOTE: The issue here is not whether the signer could deny
    the transaction (which is a legal issue), but whether the
    relying-party can provide evidence of authentication that could
    be accepted (or not) as proof; thus a signer may not be able to
    hide behind the POA mode in order to successfully deny a
    transaction in a mood change, if the relying-party can provide
    POA that is deemed (legally or policy-wise) credible enough in
    the operational circumstances.

[4] NR (non-repudiation): signature presumptions cannot be denied
    by signer and are irrebuttable if the signature is authenticated.
    Technical application: signer has a NR certificate which
    can be used within a time window from a caller-ID phone call
    from one specific phone, and which the signer uses to
    immediately command an act (e.g., reboot server) without any
    need (in a threat model) for a confirmation.  Commercial
    application: signer wants bank to move funds without need for
    confirmation, up to amount X.  NOTE: with NR, a false act
    cannot be denied once authenticated -- the metric is not whether
    the act was truthful or not but whether the relying-party could
    not distinguish the *previously* agreed authentication procedure
    (e.g., caller ID plus NR cert within a time window; NR cert
    up to amount X) from a procedure that the signer did *not*
    produce. Note also that this metric does not depend on any legal
    theory that needs to be applied -- as exemplified by the server
    reboot NR example.

Further, with this table there is no indeterminacy when the NR
bit is absent.  As pointed out above, the basis for all four
NR types (yes, absence of NR is a NR type) is technical but
legal context can also be provided if so desired by a CPS,
since the cases correspond to mutually-exclusive legal models
(which also have the same names: unknown presumption, no presumption,
rebuttable presumption, irrebutable presumption).

Cheers,

Ed Gerck




Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA01106 for <[e-mail]>; Tue, 7 Sep 1999 08:25:34 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA143700; Tue, 7 Sep 1999 11:27:40 -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.04) with SMTP id LAA56990; Tue, 7 Sep 1999 11:28:04 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852567E5.0054F358 ; Tue, 7 Sep 1999 11:27:53 -0400
X-Lotus-FromDomain: IBMUS
To: "Aram Perez" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 7 Sep 1999 11:26:30 -0400
Subject: Re: New Internet Draft on Non-Repudiation Requirements
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Thank you for your comments.  After looking at some of these comments, I
think I should add some more stuff to some of the sections.  I'm copying in my
proposed section 3.4 from the transmittal as well.  My direct responses to your
questions are bracketed with [TG: comment].

3.4  The relying party should create, and save with the data submitted, a
package containing a current time stamp signed by an independent authority.
This object signed by the independent authority should include, in addition to
the time stamp, one of the following: a countersignature created by the relying
party, a copy of the "signature block" of the submitted document, or the entire
submitted document.

(Add to 3.2)   If the relying party has verified the certificate using a server
supporting a "signed-status-response" protocol such as OCSP or SCVP, the relying
party must store the tatus responses with the data submitted.  If the relying
party has verified the certificate using a CRL, the relying party may store that
CRL with the data submitted.  The relying party should also include the chain of
issuer certificates back to his (or her) trusted root.

(Add to 4.1)   If the relying party has verified the certificate using a server
supporting a "signed-status-response" protocol such as OCSP or SCVP, the relying
party must include the status responses in the escrow package.  If the relying
party has verified the certificate using a CRL, the relying party may include
that CRL in the escrow package.  The relying party should also include the chain
of issuer certificates back to his (or her) trusted root.

          Tom Gindin

Hi Tom,

I've attached an edited version of your document. My comments are bracketed
by "[AP: comment]".

Regards,
Aram


Internet-Draft                                       Thomas Gindin
PKIX WG                                                 IBM Corp.
Intended Category: Informational
Expires: 28 February 2000                          28 August, 1999



                 Internet X.509 Public Key Infrastructure
          Technical Requirements for a non-Repudiation Service
                 <draft-gindin-pkix-technr-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 February 28, 2000. 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, at [e-mail].

This Internet-Draft represents the views of its author, and not
necessarily those of his employer.

ABSTRACT

This document describes those features of a service which processes
signed doucments which must be present in order for that service to
constitute a "technical non-repudiation" service.  A technical
non-repudiation service must permit an independent verifier to
determine whether a given signature was applied to a given data object
by the private key associated with a given valid certificate, at a time
later than the signature.  The features of a technical non-repudiation
service are expected to be necessary for a full non-repudiation service,
although they may not be sufficient.
[AP: You've defined a "'technical non-repudiation' service", but not a "full
non-repudiation service". I'll use the acronym "TNR" for technical
non-repudiation and "FNR" for full non-repudiation.]

This document is intended to clarify the definition of the
"non-repudiation" service in RFC 2459.  It should thus serve as a guide
to when the nonRepudiation bit of the keyUsage extension should be used
[AP: We should be consistent with either "nonrepudiation" or "non-repudiation".
Also, does "used" mean the same thing as "set"?]
[TG: "when the nonRepudiation bit should be used" could easily be "... set"
without any real change in meaning.]
and to when a Certificate Authority is required to archive CRL's.
[AP: Does the CA only have to archive CRL's for TNR? Does the CA need to perform
a higher due diligence before setting the NR bit? Can the CA set the NR bit
without the subject requesting that the bit be set?]
[TG: It is stated above, that FNR incorporates TNR as a core set of
requirements.  Thus, CRL archiving is only directly mandated for TNR - but that
mandates it for FNR as well.]
[TG: Higher levels of due diligence are probably needed for FNR.  I doubt if
they are needed for TNR.]
[TG: The CA can set the bit if it wishes.  This service does not have the kind
of heavy-duty legal requirements that FNR is likely to.]

1 Introduction

RFC 2459 [1] specifies a bit within the KeyUsage extension called the
nonRepudiation bit which is "asserted when the subject public key is
used to verify digital signatures used to provide a non-repudiation
service which protects against the signing entity falsely denying some
action, excluding certificate or CRL signing."  Extensive discussions
in the PKIX WG have revealed that the description of the non-repudiation
service contained in this passage is not widely enough understood or
agreed upon to characterize any given service as providing or not
providing a non-repudiation service.  Two major categories of service
have been proposed as potentially providing a non-repudiation service:
the technical non-repudiation service, which this draft attempts to
define with greater precision, and a full non-repudiation service
which is intended to prevent all possible repudiations of a signed
object or document.  Since a full non-repudiation service is required
to meet all the requirements of this technical non-repudiation service
as a prerequisite, the technical non-repudiation service's definition
is necessary for both [AP: I disagree if you require the NR bit to be set].
[TG: I'm not defining FNR here.  An FNR set of requirements is likely to define
a needed keyPurpose ID in the XKU extension, anyway.  My question is whether you
and the other FNR supporters believe that there needs to be some indication in
the certificate that a given certificate is intended for NR or FNR use.]


1.1  Definitions

Signing Certificate:     A certificate containing the key pair whose
[AP: Containing the "key pair" or the "public key component of a key pair
whose"]
[TG: Thanks - the second variant is clearer than mine.]
private key was used to create the signature being verified.

Signer:        The party who created the signature being verified.  It
is outside the scope of these requirements to distinguish between the
actual signer and the holder of the signing certificate.
[AP: The r-p is a "holder of the signing certificate". Do you mean the actual
signer and the owner of the private key?]
[TG: Probably "subject" is better than "holder" here and below.  Thanks.]

Relying Party: The party who received the signature being verified, and
initially verified it.

Verifier: An entity independent of both the signer and the relying
party who is verifying that the supplied signature, data object, and
certificate are consistent with each other.

1-way NR: A service in which the relying party preserves
sufficient evidence to permit the verifier to perform a verification,
and may submit it for verification by his or her own action.

2-way NR: A service in which the relying party submits
sufficient evidence to permit the verifier to perform a verification
to a third party, known as the "escrow holder". [AP: I had to read
this definition several times before understanding it. How about
 defining escrow holder first and then defining 2-way NR as "A service
 in which the r-p submits sufficient evidence to an escrow holder that
allows a verifier to perform a verification at a later time."?]
[TG: I'll wait to see if others are confused by 2-way vs. 1-way NR.  Your
suggestion about order might be easier to understand and doesn't damage the
meaning.]

Escrow holder: The party responsible for preserving signature evidence
in 2-way NR.  The escrow holder may also be, but need not be, the
verifier.

Escrow package:     The data submitted from the relying party to the escrow
holder, in 2-way NR [AP: ", that constitutes sufficient evidence"][TG: No - I
may need to add something about post-storage responsibilities of the escrow
holder].  The escrow holder may add certain auditing and tracking information to
this package before storage.

NR service:    The technical nonRepudiation service referenced above. [AP: I
think you should define it here again, and this be the formal definition.][TG:
Actually, it probably should include a statement about either 1-way or 2-way
being needed]

keyUsage extension: A standard extension within X.509v3 certificates
with object identifier { 2 5 29 15 }, consisting of a series of
enumerated bits.

NR bit:        The nonRepudiation bit (offset 1) of the keyUsage
extension.


1.2  Scope and caveats

     The [AP: "T"]NR service is expected to provide evidence that a given
object was signed by the private key corresponding to a given
certificate which was valid at the time of signature.  It is not
anticipated that the use of the NR service will ordinarily constitute
execution of a contract, or acceptance of any other legal obligation.
It is anticipated that the use of this service in accepting legal
obligations will be the subject of legislation or judicial decision
in various jurisdictions, which are likely to lay additional technical
burdens upon the provision of such a service to such an extent as to
constitute another, larger service which need not be the same in all
jurisdictions.[AP: This sentence is too long!]  It is outside the scope of the
definition of this
service to provide evidence that the signer and the holder of the
signing certificate are the same [AP: ditto comment above about holder vs.
owner.][TG: subject]
, that the signer has been adequately informed of the content which is signed,
that the signer is not acting
under duress, etc. [AP: I think the scope should only include when the NR bit is
set, but clearly state that you can have FNR with the NR bit not set (as have
been stated in the WG).][TG: That is fairly controversial in the WG, and I'm not
doing the FNR definition].

2    Requirements for both 1-way and 2-way NR

2.1  The signer must submit, with the signature, the signing
certificate or an unambiguous identifier of that certificate.
Unambiguous identifiers of certificates include the combination of a
certificate serial number with an issuer name [AP: You've only given 1
identifier.][TG: So far, that's right.  I wasn't trying to be exhaustive.]

2.2  The signer must submit, with the signature, the content being
signed or an unambiguous reference to that content.  It is explicitly
contemplated that a URI constitutes an unambiguous reference to its
content. [AP: Do we have to worry about platform specific transformations, i.e.
CRLF vs. CR v. LF, base-64 encoding, compression, etc?]
[TG: Canonicalization of an external document is out of scope for this.]

2.3  The signer must include, in the base over which the signature
is calculated, the time at which the signature was created.[AP: I think this
 opens up a can of worms: local time, GMT, precision, trusted, etc.]
[TG: Format is not, and does not have to be, specified for this.  The signer has
to trust this time, but either the RP or the escrow holder (depending on 1-way
vs. 2-way) will be adding a time stamp of their own.]

2.4  The relying party must, before accepting the signature, verify
that the signing certificate is valid.  This verification should include
a CRL check.[AP: Do we allow OCSP or SVCP?]
[TG: Your point about OCSP and SCVP is well taken.  They should be allowed (I
didn't remember that they had an effective time field).  However, they will need
some extra archiving requirements because CRL archiving might not apply
sufficiently to them.]


2.5  The relying party must, before accepting the signature, verify
the signature of the data object being submitted.[AP: This seems too
obvious. Why would a r-p accept a signature that does not verify?]
[TG: A single sentence on something obvious isn't a serious problem, is it?]


3    Requirements for 1-way NR

3.1  The relying party must save a copy of the content being signed.[AP: Is a
 URI sufficient as in 2.2 above?]
[TG: A URI isn't good enough.  It says "content" not "content or reference".]

3.2  The relying party must save the identity of the signing
certificate, along with the content of the signature.[AP: Isn't the
 certificate self-identifiable? Isn't is sufficient to save the certificate?]
[TG: Content of the signature, not of the certificate.  The full certificate is
acceptable, of course, since it contains its own ID.]

3.3  The relying party must check that the signing certificate
contains a keyUsage extension.  If the extension is not present or does
not contain the nonRepudiation bit, and the version of the certificate
is v3 or higher, the submission must be rejected.[AP: I (and others in the WG)
 believe this is wrong. Above you state the TNR is a requirement for FNR,
but I think it has been shown in the recent discussions that the NR bit is NOT
required for FNR.]
[TG: 1-way NR is not a basis for FNR.  We can discuss this under 4.3, however.]

4    Requirements for 2-way NR

4.1  The relying party must submit to the escrow holder a copy of
the content being signed, the identity of the signing certificate, and
the signature.[AP: ditto comment as in 3.2]
[TG: Content of the signature, not of the certificate.]

4.2  The relying party must sign the submission to the escrow holder.
The relying party SHOULD include, in the base over which that signature
is calculated, the current time. [AP: ditto comment as in 2.3]  This time will
be between the time
when the signer submitted the signature and the time when the package
is submitted.  The signed object submitted is known as the escrow
package.
[TG: This does need some work, although format and precision aren't the major
issues.  I think I need to add a requirement that the escrow holder add some
fields to the escrow package, which MUST include the time of receipt, for
example].

4.3  The relying party must check whether or not the signing
certificate contains a keyUsage extension.  If the keyUsage extension
is present and the nonRepudiation bit is not set the submission must be
rejected.[AP: ditto comment as in 3.3]
[TG: If the group really wants this, I'll put in some wording about how "larger
services extending this one may dispense from this requirement".  Note that
missing keyUsage's are allowed here although not for 1-way.]

5 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.


6 References

[1] R. Housley, W. Ford, W. Polk, and D. Solo "Internet X.509 Public Key
Infrastructure Certificate and CRL Profile", RFC 2459, January 1999
[2] X.509(97)



7 Author's Address

Thomas Gindin
IBM Corporation
800 North Frederick Ave.
Gaithersburg, MD 20879
USA

Email: [e-mail]

Internet-Draft Technical Requirements for a non-Repudiation Service
Expires: 28 February 2000




Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA29807 for <[e-mail]>; Tue, 7 Sep 1999 07:31:52 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA10259; Tue, 7 Sep 1999 07:27:47 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 07 Sep 1999 10:32:46 -0400
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Stefan:

 >>Single Certificate Policy OID
 >>
 >>When an end-entity certificate contains more than one certificate policy
 >>OID, there is ambiguity about the intent of a signer.  On the other hand,
 >>if the end-entity certificate contains only one certificate policy OID,
 >>there is no ambiguity.  If an end-entity certificate contains two policies,
 >>one that says the certificate id for use with non-binding e-mail and
 >>another that says the certificate is intended for purchases up to $10,000,
 >>then it is not clear the signer intends when a signature is generated.
 >
 >This is to me a bad way to view certificate policies. Certificate Policies
 >are assertions by the CA to relying parties. It is NOT an assertion by the
 >signer. When a signer signs a message, the intention of the signer is only
 >expressed in that message, not in any certificate.

Certificate policies are defined in X.509, Section 3.3.5.  Is says: "A 
named set of rules that indicates the applicability of a certificate to a 
particular community and/or class of application with common security 
requirements. For example, a particular certificate policy might indicate 
applicability of a type of certificate to the authentication of electronic 
data interchange transactions for the trading of goods within a given price 
range."

So, what do these words mean?  They do not seem to exclude any of the 
parties: the CA, the subject, and the certificate user (a.k.a. relying party).

 >Even if there are many certificates out there for the signers public key,
 >the signer goes free of liability for any "bad" certificate. And if some of
 >these certificates has ambiguous policy OIDs, that says nothing about the
 >signers intent. It just points out a bad CA and that CA may get into trouble.

In my view, the certificate user should reject a transaction that is 
associated with an inappropriate certificate policy.  The certificate user 
states which certificate policies are acceptable for the pending 
transaction in the initial-policy-set input to the certificate path 
validation algorithm.  If the path does not support this policy or 
policies, then validation fails.  Further, a set of certificate policy 
qualifier is returned for each valid policy.  These qualifiers are supposed 
to help the certificate user determine if a valid path is appropriate for 
the specific transaction at hand.

 >What you are talking about seams to be more appropriate for signature
 >policies, which would be asserted by the signer.

We do not have such a thing....

 >>One solution for this problem is specified in  RFC 2634, Section 5.4
 >>(Signing Certificate Attribute Definition).  Here, the signer can state the
 >>policy that was intended at the time the signature is generated.  Other
 >>protocols that use the PKIX Certificate Profile do not have similar
 >>mechanisms.
 >
 >With all respect to the attacks expressed in section 5, any attempt to
 >solve this by having the signer assert appropriate certificate content, is
 >to address the issue from the wrong angle. These attacks do in the first
 >place assume that a relying party trusts any bad CA.
 >
 >If that is so (i.e. the relying parties trust hierarchy is broken) or a CA
 >within that trust hierarchy is bad. Then there are so many other potential
 >problems, that you basically are sucked any way.
 >
 >These problems must be treated by each relying party by having working
 >trust models originating from trusted roots. If you have that, then you are
 >fixing non-existing problems. If you don't have that, you can't fix
 >anything anyway.

I grant you that some of the attacks are a result of a certificate user 
trusting a "bad" CA.  However, if the same public key is in more than one 
certificate, similar issues arise.  This provides a mechanism for the 
signer to assert which of those certificates should be used to validate the 
message.  (Using a different public key in each certificate is even better.)

 >>I understand the desires expressed by Mack Hicks and Dave Solo for multiple
 >>certificate policy OIDs in a certificate.  And, I can imagine environments
 >>where there would not be a problem with this practice.  Perhaps we need
 >>some guidance about when it is acceptable and when it is not.
 >
 >many OIDs are acceptable. The CA must however make sure that no certificate
 >contains conflicting policies. But I hope all CAs understand that.

By including multiple OIDs in a certificate, the CA is stating that the 
certificate was issues in accordance with each of the policies.  If the 
certificate policy states a particular use, then the certificate is 
appropriate for that use.  If the certificate policy states a particular 
means of validating identity, then that means was used.

 >>Limiting Certificate Policy Qualifiers to End-Entity Certificates
 >>
 >>A review of the certificate path validation algorithm shows that one of
 >>it's outputs is a set of certificate policy qualifiers.  X.509-1997 says
 >>that a successful validation returns "a set of policies constrained by the
 >>CAs in the certification path, together with all qualifiers for these
 >>policies encountered in the certification path."
 >>
 >>This means that the certificate user cannot tell which qualifier goes with
 >>which certificate in the path.  Rather, an unordered set of the qualifiers
 >>is provided. Since the purpose of qualifier is to provide additional policy
 >>information to the certificate user (a.k.a. the relying party), it seems
 >>important that the set of qualifiers not provide
 >>contradictions.  Especially in the case of the qualifiers specified in RFC
 >>2459.
 >
 >I believe you read X.509 wrong here. The full text of that section continues:
 >
 >"Unless any-policy is returned, the certificate user shall ONLY use the
 >certificate in accordance with ONE of the identified policies and shall
 >process all qualifiers for THAT policy present in the certification path."
 >
 >Now how is that possible if you return an un-ordered set of the qualifiers,
 >not related to their associated policies.

The algorithm gathers the qualifiers associated with each certificate 
policy as it processes the path.  The algorithm returns a set of valid 
certificate policies and a set of qualifiers for each of those certificate 
policies.  I do not see anything in the algorithm that keeps a binding 
between the qualifiers and the certificates that provided them.

 >The path processing algorithm does further not use separate variables for
 >policies and for qualifiers. A reasonable interpretation of the algorithm,
 >given these facts, must be that all policy objects in the process is
 >handled together with their associated qualifiers, and thus should be
 >presented that way in the output.

I think we just said the same thing.  There is no binding.  A certificate 
may provide multiple qualifiers, or it could provide one, or it could 
provide zero.  Can't tell by the output of the algorithm.

 >Your interpretation must be wrong here, or do you have an installed base of
 >softwares to back your view?

I do not think that there is any installed base backs any 
view.  Certificate policy handling is absent in most certificate using 
applications and primitive in the rest.  CAs may be more advanced, but you 
cannot really tell given the state of certificate using applications.

 >>Mike Myers suggests that CA certificates should be permitted to include the
 >>CPS pointer qualifier.  Let's assume that there is a simple path of two
 >>certificates, the CA certificate and the end-entity certificate.  The CA
 >>certificate has two certificate policy OIDs, each with a CPS pointer
 >>qualifier.  The end-entity certificate has a single certificate policy OID,
 >>also with a CPS pointer qualifier.  When the certificate path validation
 >>algorithm is executed, one of the outputs will be the certificate policy
 >>OID that is common to both certificates and the two qualifiers (one from
 >>the CA certificate and one from the end-entity certificate).  What is the
 >>certificate user expected to do?  If the URLs are different, the
 >>certificate user really has no idea what to do.
 >
 >See above +
 >This example suggest that a CA issue a certificate under two different
 >CPSs, That seams to be a false case.
 >
 >If there would be a guideline it should say that a certificate may include
 >many policy OIDs but should only indicate one CPS. One CPS may very well
 >reflect multiple policies.

I belive that it is possible that two CAs can support the same certificate 
policy using different CPSs.  This certificates issued by the two CAs would 
have the same OID but a different CPS pointer.  Now, if one CA issues a 
certificate to the other, the resulting path to an end-entity will have one 
certificate policy OID throughout, but two different CPS pointer qualifiers.

Russ



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA29320 for <[e-mail]>; Tue, 7 Sep 1999 07:05:20 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA09674 for <[e-mail]>; Tue, 7 Sep 1999 07:01:32 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 07 Sep 1999 09:33:31 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Bill:

 >>Single Certificate Policy OID
 >>
 >>When an end-entity certificate contains more than one certificate policy
 >>OID, there is ambiguity about the intent of a signer.  On the other hand,
 >>if the end-entity certificate contains only one certificate policy OID,
 >>there is no ambiguity.  If an end-entity certificate contains two policies,
 >>one that says the certificate id for use with non-binding e-mail and
 >>another that says the certificate is intended for purchases up to $10,000,
 >>then it is not clear the signer intends when a signature is generated.
 >
 >But, is it clear that one CP will necessarily be that specific?  A single
 >policy  might allow several applications, or it might speak to assurance
 >level rather than constraining applications at all.
 >
 >Moreover, when I sign something with my John Hancock, do I state the policy
 >under which I sign it, and have a separate signature for every kind of
 >document I sign?  Why do I have to with certificates?  And, is it your
 >supposition that the certificate used to sign a document is always bound
 >with the signed document?

This question was debated quite a bit in the ietf-smime list.  Denis Pinkas 
was the major advocate for a mechanism that allowed a signer to bind the 
certificate that she expected to be used to verify the signature to the 
signed content.  RFC 2634, Section 5.4 is the result of that discussion.

Some certificate policies will include statements that limit the types of 
transactions for which the certificate is appropriate. SET is one existing 
example.  A SET certificate should not be considered valid for signing 
S/MIME messages.  On the other hand, there are policies that do not include 
such constraints.  Verisign Class 1 is one example.  It is up to the signer 
to use a private key that corresponds to an appropriate certificate when 
signing.  If the signer does not, then the recipient will not consider the 
signature valid.

Russ


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA28444 for <[e-mail]>; Tue, 7 Sep 1999 05:52:56 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA20452 for <[e-mail]>; Tue, 7 Sep 1999 08:55:44 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA20447 for <[e-mail]>; Tue, 7 Sep 1999 08:55:43 -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 IAA28445 for <[e-mail]>; Tue, 7 Sep 1999 08:55:28 -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 IAA03062 for <[e-mail]>; Tue, 7 Sep 1999 08:53:37 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 7 Sep 1999 08:53:37 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: NR bit absence, was Re: Deprecate the NR bit?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: w6nAhJoZbFKOrelf+4dAMg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Tony Bartoletti <[e-mail]>
> 
> By "signs a message as NR", I am sure Ed simply means "signs a message
> with the key in question", which can subsequently be shown to have been
> certified with "NR=1".  Thus the relying party, or who-knows-who, may
> attempt to assert NR even though the application may not have cared.
> 
> Is this point in dispute?

No.  I'm not sure what you intend by "the application may not have cared",
but what I mean by it is that the application generated a signed object,
period.


> According to your earlier post, a PKIX-conforming application could apply
> "signature" if the signature bit is set, and ignore any possible NR-bit
> setting.  This is at least a clear position.  You also write that a PKIX-
> conforming CA would not issue certain combinations of key usage bits.

I hope I didn't write that!  I did write that I agreed with the current
PKIX wording that explicitly does not restrict the combinations of key
usage bits, and that such restrictions, if any, should be placed in
community-specific certificate profiles.

I agree with you that "support for legal NR" is related to the binding
between 1) private key and a single individual, and 2) public key/subject
name to a single individual.  I also believe that "support for legal NR"
is also related to the generation of verifiable evidence, and that PKIX
should declare that applications which produce signed objects generate
verifiable evidence, and that applications which sign protocol-internal
data for the purpose of establishing symmetric keys or other ephemeral
data do not generate verifiable evidence.

Thus, I would put a table such as the following into Tom's draft:

Application      DS NR      Result
-----------      -----   -----------------------------------------
signed object:    0  0    prohibited (except for certs/CRLs)
                  0  1    provides "support for legal NR" *
                  1  0    provides Ed's "Proof of Authentication"
                  1  1    provides "support for legal NR" *
authenticated
connection:       0  x    prohibited  (NR bit is "don't care")
                  1  x    provides Authentication (without proof)

* The case where both the private key is bound to the subject and the
  application generates a signed object is the PKIX-defined "technical
  prerequisite" for supporting NR.  Additional (currently not defined)
  conditions, such as evidence of user intent and CA's intent, will be
  required, but are not addressed by the NR keyUsage bit.




Received: from smtp.exocom.com (smtp.exocom.com [209.167.230.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA27914 for <[e-mail]>; Tue, 7 Sep 1999 05:16:25 -0700 (PDT)
Received: by mail.exocom.com with Internet Mail Service (5.5.2448.0) id <R3D38WQV>; Tue, 7 Sep 1999 08:21:36 -0400
Message-ID: <[e-mail]>
From: "Wilson, Brian" <[e-mail]>
To: [e-mail]
Subject: Unsubscribe
Date: Tue, 7 Sep 1999 08:21:35 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

unsubscribe

Brian Wilson, CISSP

IT Security Consultant
Network Architecture Services
Exocom Enabling Technologies Corp
1400-45 O'Connor Street, Ottawa ON  K1P 1A4
Tel: [phone]  Fax: [phone]
E-Mail: [e-mail]
Internet: www.exocom.com




Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA13722 for <[e-mail]>; Mon, 6 Sep 1999 17:34:54 -0700 (PDT)
Received: from nma.com (pm02-32.sac.verio.net [209.162.64.51]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id RAA20175 for <[e-mail]>; Mon, 6 Sep 1999 17:37:31 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 06 Sep 1999 17:37:35 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: PKIX non-repudiation 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

List:

It might be useful to view what others have understood
from  the X.509v2-3 and PKIX RFC 2459 definitions of
"non-repudiation", in order to see what was conveyed
by those texts -- before changes are introduced.  By
refering to "the reader's eyes" so to say, as reflected in
spontaneous renderings by those readers of what they
read in the specs, we can grade the specs' objectivity by
a metric based on neutral observers.

This is what I found in http://www.rmionline.com/cryp_tutorialbody
under "Electronic Crypto Method" for "Non-Repudiation":

 Digital non-repudiation is provided via digital signatures,
 which are created by hashing a  message (file) and encrypting
 the result with the private key of  the authorizer. This binds the
 digital signature to the digital message (file) being authorized,
  making it extremely difficult to counterfeit.

which means that, to them, "non-repudiation" is directly provided
by the security of digital signatures.  It is a syntactic property of
a digital signature by itself.  The fact that this WG has recently
unanimously rejected this interpretation even for what has been
called here "technical non-repudiation" is an indication, IMO,
that this rendering should be denied in future documents in
order to clarify what NR is not.

{In other words, what is being described in the reference is simply a
property of DS, not a property of NR}

Further, even though it might not be yet so clear to this WG what
NR is or should be in PKIX, we may have achieved a better understanding
of what NR is not -- and this could likewise be reflected in the specs,
in order to avoid future false interpretations.  Counter-examples help, also
in specs.

Cheers,

Ed Gerck


PS: BTW, the same reference has also a rather fitting acronym for
that which discussing these matters may potentially produce ;-)

 The primary components of transactions security can be remembered
 by their acronym, PAIN, and include:

     Privacy (P)
     Authentication (A)
     Integrity (I)
     Non-repudiation (N)




Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA08458; Mon, 6 Sep 1999 09:46:47 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 06 Sep 1999 09:47:27 -0700
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: End-Entity Certificate Policies v. EKU
In-Reply-To: <H0000cc4042d1dd1@MHS>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:56 AM 9/6/1999 -0400, [e-mail] wrote:
>We certainly shouldn't disrupt usage already in the pipeline.  However, it 
>may
>be appropriate (assuming the current revisions make policy more 
>implementable)
>to provide better guidance going forward.  Note that syntactically, EKU and
>certpolicies are very similar in terms of being a list of OIDs (and ignoring
>qualifiers).  I would argue that defining a widely recognized policy OID 
>should
>be no harder than defining a widely recognized EKU OID and, where the 
>semantics
>deal with applicability rather than cryptographic function, using policy
>benefits from the possibility of cert path enforcement.  For an enterprise
>environment, being able to restrict which CAs can issue certs for a given
>purpose is highly useful.

I fully agree with all of this. I would extend it a bit to say that, if we 
add such suggestions, we add them to *both* sections 4.2.1.13 (extended key 
usage) and 4.2.1.5 (policies) and point to each other, so future designers 
have the highest chance of hitting the new suggestions.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from citicorp.com (mango2.citicorp.com [192.193.196.141]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA07300; Mon, 6 Sep 1999 08:54:57 -0700 (PDT)
From: [e-mail]
Received: from spruce.citicorp.com (spruce.citicorp.com [192.193.196.184]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id LAA19159; Mon, 6 Sep 1999 11:56:30 -0400 (EDT)
Received: from x400prod2.cgin.us-md.citicorp.com (omroute1.email.citicorp.com [163.39.141.235]) by spruce.citicorp.com (8.8.5/8.8.5) with ESMTP id LAA15854; Mon, 6 Sep 1999 11:57:18 -0400 (EDT)
Received: from saturnalias.email.citicorp.com ([e-mail] [163.39.141.252]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA21944; Mon, 6 Sep 1999 11:56:47 -0400 (EDT)
Received: from localhost (root@localhost) by saturnalias.email.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA03496; Mon, 6 Sep 1999 11:56:47 -0400 (EDT)
X-OpenMail-Hops: 1
Date: Mon, 6 Sep 1999 11:56:41 -0400
Message-Id: <H0000cc4042d1dd1@MHS>
Subject: RE: End-Entity Certificate Policies v. EKU
MIME-Version: 1.0
TO: [e-mail], [e-mail]
Content-Type: multipart/mixed; boundary="openmail-part-0d1e16b3-00000001"

--openmail-part-0d1e16b3-00000001
Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT"
Content-Disposition: inline; filename="BDY.TXT"
Content-Transfer-Encoding: 7bit

Paul,

We certainly shouldn't disrupt usage already in the pipeline.  However, it may 
be appropriate (assuming the current revisions make policy more implementable) 
to provide better guidance going forward.  Note that syntactically, EKU and 
certpolicies are very similar in terms of being a list of OIDs (and ignoring 
qualifiers).  I would argue that defining a widely recognized policy OID should 
be no harder than defining a widely recognized EKU OID and, where the semantics 
deal with applicability rather than cryptographic function, using policy 
benefits from the possibility of cert path enforcement.  For an enterprise 
environment, being able to restrict which CAs can issue certs for a given 
purpose is highly useful.

Dave 

> -----Original Message-----
> From: phoffman [mailto:[e-mail]]
> Sent: Sunday, September 05, 1999 7:13 PM
> To: dsolo; ietf-pkix
> Cc: phoffman
> Subject: RE: End-Entity Certificate Policies v. EKU
> 
> 
> At 07:02 PM 9/5/1999 -0400, David Solo wrote:
> >Sorry Paul, perhaps my longstanding concerns about EKU led 
> me to overstate
> >the point slightly :-)
> >
> >Nonetheless, for the application applicability examples I 
> had cited, as well
> >as the general notion of "operating under the rules of xxx", 
> I think EKU is
> >a poor choice.  Key usage relating to cryptographic function 
> makes sense.
> >As it starts to begin to be used to express applicability of 
> the cert for
> >different applications (and especially where that rule 
> should be enforced as
> >part of path validation), I think cert policies is a better 
> option.  If I
> >were cynical, I'd speculate that some of the current uses of 
> EKU arose from
> >the (continuing) problems with implementing certpolicy.
> 
> You may be right on that speculation. However, many (most?) 
> of the IPsec 
> vendors who do certs look for the EKU because that's where 
> they were told 
> to look. It would be pretty harsh to say to the deployed PKIX 
> world "we're 
> getting rid of this thing you rely on because we misdesigned 
> it and we want 
> to be sure you can't use it".
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

--openmail-part-0d1e16b3-00000001
Content-Type: application/ms-tnef; name="WINMAIL.DAT"
Content-Disposition: attachment; filename="WINMAIL.DAT"
Content-Transfer-Encoding: base64

eJ8+IsCDAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5N
aWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEDkAYADAAAAAEAAAADABcAAQAA
ABwAAQOQBgAMAAAAAQAAAAMANgAAAAAAOgABBIABACsAAABSRTogRW5kLUVudGl0eSBDZXJ0
aWZpY2F0ZSBQb2xpY2llcyB2LiBFS1UAVg4BA5AGAAwAAAABAAAACwACAAEAAAAPAAEDkAYA
DAAAAAEAAAALACsAAAAAADcAAQOQBgAMAAAAAQAAAAMALgAAAAAAMgABA5AGAEAAAAABAAAA
AgExAAEAAAAwAAAANC4yLjAuNTguMTk5OTA5MDUxNjEwMTEuMDBiNWM3ODAoYSltYWlsLmlt
Yy5vcmcATgwBA5AGABAAAAABAAAAQAA5AGCzDGCA+L4BMAQBA5AGABwAAAABAAAAHgBCAAEA
AAAMAAAAU29sbywgRGF2aWQAPwQBA5AGABAAAAABAAAAQABIALCGNGCA+L4BigQBA5AGADgA
AAABAAAAHgBwAAEAAAAnAAAARW5kLUVudGl0eSBDZXJ0aWZpY2F0ZSBQb2xpY2llcyB2LiBF
S1UAABwOAQOQBgAoAAAAAQAAAAIBcQABAAAAFgAAAAG++IBgBnmttH5kcRHTszAAADkToxUA
ACEJAQOQBgAMAAAAAQAAAAMABhCun7yLrgIBA5AGAAwAAAABAAAAAwAHEI8GAACwAAEDkAYA
eAAAAAEAAAAeAAgQAQAAAGUAAABQQVVMLFdFQ0VSVEFJTkxZU0hPVUxETlRESVNSVVBUVVNB
R0VBTFJFQURZSU5USEVQSVBFTElORUhPV0VWRVIsSVRNQVlCRUFQUFJPUFJJQVRFKEFTU1VN
SU5HVEhFQ1VSUkVOAAAAAAAeAQOQBgAMAAAAAQAAAAMAEBAAAAAAJAABA5AGAAwAAAABAAAA
AwAREAEAAAAmAAEDkAYAFAAAAAEAAAAeAEIQAQAAAAEAAAAAAAAAcwABA5AGABAAAAABAAAA
QAAHMKAAeEV/+L4BCwQBA5AGABAAAAABAAAAQAAIMFDyqi6A+L4BygQBA5AGACAAAAABAAAA
AgELMAEAAAAQAAAAerSteXFk0xGzMAAAOROjFUQGAQOQBgAMAAAAAQAAAAMA3j+vbwAAPwIB
A5AGACQAAAABAAAAAwBPngggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAC6AgEDkAYAJAAA
AAEAAAADAFCeCCAGAAAAAADAAAAAAAAARgAAAABShQAA8BMAAAAEAQOQBgAkAAAAAQAAAAMA
UZ4IIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAArQIBA5AGACwAAAABAAAAHgBSngggBgAA
AAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41ALwDAQOQBgAkAAAAAQAAAAsAU54IIAYA
AAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAxAIBA5AGACQAAAABAAAAAwBUngggBgAAAAAAwAAA
AAAAAEYAAAAAEYUAAAAAAADAAgEDkAYAJAAAAAEAAAADAFWeCCAGAAAAAADAAAAAAAAARgAA
AAAYhQAAAAAAAMgCAQOQBgAsAAAAAQAAAB4AVp4IIAYAAAAAAMAAAAAAAABGAAAAADaFAAAB
AAAAAQAAAAAAAAAEAwEDkAYALAAAAAEAAAAeAFeeCCAGAAAAAADAAAAAAAAARgAAAAA3hQAA
AQAAAAEAAAAAAAAABgMBA5AGACwAAAABAAAAHgBYngggBgAAAAAAwAAAAAAAAEYAAAAAOIUA
AAEAAAABAAAAAAAAAAgDAQOQBgAkAAAAAQAAAAsAWZ4LIAYAAAAAAMAAAAAAAABGAAAAAACI
AAAAAAAAwgIBA5AGACQAAAABAAAACwBangsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAAAADI
AgEDkAYAJAAAAAEAAAALAFueCCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAMQCAQOQBgAY
AAAAAQAAAB4APQABAAAABQAAAFJFOiAAAAAAUwEBA5AGAAwAAAABAAAAAwCAEP////+QBAEJ
AAQAAgAAAAAAAAABA5AGAAwAAAABAAAACwAjAAAAAAAvAAEDkAYADAAAAAEAAAALACkAAAAA
ADUAAQSQBgDkAgAAAgAAABEAAAADAAAwAwAAAAsADw4AAAAAAgH/DwEAAAA3AAAAAAAAAIEr
H6S+oxAZnW4A3QEPVAIAAAAAcGhvZmZtYW4AU01UUABwaG9mZm1hbkBpbWMub3JnAAAeAAIw
AQAAAAUAAABTTVRQAAAAAB4AAzABAAAAEQAAAHBob2ZmbWFuQGltYy5vcmcAAAAAAwAVDAEA
AAADAP4PBgAAAB4AATABAAAACwAAACdwaG9mZm1hbicAAAIBCzABAAAAFgAAAFNNVFA6UEhP
RkZNQU5ASU1DLk9SRwAAAAMAADkAAAAACwBAOgEAAAADAHE6AAAAAB4A9l8BAAAACQAAAHBo
b2ZmbWFuAAAAAAIB918BAAAANwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHBob2ZmbWFu
AFNNVFAAcGhvZmZtYW5AaW1jLm9yZwAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAA
AAMRAAAAAwAAMAQAAAALAA8OAAAAAAIB/w8BAAAAOQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QC
AAAAAGlldGYtcGtpeABTTVRQAGlldGYtcGtpeEBpbWMub3JnAAAAAB4AAjABAAAABQAAAFNN
VFAAAAAAHgADMAEAAAASAAAAaWV0Zi1wa2l4QGltYy5vcmcAAAADABUMAQAAAAMA/g8GAAAA
HgABMAEAAAAMAAAAJ2lldGYtcGtpeCcAAgELMAEAAAAXAAAAU01UUDpJRVRGLVBLSVhASU1D
Lk9SRwAAAwAAOQAAAAALAEA6AQAAAAMAcToAAAAAHgD2XwEAAAAKAAAAaWV0Zi1wa2l4AAAA
AgH3XwEAAAA5AAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAaWV0Zi1wa2l4AFNNVFAAaWV0
Zi1wa2l4QGltYy5vcmcAAAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAASmhA==

--openmail-part-0d1e16b3-00000001--



Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA16749; Sun, 5 Sep 1999 16:11:31 -0700 (PDT)
Received: from rankney (207-172-184-17.s17.tnt6.lnhva.md.dialup.rcn.com [207.172.184.17]) by smtp3.erols.com (8.8.8/8.8.5) with SMTP id TAA19348; Sun, 5 Sep 1999 19:13:31 -0400 (EDT)
Message-ID: <008d01bef7f5$1e4d8e80$11b8accf@rankney>
From: "Rich Ankney" <[e-mail]>
To: <[e-mail]>, "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
Subject: Re: End-Entity Certificate Policies v. EKU
Date: Sun, 5 Sep 1999 19:19:32 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0

I agree.  I'm still partial to a signature purpose or policy
(IOW an OID), which is more granular than a cert policy
OID, and is orthogonal to EKU.  See, for example, ANSI
X12.58 v2 (the public key version of X12 security), which
has something called "business purpose of assurance."

Regards,
Rich
-----Original Message-----
From: David Solo <[e-mail]>
To: Paul Hoffman / IMC <[e-mail]>; [e-mail]
<[e-mail]>
Date: Sunday, September 05, 1999 7:04 PM
Subject: RE: End-Entity Certificate Policies v. EKU


>Sorry Paul, perhaps my longstanding concerns about EKU led me to overstate
>the point slightly :-)
>
>Nonetheless, for the application applicability examples I had cited, as
well
>as the general notion of "operating under the rules of xxx", I think EKU is
>a poor choice.  Key usage relating to cryptographic function makes sense.
>As it starts to begin to be used to express applicability of the cert for
>different applications (and especially where that rule should be enforced
as
>part of path validation), I think cert policies is a better option.  If I
>were cynical, I'd speculate that some of the current uses of EKU arose from
>the (continuing) problems with implementing certpolicy.
>
>Dave
>
>> -----Original Message-----
>> From: Paul Hoffman / IMC [mailto:[e-mail]]
>> Sent: Saturday, September 04, 1999 6:08 PM
>> To: [e-mail]; [e-mail]
>> Subject: RE: End-Entity Certificate Policies
>>
>>
>> At 04:56 PM 9/4/1999 -0400, [e-mail] wrote:
>> >Exactly.  The lack of constraints on EKU make it a poor choice
>> for this (and
>> >most other of its stated purposes).  In fact, I'd suggest that we should
>> >abolish EKU and handle those items via cert policies.
>>
>> And to hell with the other protocols that use the EKU? IPsec apparently
>> uses EKU values, for example.
>>
>> --Paul Hoffman, Director
>> --Internet Mail Consortium
>>
>
>



Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA16721; Sun, 5 Sep 1999 16:11:09 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sun, 05 Sep 1999 16:12:32 -0700
To: <[e-mail]>, <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: End-Entity Certificate Policies v. EKU
In-Reply-To: <005801bef7f2$ad2b6080$3f0f4f0c@default>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 07:02 PM 9/5/1999 -0400, David Solo wrote:
>Sorry Paul, perhaps my longstanding concerns about EKU led me to overstate
>the point slightly :-)
>
>Nonetheless, for the application applicability examples I had cited, as well
>as the general notion of "operating under the rules of xxx", I think EKU is
>a poor choice.  Key usage relating to cryptographic function makes sense.
>As it starts to begin to be used to express applicability of the cert for
>different applications (and especially where that rule should be enforced as
>part of path validation), I think cert policies is a better option.  If I
>were cynical, I'd speculate that some of the current uses of EKU arose from
>the (continuing) problems with implementing certpolicy.

You may be right on that speculation. However, many (most?) of the IPsec 
vendors who do certs look for the EKU because that's where they were told 
to look. It would be pretty harsh to say to the deployed PKIX world "we're 
getting rid of this thing you rely on because we misdesigned it and we want 
to be sure you can't use it".

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from mtiwmhc04.worldnet.att.net (mtiwmhc04.worldnet.att.net [204.127.131.39]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA16349; Sun, 5 Sep 1999 15:54:09 -0700 (PDT)
Received: from default ([12.79.15.63]) by mtiwmhc04.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id <19990905225613.PXDN6819@default>; Sun, 5 Sep 1999 22:56:13 +0000
Reply-To: <[e-mail]>
From: "David Solo" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
Subject: RE: End-Entity Certificate Policies v. EKU
Date: Sun, 5 Sep 1999 19:02:07 -0400
Message-ID: <005801bef7f2$ad2b6080$3f0f4f0c@default>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211

Sorry Paul, perhaps my longstanding concerns about EKU led me to overstate
the point slightly :-)

Nonetheless, for the application applicability examples I had cited, as well
as the general notion of "operating under the rules of xxx", I think EKU is
a poor choice.  Key usage relating to cryptographic function makes sense.
As it starts to begin to be used to express applicability of the cert for
different applications (and especially where that rule should be enforced as
part of path validation), I think cert policies is a better option.  If I
were cynical, I'd speculate that some of the current uses of EKU arose from
the (continuing) problems with implementing certpolicy.

Dave

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: Saturday, September 04, 1999 6:08 PM
> To: [e-mail]; [e-mail]
> Subject: RE: End-Entity Certificate Policies
>
>
> At 04:56 PM 9/4/1999 -0400, [e-mail] wrote:
> >Exactly.  The lack of constraints on EKU make it a poor choice
> for this (and
> >most other of its stated purposes).  In fact, I'd suggest that we should
> >abolish EKU and handle those items via cert policies.
>
> And to hell with the other protocols that use the EKU? IPsec apparently
> uses EKU values, for example.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>



Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA19395; Sat, 4 Sep 1999 15:05:15 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 04 Sep 1999 15:07:30 -0700
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: End-Entity Certificate Policies
In-Reply-To: <H0000cc4042cc47b@MHS>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:56 PM 9/4/1999 -0400, [e-mail] wrote:
>Exactly.  The lack of constraints on EKU make it a poor choice for this (and
>most other of its stated purposes).  In fact, I'd suggest that we should
>abolish EKU and handle those items via cert policies.

And to hell with the other protocols that use the EKU? IPsec apparently 
uses EKU values, for example.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from citicorp.com (mango1.citicorp.com [192.193.195.140]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA18858 for <[e-mail]>; Sat, 4 Sep 1999 13:54:23 -0700 (PDT)
From: [e-mail]
Received: from spruce.citicorp.com (spruce.citicorp.com [192.193.195.184]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id QAA04415; Sat, 4 Sep 1999 16:53:48 -0400 (EDT)
Received: from x400prod2.cgin.us-md.citicorp.com ([e-mail] [163.39.141.235]) by spruce.citicorp.com (8.8.5/8.8.5) with ESMTP id QAA00423; Sat, 4 Sep 1999 16:56:38 -0400 (EDT)
Received: from saturnalias.email.citicorp.com ([e-mail] [163.39.141.252]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA18551; Sat, 4 Sep 1999 16:56:35 -0400 (EDT)
Received: from localhost (root@localhost) by saturnalias.email.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id QAA18649; Sat, 4 Sep 1999 16:56:36 -0400 (EDT)
X-OpenMail-Hops: 1
Date: Sat, 4 Sep 1999 16:56:26 -0400
Message-Id: <H0000cc4042cc47b@MHS>
Subject: RE: End-Entity Certificate Policies
MIME-Version: 1.0
TO: [e-mail], [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Content-Type: multipart/mixed; boundary="openmail-part-0d1c8194-00000001"

--openmail-part-0d1c8194-00000001
Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT"
Content-Disposition: inline; filename="BDY.TXT"
Content-Transfer-Encoding: 7bit

Exactly.  The lack of constraints on EKU make it a poor choice for this (and 
most other of its stated purposes).  In fact, I'd suggest that we should 
abolish EKU and handle those items via cert policies.

Dave

> -----Original Message-----
> From: thayes [mailto:[e-mail]]
> Sent: Friday, September 03, 1999 1:04 PM
> To: MMyers
> Cc: thayes; David.Solo; housley; ietf-pkix
> Subject: Re: End-Entity Certificate Policies
> 
> 
> Michael (and David),
> 
> For one, I don't think the Extended Key Usage plays a part in 
> validating the
> certificate chain.  Therefore any CA could put the desired 
> Extended Key Usage
> into the EE certificate.  The advantage of using Certificate 
> Policies is that
> the chain validation checks the right of the CAs to issue the 
> certificates at
> each level.
> 
> Terry
> 
> Michael Myers wrote:
> 
> > Dave,
> >
> > Why not use Extended Key Usage to meet requirements on use-specific
> > constraints as you note below (e.g. "OK for email; OK for 
> transactions; OK
> > for intranet access; OK for online banking; etc.") and 
> leave Certificate
> > Policies to assert a metric on the reliability of a 
> certificate, regardless
> > of intended use?  As we know, there is at least one 
> instance of the use of
> > EKU that has the proven the utility of the concept on a 
> broadly deployable
> > basis.
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: Solo, David [mailto:[e-mail]]
> > > Sent: Thursday, September 02, 1999 9:12 AM
> > > To: [e-mail]; [e-mail]
> > > Subject: RE: End-Entity Certificate Policies
> > >
> > >
> > > Just adding my voice to the chorus - I'd strongly object to
> > > limiting EE certs
> > > to a single policy OID.  One of the planned deployment models
> > > uses policy OIDs
> > > as applicability labels (OK for email; OK for transactions;
> > > Ok for intranet
> > > access; OK for online banking; etc.)  These policy OIDs 
> may well be
> > > standardized across multiple issuers/organizations.  Thus, a
> > > given cert may
> > > well have multiple such OIDs present (loosely like having
> > > multiple card network
> > > logos on the back of your ATM/credit card) if approved for
> > > multiple purposes.
> > > This model also makes RP configuration much simpler.
> > >
> > > As to policy qualifiers, you can deprecate them everywhere as
> > > far as I'm
> > > concerned.
> > >
> > > Dave
> > >
> > > > -----Original Message-----
> > > > From: housley [mailto:[e-mail]]
> > > > Sent: Tuesday, August 31, 1999 4:57 PM
> > > > To: ietf-pkix
> > > > Cc: housley
> > > > Subject: End-Entity Certificate Policies
> > > >
> > > >
> > > > Tim Polk and I got together today to discuss the changes
> > > > needed to address
> > > > the policy mapping bug (as discussed at the Oslo meeting).
> > > > As part of this
> > > > discussion, we discussed the certificate policy extension.
> > > >
> > > > We believe that a CA certificate may contain one or more
> > > > certificate policy
> > > > OID.  On the other hand, we believe that an end-entity 
> certificate
> > > > containing a certificate policy extension must  contain a single
> > > > certificate policy OID.  RFC 2459 says:
> > > >
> > > >     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.
> > > >
> > > > We would like to add words to make it more clear that 
> an end-entity
> > > > certificate may only contain a single certificate 
> policy OID.  The
> > > > explanation of this extension's purpose in a CA certificate
> > > > was not spelled
> > > > out, so we propose to fix that too.  Our proposed text is:
> > > >
> > > >     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.  In an
> > > > end-entity certificate,
> > > >     these policy information terms indicate the single policy
> > > > under which
> > > >     the certificate has been issued and the purposes for
> > > > which the certificate
> > > >     may be used.  In a CA certificate,  these policy
> > > information terms
> > > >     limit the set of policies for certification paths which
> > > > include this
> > > >     certificate.  Optional qualifiers, which may be 
> present, are not
> > > >     expected to change the definition of the policy.
> > > >
> > > > Does anyone disagree?
> > > >
> > > > Tim and I also discussed certificate policy qualifiers.  Tim
> > > > and I agree
> > > > that certificate policy qualifiers should only appear 
> in end-entity
> > > > certificates.  That is, we agree that certificate policy
> > > > qualifier should
> > > > never appear in a CA certificate.  Does anyone (besides Mike
> > > > Baum) disagree?
> > > >
> > > > Russ
> > > >
> > >
> 

--openmail-part-0d1c8194-00000001
Content-Type: application/ms-tnef; name="WINMAIL.DAT"
Content-Disposition: attachment; filename="WINMAIL.DAT"
Content-Transfer-Encoding: base64

eJ8+IoblAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5N
aWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEDkAYADAAAAAEAAAADABcAAQAA
ABwAAQOQBgAMAAAAAQAAAAMANgAAAAAAOgABBIABACQAAABSRTogRW5kLUVudGl0eSBDZXJ0
aWZpY2F0ZSBQb2xpY2llcwCNDAEDkAYADAAAAAEAAAALAAIAAQAAAA8AAQOQBgAMAAAAAQAA
AAsAKwAAAAAANwABA5AGAAwAAAABAAAAAwAuAAAAAAAyAAEDkAYANAAAAAEAAAACATEAAQAA
ACEAAAAzN0NGRkY5Qi44REJEOEYwOChhKW5ldHNjYXBlLmNvbQAAAADZCQEDkAYAEAAAAAEA
AABAADkAoFp14xf3vgGZBAEDkAYAHAAAAAEAAAAeAEIAAQAAAAwAAABTb2xvLCBEYXZpZAA/
BAEDkAYAEAAAAAEAAABAAEgAIHV74xf3vgFJBAEDkAYAMAAAAAEAAAAeAHAAAQAAACAAAABF
bmQtRW50aXR5IENlcnRpZmljYXRlIFBvbGljaWVzAEwMAQOQBgAoAAAAAQAAAAIBcQABAAAA
FgAAAAG+9xfjXK+Q4yRjBhHTsy5Q3XIAAAAAAKsJAQOQBgAMAAAAAQAAAAMABhAvv/pXWQIB
A5AGAAwAAAABAAAAAwAHEC0OAABWAAEDkAYAeAAAAAEAAAAeAAgQAQAAAGUAAABFWEFDVExZ
VEhFTEFDS09GQ09OU1RSQUlOVFNPTkVLVU1BS0VJVEFQT09SQ0hPSUNFRk9SVEhJUyhBTkRN
T1NUT1RIRVJPRklUU1NUQVRFRFBVUlBPU0VTKUlORkFDVCxJRFNVAAAAAPIdAQOQBgAMAAAA
AQAAAAMAEBAAAAAAJAABA5AGAAwAAAABAAAAAwAREAgAAAAtAAEDkAYAFAAAAAEAAAAeAEIQ
AQAAAAEAAAAAAAAAcwABA5AGABAAAAABAAAAQAAHMKCLFYYX974BCwQBA5AGABAAAAABAAAA
QAAIMKCLFYYX974BDAQBA5AGACAAAAABAAAAAgELMAEAAAAQAAAAI+OQrwZj0xGzLlDdcgAA
AGIGAQOQBgAMAAAAAQAAAAMA3j+vbwAAPwIBA5AGACQAAAABAAAAAwBulwggBgAAAAAAwAAA
AAAAAEYAAAAAEIUAAAAAAADSAgEDkAYAJAAAAAEAAAADAG+XCCAGAAAAAADAAAAAAAAARgAA
AABShQAA8BMAABgEAQOQBgAkAAAAAQAAAAMAcJcIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAA
AAAAxQIBA5AGACwAAAABAAAAHgBxlwggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAA
OC41ANQDAQOQBgAkAAAAAQAAAAsAcpcIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAA3AIB
A5AGACQAAAABAAAAAwBzlwggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAADYAgEDkAYAJAAA
AAEAAAADAHSXCCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAOACAQOQBgAsAAAAAQAAAB4A
dZcIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAcAwEDkAYALAAAAAEAAAAe
AHaXCCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgMBA5AGACwAAAABAAAA
HgB3lwggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAACADAQOQBgAkAAAAAQAA
AAsAeJcLIAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAA2gIBA5AGACQAAAABAAAACwB5lwsg
BgAAAAAAwAAAAAAAAEYAAAAABYgAAAAAAADgAgEDkAYAJAAAAAEAAAALAHqXCCAGAAAAAADA
AAAAAAAARgAAAAAGhQAAAAAAANwCAQOQBgAYAAAAAQAAAB4APQABAAAABQAAAFJFOiAAAAAA
UwEBA5AGAAwAAAABAAAAAwCAEP////+QBAEJAAQAAgAAAAAAAAABA5AGAAwAAAABAAAACwAj
AAAAAAAvAAEDkAYADAAAAAEAAAALACkAAAAAADUAAQSQBgCgBwAABQAAABEAAAADAAAwBgAA
AAsADw4AAAAAAgH/DwEAAAA4AAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAdGhheWVzAFNN
VFAAdGhheWVzQG5ldHNjYXBlLmNvbQAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAFAAA
AHRoYXllc0BuZXRzY2FwZS5jb20AAwAVDAEAAAADAP4PBgAAAB4AATABAAAACQAAACd0aGF5
ZXMnAAAAAAIBCzABAAAAGQAAAFNNVFA6VEhBWUVTQE5FVFNDQVBFLkNPTQAAAAADAAA5AAAA
AAsAQDoBAAAAAwBxOgAAAAAeAPZfAQAAAAcAAAB0aGF5ZXMAAAIB918BAAAAOAAAAAAAAACB
Kx+kvqMQGZ1uAN0BD1QCAAAAAHRoYXllcwBTTVRQAHRoYXllc0BuZXRzY2FwZS5jb20AAwD9
XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAAYRAAAAAwAAMAcAAAALAA8OAAAAAAIB/w8B
AAAAOAAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE1NeWVycwBTTVRQAE1NeWVyc0B2ZXJp
c2lnbi5jb20AHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAABQAAABNTXllcnNAdmVyaXNp
Z24uY29tAAMAFQwBAAAAAwD+DwYAAAAeAAEwAQAAAAkAAAAnTU15ZXJzJwAAAAACAQswAQAA
ABkAAABTTVRQOk1NWUVSU0BWRVJJU0lHTi5DT00AAAAAAwAAOQAAAAALAEA6AQAAAAMAcToA
AAAAHgD2XwEAAAAHAAAATU15ZXJzAAACAfdfAQAAADgAAAAAAAAAgSsfpL6jEBmdbgDdAQ9U
AgAAAABNTXllcnMAU01UUABNTXllcnNAdmVyaXNpZ24uY29tAAMA/V8BAAAAAwD/XwAAAAAC
AfYPAQAAAAQAAAAAAAAHEQAAAAMAADAIAAAACwAPDgAAAAACAf8PAQAAAFUAAAAAAAAAgSsf
pL6jEBmdbgDdAQ9UAgAAAABEYXZpZC5Tb2xvAFNNVFAARGF2aWQuU29sb0B4NDAwcHJvZDIu
Y2dpbi51cy1tZC5jaXRpY29ycC5jb20AAAAAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAA
AC0AAABEYXZpZC5Tb2xvQHg0MDBwcm9kMi5jZ2luLnVzLW1kLmNpdGljb3JwLmNvbQAAAAAD
ABUMAgAAAAMA/g8GAAAAHgABMAEAAAANAAAAJ0RhdmlkLlNvbG8nAAAAAAIBCzABAAAAMgAA
AFNNVFA6REFWSUQuU09MT0BYNDAwUFJPRDIuQ0dJTi5VUy1NRC5DSVRJQ09SUC5DT00AAAAD
AAA5AAAAAAsAQDoBAAAAAwBxOgAAAAAeAPZfAQAAAAsAAABEYXZpZC5Tb2xvAAACAfdfAQAA
AFUAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABEYXZpZC5Tb2xvAFNNVFAARGF2aWQuU29s
b0B4NDAwcHJvZDIuY2dpbi51cy1tZC5jaXRpY29ycC5jb20AAAAAAwD9XwEAAAADAP9fAAAA
AAIB9g8BAAAABAAAAAAAAAgRAAAAAwAAMAkAAAALAA8OAAAAAAIB/w8BAAAAOAAAAAAAAACB
Kx+kvqMQGZ1uAN0BD1QCAAAAAGhvdXNsZXkAU01UUABob3VzbGV5QHNweXJ1cy5jb20AHgAC
MAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAABMAAABob3VzbGV5QHNweXJ1cy5jb20AAAMAFQwC
AAAAAwD+DwYAAAAeAAEwAQAAAAoAAAAnaG91c2xleScAAAACAQswAQAAABgAAABTTVRQOkhP
VVNMRVlAU1BZUlVTLkNPTQADAAA5AAAAAAsAQDoBAAAAAwBxOgAAAAAeAPZfAQAAAAgAAABo
b3VzbGV5AAIB918BAAAAOAAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAGhvdXNsZXkAU01U
UABob3VzbGV5QHNweXJ1cy5jb20AAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAAkR
AAAAAwAAMAoAAAALAA8OAAAAAAIB/w8BAAAAOQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAA
AGlldGYtcGtpeABTTVRQAGlldGYtcGtpeEBpbWMub3JnAAAAAB4AAjABAAAABQAAAFNNVFAA
AAAAHgADMAEAAAASAAAAaWV0Zi1wa2l4QGltYy5vcmcAAAADABUMAgAAAAMA/g8GAAAAHgAB
MAEAAAAMAAAAJ2lldGYtcGtpeCcAAgELMAEAAAAXAAAAU01UUDpJRVRGLVBLSVhASU1DLk9S
RwAAAwAAOQAAAAALAEA6AQAAAAMAcToAAAAAHgD2XwEAAAAKAAAAaWV0Zi1wa2l4AAAAAgH3
XwEAAAA5AAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAaWV0Zi1wa2l4AFNNVFAAaWV0Zi1w
a2l4QGltYy5vcmcAAAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAArLdA==

--openmail-part-0d1c8194-00000001--



Received: from mail.fred.net (mail.fred.net [204.215.84.6]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA18384 for <[e-mail]>; Sat, 4 Sep 1999 12:59:43 -0700 (PDT)
Received: from bigdog.fred.net (bigdog.fred.net [204.215.84.3]) by mail.fred.net (Postfix) with ESMTP id A1FCF2A25A for <[e-mail]>; Sat,  4 Sep 1999 16:01:56 -0400 (EDT)
Received: from hb71f (user208-238-77-236.fred.net [208.238.77.236]) by bigdog.fred.net (8.9.1b+Sun/8.9.1) with SMTP id QAA26095 for <[e-mail]>; Sat, 4 Sep 1999 16:01:55 -0400 (EDT)
Message-ID: <001801bef729$fbdae8a0$ec4deed0@hb71f>
From: "Khalid Asad" <[e-mail]>
To: <[e-mail]>
Subject: subscribe
Date: Sat, 4 Sep 1999 16:05:29 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01BEF6EF.4EB2A620"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01BEF6EF.4EB2A620
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

subscribe

------=_NextPart_000_0015_01BEF6EF.4EB2A620
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 size=3D2>subscribe</FONT></DIV></BODY></HTML>

------=_NextPart_000_0015_01BEF6EF.4EB2A620--



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA03013 for <[e-mail]>; Fri, 3 Sep 1999 15:39:17 -0700 (PDT)
Received: from nma.com (pm09-44.sac.verio.net [209.162.65.157]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id PAA20689; Fri, 3 Sep 1999 15:41:38 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 03 Sep 1999 15:41:40 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: NR bit absence, was Re: Deprecate the NR bit?
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tony Bartoletti wrote:

> Of course, many signing applications, I presume, require only the
> private key, and care nothing of how the corresponding public key
> was certified.  Hence, in the absense of a 1-to-1 relationship
> between keys and certificates, and signing applications that care,
> this discussion seems academic in the extreme.

Good point. But, no, it highlights the fact that there are now TWO
signing procedures for ONE key, so that the former implict 1:1
relationship between ONE signing policy (DS) for ONE key is
no longer valid.

The 1:1 thus breaks down, and it does so quite perversely, towards
the default ACK for NR instead of a default NACK for NR -- as I
commented and exemplified in several cases.

This just highlights the fact that there is no real-world usage model
for NR in PKIX.  It is not just the NR bit definition that needs to be,
hmmm... defined.  It is the framework and the threat model that are also
missing and would need to be defined for NR to be useful.  That is
why so many PKIX NR examples are rebuked here. And, this is what
Bob Jueneman was trying to say IMO when he called for the NR bit
to be deprecated but, as I commented, this would be the worse option
and this WG  needs to start from somewhere in the NR issue.

In this regard, again, I think that Tom's RFC is the most one can have at
this moment and should be supported as a starting point.  And, one
should not close the door on detecting NR bit absence -- not even in
the name of simplicity.  Because it won't work that way and all the effort
to improve the definition of NR in PKIX would be mostly moot if NR is
to be confused at the application level.

Thus, let the applications that want to use the NR bit worry about
how that linking will be made -- perhaps, quite simply, by checking
the corresponding public-key cert that the keyholder must have a copy
of, for presence/absence of the DS and NR bits. And, later on, by
cheking the private-key cert if and when asserting DS and NR bits
is well-defined and relied upon in private-key certs.

Cheers,

Ed Gerck




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA02627 for <[e-mail]>; Fri, 3 Sep 1999 15:12:57 -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 SAA25868; Fri, 3 Sep 1999 18:15:10 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a15b3f5f830c624@[128.89.0.110]>
In-Reply-To: <007a01bef48f$e9d98540$[e-mail]>
References: <000701bef46c$bdab0660$0500000a@npwork2>
Date: Fri, 3 Sep 1999 18:14:57 -0400
To: "todd@gmtsw" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: X509 Language - Was Re: New Internet Draft on Non-Repudiation Requirements
Cc: <[e-mail]>

Todd,

While I appreciate your persistant devotion to a model in which some form
of high assurance, distributed time stamps play a central role, I don't
agree with your interpretation of X.509 requirements re timestamps and
CRLs.  Your interpretation is not consistent with the overall context in
which the X.509 and PKIX standards have been formulated.

Steve


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA02212 for <[e-mail]>; Fri, 3 Sep 1999 14:38:10 -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 OAA04030; Fri, 3 Sep 1999 14:40:34 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 03 Sep 1999 14:40:35 -0700
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: NR bit absence, was Re: Deprecate the NR bit?
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:09 PM 9/3/99 -0700, Tony Bartoletti wrote:

Addendum:  See below.

>At 03:44 PM 9/3/99 -0400, David P. Kemp wrote:
>>
>>> Date: Fri, 03 Sep 1999 11:17:36 -0700
>>> From: Ed Gerck <[e-mail]>
>>> 
>>> * Applications that do signature require that the key
>>>    signature bit be set, and ignore the rest.
>>> 
>>> which would imply that such applications would sign a message as
>>> NR ... just because the cert NR bit was set ... and ignored.  So, the
>>> application would do what was NOT requested by defaulting to an
>>> ACK when the NR bit is detected, instead of defaulting to an
>>> NACK  -- a common mistake in protocols.
>>
>>
>>This presupposes that there are "applications which sign a message as
>>NR" as well as "applications which sign a message as non-NR"; we are
>>attempting to clarify the (non-)validity of that presumption.
>
>By "signs a message as NR", I am sure Ed simply means "signs a message
>with the key in question", which can subsequently be shown to have been
>certified with "NR=1".  Thus the relying party, or who-knows-who, may
>attempt to assert NR even though the application may not have cared.
>
>Is this point in dispute?
>
>According to your earlier post, a PKIX-conforming application could apply
>"signature" if the signature bit is set, and ignore any possible NR-bit
>setting.  This is at least a clear position.  You also write that a PKIX-
>conforming CA would not issue certain combinations of key usage bits.
>
>This is a bit vague.  Does (CA) PKIX-conformance preclude "SIG+NR" set?
>And would signing applications know that a CA is PKIX-conformant by
>virtue of the certificate?
>
>Without a definitive "Yes" to both of the last questions, we could have 
>"conformance all around" and still end up with the situation Ed mentions.
>
>Of course, a signing application could simply refuse certs with both
>SIG+NR set, but it would not be required of conformance.

(Addendum):

Of course, many signing applications, I presume, require only the
private key, and care nothing of how the corresponding public key
was certified.  Hence, in the absense of a 1-to-1 relationship
between keys and certificates, and signing applications that care,
this discussion seems academic in the extreme. 



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


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA02031 for <[e-mail]>; Fri, 3 Sep 1999 14:31:52 -0700 (PDT)
Received: from nma.com (pm09-44.sac.verio.net [209.162.65.157]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id OAA05067; Fri, 3 Sep 1999 14:34:14 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 03 Sep 1999 14:34:16 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: NR bit absence, was Re: Deprecate the NR bit?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:

> > Date: Fri, 03 Sep 1999 11:17:36 -0700
> > From: Ed Gerck <[e-mail]>
> >
> > * Applications that do signature require that the key
> >    signature bit be set, and ignore the rest.
> >
> > which would imply that such applications would sign a message as
> > NR ... just because the cert NR bit was set ... and ignored.  So, the
> > application would do what was NOT requested by defaulting to an
> > ACK when the NR bit is detected, instead of defaulting to an
> > NACK  -- a common mistake in protocols.
>
> This presupposes that there are "applications which sign a message as
> NR" as well as "applications which sign a message as non-NR"; we are
> attempting to clarify the (non-)validity of that presumption.

No, let me try to make it clearer. My argument pressuposes (as you also
do) that there are:

a. certs with the DS bit set --> they sign
b. certs with NR bit set --> they sign with NR services

and now, if we recall that the DS and NR bits are independent, to be
compliant with  RFC 2459, Section 4.2.1.3:

 "This profile does not restrict the combinations of bits that may
 be set in an instantiation of the keyUsage extension."

then two (bad) things would happen if NR absence is NOT detected
before signing:

1. a cert with NR bit set could be used by mistake for signing with NR,
since the application for (example) would not be required to pop-up a dialogue
box saying "Are you sure you want to assert non-repudiation as PKIX
has defined it?"  Of course, one may also have an automatic option (for
example, "Check this box in order to always grant NR confirmation") for
NR, but this should be for the user to decide.  So, the application MUST
provide the capability for a user to verify absence of the NR bit, or
to turn it always on if so desired, or grant it case by case with a dialogue.
To do otherwise is to allow NR services to be asserted when they are
not desired.

2. certs with the DS and the NR bit set are possible -- which means that
an application that needs to detect the DS bit but is not required to check
for absence  of the NR bit would automatically sign a message with
NR... when that  was not originally intended at all.

Thus, instead of  deleting the bit-independence rule of RFC 2459,
Section 4.2.1.3 (which rule you also agree with) in order to prevent
(2) above and then invent all sorts of allowed and forbidden
octect-codes, the solution should be to recognize, as I wrote before:

 As a general principle, compliant PKIX applications MUST require
 the absence of a particular key usage bit in certain situations, for
 example, by requiring absence of the NR bit in the key cert when the
 message to be signed by the corresponding key does not use NR
 services.

Note that this would not preclude automatic NR signing (ie, without
human intervention, as you want) since someone/something can
previously check a control option that confirms *all* messages as
NR.  Which, BTW, is much safer than having all applications blindly
and out of the box assume NR for all and every message, no? Here,
at least, someone/something had to *previously* confirm the desire
to use automatic NR.

A useful comparison can be seen in the Unix command rm.  Of course,
you can use rm if you want and then immediately delete any file with
full non-repudiation -- even if you type "rm *". But, that is why it is
possible, useful and very common to instruct the shell to use "rm -i"
whenever you type rm -- so that you have a chance to repudiate your
"death penalty" command.

BTW, the Unix command rm provides an example of technical
non-repudiation. And why one needs to be very careful with
asserting non-repudiation.  Especially, automatic non-repudiation
that runs amok out of the box without any chance for controlled
testing before -- but, the NR bug is a deadly bug ;-).. not a simple
"Error: reboot your system".

I hope to have provided above yet more reasons why the NR bit
needs to be tested for absence (or, for lack of presence -- which is
the same), besides the two that I gave before.   But, there are many
more examples of this logic, also if you go to higher orders, for
example when a NR service (whatever that might be) is triggered
by receiving a NR message from another service (in order to be
on the same level of response) -- then, you may get a NR message
from a service due to a NR fault from another one that ignored the
double presence of the DS and the NR bit and assumed it was NR.

Cheers,

Ed Gerck




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA01735 for <[e-mail]>; Fri, 3 Sep 1999 14:07:28 -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 OAA17775; Fri, 3 Sep 1999 14:09:43 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 03 Sep 1999 14:09:44 -0700
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: NR bit absence, was Re: Deprecate the NR bit?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 03:44 PM 9/3/99 -0400, David P. Kemp wrote:
>
>> Date: Fri, 03 Sep 1999 11:17:36 -0700
>> From: Ed Gerck <[e-mail]>
>> 
>> * Applications that do signature require that the key
>>    signature bit be set, and ignore the rest.
>> 
>> which would imply that such applications would sign a message as
>> NR ... just because the cert NR bit was set ... and ignored.  So, the
>> application would do what was NOT requested by defaulting to an
>> ACK when the NR bit is detected, instead of defaulting to an
>> NACK  -- a common mistake in protocols.
>
>
>This presupposes that there are "applications which sign a message as
>NR" as well as "applications which sign a message as non-NR"; we are
>attempting to clarify the (non-)validity of that presumption.

By "signs a message as NR", I am sure Ed simply means "signs a message
with the key in question", which can subsequently be shown to have been
certified with "NR=1".  Thus the relying party, or who-knows-who, may
attempt to assert NR even though the application may not have cared.

Is this point in dispute?

According to your earlier post, a PKIX-conforming application could apply
"signature" if the signature bit is set, and ignore any possible NR-bit
setting.  This is at least a clear position.  You also write that a PKIX-
conforming CA would not issue certain combinations of key usage bits.

This is a bit vague.  Does (CA) PKIX-conformance preclude "SIG+NR" set?
And would signing applications know that a CA is PKIX-conformant by
virtue of the certificate?

Without a definitive "Yes" to both of the last questions, we could have 
"conformance all around" and still end up with the situation Ed mentions.

Of course, a signing application could simply refuse certs with both
SIG+NR set, but it would not be required of conformance.

___tony___

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


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA00768 for <[e-mail]>; Fri, 3 Sep 1999 12:43:49 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA24314 for <[e-mail]>; Fri, 3 Sep 1999 15:46:16 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA24310 for <[e-mail]>; Fri, 3 Sep 1999 15:46:15 -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 PAA15508 for <[e-mail]>; Fri, 3 Sep 1999 15:46:01 -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 PAA02458 for <[e-mail]>; Fri, 3 Sep 1999 15:44:17 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 3 Sep 1999 15:44:17 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: NR bit absence, was Re: Deprecate the NR bit?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: vexbNCRE1viPihXp7iNJpg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> Date: Fri, 03 Sep 1999 11:17:36 -0700
> From: Ed Gerck <[e-mail]>
> 
> * Applications that do signature require that the key
>    signature bit be set, and ignore the rest.
> 
> which would imply that such applications would sign a message as
> NR ... just because the cert NR bit was set ... and ignored.  So, the
> application would do what was NOT requested by defaulting to an
> ACK when the NR bit is detected, instead of defaulting to an
> NACK  -- a common mistake in protocols.


This presupposes that there are "applications which sign a message as
NR" as well as "applications which sign a message as non-NR"; we are
attempting to clarify the (non-)validity of that presumption.

One possible outcome of Tom's draft is a definition of "applications
which can support NR" and "applications which use a digital signature
in a manner which does not support NR".  Under such a definition, any
application which signs a "message" falls into the first category and
would require the NR bit to be set, and an application which signs
something else would only require the DS bit.   Under this definition,
it doesn't matter if a human user saw what was signed, or intended to
sign what was signed, or performed some special ceremony to enable the
signing.  Under this definition, an automatically-generated email
receipt can support NR if signed with an NR key, because the receipt is
a signed object that is intended to be verified after the connection
over which it was sent is closed.

A digital signature used to authenticate the connection (TLS, IPSEC,
SSH, ...) over which a message was sent would not generate a signature
that was intended to be verified after the termination of the
connection (notwithstanding Peter W's position on trespassing), and
thus would require the DS bit to be set.



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29499 for <[e-mail]>; Fri, 3 Sep 1999 11:15:14 -0700 (PDT)
Received: from nma.com (pm09-01.sac.verio.net [209.162.65.114]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id LAA18621; Fri, 3 Sep 1999 11:17:34 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 03 Sep 1999 11:17:36 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: kent <@ara.missi.ncsc.mil:[e-mail]>, BJUENEMAN <@ara.missi.ncsc.mil:[e-mail]>, "[e-mail]" <[e-mail]>
Subject: NR bit absence, was Re: Deprecate the NR bit?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:

> I hope that we all agree that as a general principle, applications
> do not require the absence of any particular key usage bit:
>
>  * Applications that do encryption require that the key
>    transport/agreement bits be set, and ignore the signature and cert
>    signing bits.
>
>  * Applications that verify cert paths require that the
>    cert/CRL signing bits be set, and ignore the signature and
>    encryption bits.
>
>  * Applications that support "non-repudiation" (however that is eventually
>    defined) require that the NR bit be set and ignore the rest.
>
> ....there is no need for certain applications to require the
> absence of the NR bit -- PKIX-conforming applications would simply
> require the *presence* of the key usage bit appropriate to the operation
> being performed, while PKIX-conforming CAs would not issue certain
> combinations of key usage bits.

Dave:

Sorry to disturb the "all agree", but let me continue the list above:

* Applications that do signature require that the key
   signature bit be set, and ignore the rest.

which would imply that such applications would sign a message as
NR ... just because the cert NR bit was set ... and ignored.  So, the
application would do what was NOT requested by defaulting to an
ACK when the NR bit is detected, instead of defaulting to an
NACK  -- a common mistake in protocols.

Note also that this cannot solved by PKIX-conforming CAs not issuing
certain combinations of key usage bits (even if we forget that RFC 2459,
Section 4.2.1.3  says the very opposite) -- because, what is there NOT  to
issue? One must have the signature bit *with* the NR bit in order to
sign *and* assert usage of NR services (whatever NR is decided to be),
which means that this combination of the two bits is compliant and
useful -- and yet, would lead to an application wrongly signing a msg
as NR because *absence* of the NR bit was not checked by the application.
You would need *more* keyUsage bits to do what you propose and you
would need to revoke Section 4.2.1.3, and still not solve the problem as
further analysis would show.

The solution is however simple, though it reverses what you said.
As a general principle, compliant PKIX applications MUST require
the absence of a particular key usage bit in certain situations, for
example, by requiring absence of the NR bit in the key cert when the
message to be signed by the corresponding key does not use NR
services.

> Note: I agree with the current text of RFC 2459 Section 4.2.1.3:
> "This profile does not restrict the combinations of bits that may
> be set in an instantiation of the keyUsage extension."

Me too.  And this is another reason to let applications require
absence of bits in certain cases.  And, absence of the NR bit can have
three meanings, as I commented before, which also need to be
made clear somewhere.

Cheers,

Ed Gerck




Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA28471 for <[e-mail]>; Fri, 3 Sep 1999 10:01:52 -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 KAA29346 for <[e-mail]>; Fri, 3 Sep 1999 10:03:45 -0700 (PDT)
Received: from netscape.com ([206.222.244.26]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP id FHHU2800.GDE; Fri, 3 Sep 1999 10:03:44 -0700 
Message-ID: <[e-mail]>
Date: Fri, 03 Sep 1999 10:04:27 -0700
From: [e-mail] (Terry Hayes)
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: "Solo David" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: End-Entity Certificate Policies
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael (and David),

For one, I don't think the Extended Key Usage plays a part in validating the
certificate chain.  Therefore any CA could put the desired Extended Key Usage
into the EE certificate.  The advantage of using Certificate Policies is that
the chain validation checks the right of the CAs to issue the certificates at
each level.

Terry

Michael Myers wrote:

> Dave,
>
> Why not use Extended Key Usage to meet requirements on use-specific
> constraints as you note below (e.g. "OK for email; OK for transactions; OK
> for intranet access; OK for online banking; etc.") and leave Certificate
> Policies to assert a metric on the reliability of a certificate, regardless
> of intended use?  As we know, there is at least one instance of the use of
> EKU that has the proven the utility of the concept on a broadly deployable
> basis.
>
> Mike
>
> > -----Original Message-----
> > From: Solo, David [mailto:[e-mail]]
> > Sent: Thursday, September 02, 1999 9:12 AM
> > To: [e-mail]; [e-mail]
> > Subject: RE: End-Entity Certificate Policies
> >
> >
> > Just adding my voice to the chorus - I'd strongly object to
> > limiting EE certs
> > to a single policy OID.  One of the planned deployment models
> > uses policy OIDs
> > as applicability labels (OK for email; OK for transactions;
> > Ok for intranet
> > access; OK for online banking; etc.)  These policy OIDs may well be
> > standardized across multiple issuers/organizations.  Thus, a
> > given cert may
> > well have multiple such OIDs present (loosely like having
> > multiple card network
> > logos on the back of your ATM/credit card) if approved for
> > multiple purposes.
> > This model also makes RP configuration much simpler.
> >
> > As to policy qualifiers, you can deprecate them everywhere as
> > far as I'm
> > concerned.
> >
> > Dave
> >
> > > -----Original Message-----
> > > From: housley [mailto:[e-mail]]
> > > Sent: Tuesday, August 31, 1999 4:57 PM
> > > To: ietf-pkix
> > > Cc: housley
> > > Subject: End-Entity Certificate Policies
> > >
> > >
> > > Tim Polk and I got together today to discuss the changes
> > > needed to address
> > > the policy mapping bug (as discussed at the Oslo meeting).
> > > As part of this
> > > discussion, we discussed the certificate policy extension.
> > >
> > > We believe that a CA certificate may contain one or more
> > > certificate policy
> > > OID.  On the other hand, we believe that an end-entity certificate
> > > containing a certificate policy extension must  contain a single
> > > certificate policy OID.  RFC 2459 says:
> > >
> > >     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.
> > >
> > > We would like to add words to make it more clear that an end-entity
> > > certificate may only contain a single certificate policy OID.  The
> > > explanation of this extension's purpose in a CA certificate
> > > was not spelled
> > > out, so we propose to fix that too.  Our proposed text is:
> > >
> > >     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.  In an
> > > end-entity certificate,
> > >     these policy information terms indicate the single policy
> > > under which
> > >     the certificate has been issued and the purposes for
> > > which the certificate
> > >     may be used.  In a CA certificate,  these policy
> > information terms
> > >     limit the set of policies for certification paths which
> > > include this
> > >     certificate.  Optional qualifiers, which may be present, are not
> > >     expected to change the definition of the policy.
> > >
> > > Does anyone disagree?
> > >
> > > Tim and I also discussed certificate policy qualifiers.  Tim
> > > and I agree
> > > that certificate policy qualifiers should only appear in end-entity
> > > certificates.  That is, we agree that certificate policy
> > > qualifier should
> > > never appear in a CA certificate.  Does anyone (besides Mike
> > > Baum) disagree?
> > >
> > > Russ
> > >
> >



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA28132 for <[e-mail]>; Fri, 3 Sep 1999 09:44:12 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA21189; Fri, 3 Sep 1999 09:44:31 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id AAA18624; Fri, 3 Sep 1999 00:18:30 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <RKAY12R3>; Fri, 3 Sep 1999 00:18:31 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "Solo, David" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: End-Entity Certificate Policies
Date: Fri, 3 Sep 1999 00:18:31 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Dave,

Why not use Extended Key Usage to meet requirements on use-specific
constraints as you note below (e.g. "OK for email; OK for transactions; OK
for intranet access; OK for online banking; etc.") and leave Certificate
Policies to assert a metric on the reliability of a certificate, regardless
of intended use?  As we know, there is at least one instance of the use of
EKU that has the proven the utility of the concept on a broadly deployable
basis. 

Mike


> -----Original Message-----
> From: Solo, David [mailto:[e-mail]]
> Sent: Thursday, September 02, 1999 9:12 AM
> To: [e-mail]; [e-mail]
> Subject: RE: End-Entity Certificate Policies
> 
> 
> Just adding my voice to the chorus - I'd strongly object to 
> limiting EE certs 
> to a single policy OID.  One of the planned deployment models 
> uses policy OIDs 
> as applicability labels (OK for email; OK for transactions; 
> Ok for intranet 
> access; OK for online banking; etc.)  These policy OIDs may well be 
> standardized across multiple issuers/organizations.  Thus, a 
> given cert may 
> well have multiple such OIDs present (loosely like having 
> multiple card network 
> logos on the back of your ATM/credit card) if approved for 
> multiple purposes.  
> This model also makes RP configuration much simpler.  
> 
> As to policy qualifiers, you can deprecate them everywhere as 
> far as I'm 
> concerned.
> 
> Dave
> 
> > -----Original Message-----
> > From: housley [mailto:[e-mail]]
> > Sent: Tuesday, August 31, 1999 4:57 PM
> > To: ietf-pkix
> > Cc: housley
> > Subject: End-Entity Certificate Policies
> > 
> > 
> > Tim Polk and I got together today to discuss the changes 
> > needed to address 
> > the policy mapping bug (as discussed at the Oslo meeting).  
> > As part of this 
> > discussion, we discussed the certificate policy extension.
> > 
> > We believe that a CA certificate may contain one or more 
> > certificate policy 
> > OID.  On the other hand, we believe that an end-entity certificate 
> > containing a certificate policy extension must  contain a single 
> > certificate policy OID.  RFC 2459 says:
> > 
> >     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.
> > 
> > We would like to add words to make it more clear that an end-entity 
> > certificate may only contain a single certificate policy OID.  The 
> > explanation of this extension's purpose in a CA certificate 
> > was not spelled 
> > out, so we propose to fix that too.  Our proposed text is:
> > 
> >     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.  In an 
> > end-entity certificate,
> >     these policy information terms indicate the single policy 
> > under which
> >     the certificate has been issued and the purposes for 
> > which the certificate
> >     may be used.  In a CA certificate,  these policy 
> information terms
> >     limit the set of policies for certification paths which 
> > include this
> >     certificate.  Optional qualifiers, which may be present, are not
> >     expected to change the definition of the policy.
> > 
> > Does anyone disagree?
> > 
> > Tim and I also discussed certificate policy qualifiers.  Tim 
> > and I agree 
> > that certificate policy qualifiers should only appear in end-entity 
> > certificates.  That is, we agree that certificate policy 
> > qualifier should 
> > never appear in a CA certificate.  Does anyone (besides Mike 
> > Baum) disagree?
> > 
> > Russ
> > 
> 


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA27846 for <[e-mail]>; Fri, 3 Sep 1999 09:30:31 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA18352; Fri, 3 Sep 1999 09:30:51 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id AAA18629; Fri, 3 Sep 1999 00:18:33 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <RKAY12RQ>; Fri, 3 Sep 1999 00:18:34 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Russ Housley <[e-mail]>, [e-mail]
Subject: RE: End-Entity Certificate Policies
Date: Fri, 3 Sep 1999 00:18:32 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Russ,

For clarification of my position, I am observing that the jurisdictional
authority under which a cross-certificate was issued to an existing CA may
differ from the jurisdictional authority governing issuance of end-entity
certificates intended to validate beneath that cross-certificate.

Two such jurisdictions may be represented by, among other things, different
certificate policy OIDs.  To the extent that a certificate policy OID maps
directly to a CPS, it follows that the qualifer used to point to these CPSs
would likewise differ.

Since a cross-certificate is by definition a CA certificate, it follows that
2459 must permit a CA certificate to contain a CPS pointer.

Mike




> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Thursday, September 02, 1999 12:33 PM
> To: [e-mail]
> Subject: RE: End-Entity Certificate Policies
> Mike Myers suggests that CA certificates should be permitted 
> to include the CPS pointer qualifier.  Let's assume that
> there is a simple path of two certificates, the CA certificate
> and the end-entity certificate.  The CA  certificate has two
> certificate policy OIDs, each with a CPS pointer qualifier.
> The end-entity certificate has a single certificate policy OID, 
> also with a CPS pointer qualifier.  When the certificate path 
> validation algorithm is executed, one of the outputs will be
> the certificate policy OID that is common to both certificates
> and the two qualifiers (one from the CA certificate and one
> from the end-entity certificate).  What is the  certificate
> user expected to do?  If the URLs are different, the 
> certificate user really has no idea what to do.
> 
> Russ
> 


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA25503 for <[e-mail]>; Fri, 3 Sep 1999 07:27:37 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA08613 for <[e-mail]>; Fri, 3 Sep 1999 10:30:05 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA08609 for <[e-mail]>; Fri, 3 Sep 1999 10:30:05 -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 KAA11454 for <[e-mail]>; Fri, 3 Sep 1999 10:29:50 -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 KAA02335 for <[e-mail]>; Fri, 3 Sep 1999 10:28:06 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 3 Sep 1999 10:28:06 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: End-Entity Certificate Policies
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: WBoLCFDLl3jHeQzA4fKCsQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Isn't the extended key usage extension present for precisely the purpose
of containing "applicability label" OIDs?



> From: [e-mail]
> 
> Just adding my voice to the chorus - I'd strongly object to limiting EE certs 
> to a single policy OID.  One of the planned deployment models uses policy OIDs 
> as applicability labels (OK for email; OK for transactions; Ok for intranet 
> access; OK for online banking; etc.)  These policy OIDs may well be 
> standardized across multiple issuers/organizations.  Thus, a given cert may 
> well have multiple such OIDs present (loosely like having multiple card 
network 
> logos on the back of your ATM/credit card) if approved for multiple purposes.  
> This model also makes RP configuration much simpler.




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA25182 for <[e-mail]>; Fri, 3 Sep 1999 07:19:04 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA07386 for <[e-mail]>; Fri, 3 Sep 1999 10:20:02 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA07382 for <[e-mail]>; Fri, 3 Sep 1999 10:20: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 KAA11336 for <[e-mail]>; Fri, 3 Sep 1999 10:19:47 -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 KAA02330; Fri, 3 Sep 1999 10:17:56 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 3 Sep 1999 10:17:56 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Deprecate the NR bit?
To: [e-mail]@ara.missi.ncsc.mil, [e-mail]@ara.missi.ncsc.mil
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ag1wDRQE2rP9h4dz1+gwzA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Bob Jueneman" <[e-mail]>
> 
> Although I strongly agree with the concept of requiring either the presence or 
> the absence of the NR bit with respect to certain applications, at this point 
the 
> meaning, and hence the value of the bit has been so degraded that personally,
> I despair of ever getting the horses back into the barn.


I hope that we all agree that as a general principle, applications
do not require the absence of any particular key usage bit:

 * Applications that do encryption require that the key
   transport/agreement bits be set, and ignore the signature and cert
   signing bits.

 * Applications that verify cert paths require that the
   cert/CRL signing bits be set, and ignore the signature and
   encryption bits.

 * Applications that support "non-repudiation" (however that is eventually
   defined) require that the NR bit be set and ignore the rest.
   
A community expresses its intent to prohibit the use of a particular
keypair for a particular combination of purposes by writing a
certificate profile that prohibits the corresponding bits from being
set simultaneously by a CA, and by requiring conformance to the
community certificate profile as a condition of extending trust to
that CA.

If, by some stretch of the imagination, the entire Internet Community
reached agreement that certain other key usages are incompatible with
"supporting non-repudiation", then that consensus could be elevated to
the PKIX CA conformance profile.  But even if such an agreement were
reached, there is no need for certain applications to require the
absence of the NR bit -- PKIX-conforming applications would simply
require the *presence* of the key usage bit appropriate to the operation
being performed, while PKIX-conforming CAs would not issue certain
combinations of key usage bits.

Note: I agree with the current text of RFC 2459 Section 4.2.1.3:
"This profile does not restrict the combinations of bits that may
be set in an instantiation of the keyUsage extension."



Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA14504 for <[e-mail]>; Thu, 2 Sep 1999 21:20:59 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <S1ACJS9N>; Fri, 3 Sep 1999 14:23:18 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC10785B@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: SCVP-01
Date: Fri, 3 Sep 1999 14:23:15 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain

Is the only thing difficult about a PKI iin its current way of evolution
- is which protocol do I use and where when and why...

I was quite happy in the good old days with signed DAP to X.500
(trusted) distributed directories using CRL and certficate component
matching rules and adding a few objects and processes to things to
provide different ways of dealing with status and validity . 
eg. It seems we can extend directory search matching rules to deal with
component matches (as per X.500/9), could we not also extend these to
deal with status and validation? ie take an object oriented approach to
information processing over a common protocol -

Rather than -  lets have a new protocol for every type of object
processing semantic....:-((( 

I hope traffic lights and air traffic control systems dont get too many
protocols:-)

regards as always

> -----Original Message-----
> From:	David P. Kemp 
> Sent:	Wednesday, September 01, 1999 11:07 PM
> To:	[e-mail]; [e-mail]
> Cc:	[e-mail]
> Subject:	RE: SCVP-01
> 
> 
> > From: "Peter Williams" <[e-mail]>
> > 
> > Policy WG, and reuse: I would like to see the SCVP
> > specification take component form, enabling its
> > object to be reused in the extension mechanisms of other
> > suitable value-adding services, including CMP and DCS.
> 
> 
> I would like to see that too.  It's in the spirit of the (now-defunct)
> Certificate Management Message Format (CMMF):
> 
>  * define a set of messages, and define the sequence of messages
> exchanged
>     to perform a particular action.
>  * encapsulate/protect the messages using whatever transport/security
>     mechanism (CMP, CMS, DCS, AH/ESP, ...) fits the bill.
> 
> Defining transport-independent message sets for specific purposes
> reduces the difference between "a lot of single-purpose protocols" and
> "one big do-everything protocol", enables reuse of existing transport
> modules/APIs, and as a design paradigm should be a no-brainer.
> 
> Whatever happened to CMMF anyway?  Is this the time to revive it,
> before
> CMP and CMC go to Draft?


Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA11175 for <[e-mail]>; Thu, 2 Sep 1999 19:13:33 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <S1ACJS78>; Fri, 3 Sep 1999 12:15:50 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC107852@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Paul Hoffman / VPNC'" <[e-mail]>, Alan Lloyd <[e-mail]>, [e-mail]
Subject: RE: SCVP-01
Date: Fri, 3 Sep 1999 12:15:48 +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"

Interesting views - 

> -----Original Message-----
> From:	Paul Hoffman / VPNC 
> Sent:	Wednesday, September 01, 1999 2:29 AM
> To:	Alan Lloyd; [e-mail]
> Subject:	RE: SCVP-01
> 
> At 05:21 PM 8/31/1999 +1000, Alan Lloyd wrote:
> >         snip
> > > Yes, we could put in a bunch of changes in OCSP to make it
> > > work, but you would end up changing the semantics of a large
> > > part of OCSP.
> > >
> >         its best to add a few features to a trusted transport that
> >serves a common operational function (cert status and validation)
> than
> >reinvent the whole box and dice again - re key management, protocol
> hddr
> >formats, routing references, etc, etc - and also introduce
> compatibility
> >and interoperability when both technologies are used in the same
> >operational system.
> 
> Yes, that's probably true. SCVP doesn't do any of that. This seems
> like a 
> red herring.
> 
	But SCVP is signed - the same as OCSP - and that needs key mgt
and certs, etc.. So why have two "trusted protocols" for dealing with
cert validation and status and all that gets carried with it for the
customers to deal with.

	I once heard a strory which was wrong of course which said that
OSI (and X.500) was complex and slow because of its options proposed at
each layer of functionality .. This of course has over time proved to be
wrong. 
	In this case of OCSP/SCVP we have "simple protocols "
duplicating many common features thus causing more configuration and key
management effort - for product developers, suppliers and customers -
needlessly

	Why in vent a new protocol when we can just process a protocol's
parameter?. 

> >         One only has to think of the customer and what they want...
> >simpler systems, less code changes, less protocols, less databases
> and
> >less configuration and more capability and trust  -  to see what the
> >logical answer is..
> 
> Yes, that's probably true. Do you think that adding the SCVP
> functionality 
> to OCSP would not involve more complicated systems and more code
> changes? 
> Of course, it is one more protocol, but if you're talking bits on the
> wire, 
> the SVCP request and response are carried on the same protocols as
> OCSP. I 
> don't know what you mean by more databases or more configuration. If
> you 
> want to get the functionality of SCVP in OCSP, you'll need to have the
> same 
> databases and configuration, and the same capability and trust.
> 
	May I explain the diffrenece between "the bytes on wire" - a
protocol spec and an operational product.
	Those who make the protocol will require the end systems to have
configuration of endpoints, time outs, stack references, key management,
etc and if OCSP is used as well those will need similar information -
and operational management.

	So why repeat the implementation for the support mechanisms for
YAP when one can add a few parameters and the application processing
only for an existing protocol?

	It one of product packaging, ease of configuration and
operational effort and of course - dealing with what customers want
(simpler interoperable systems) and not inventing YAP because it sounds
like  a good R&D project.


> Or are you saying that none of the SCVP features are desired by
> anyone?
	No - I just think this can be done with additional fields in
OCSP - rather than just another YAP... I n this discussion - what sort
of stystems do you build. How do you relate trust, risk, reliability and
key management effort  -- its like LDAP servers -
	replicate everything to everywhere = lower trust, low integrity
and operational cost.
	ditto systems that use OCSP in some places and YAP (SCVP) in
others = lower trust, low integrity and higher operational costs.


> >         Why does OCSP and LDAP have extensions... Its not so we can
> >ignore them and produce another YAP with optional extensions. that
> wont
> >be used...
> 
> Correct. OSCP extensions can be used to extend OCSP. What we are
> proposing 
> does not fit into the semantics of OCSP. There are two possible
> solutions: 
> extend the semantics of OCSP, or create a different protocol that does
> what 
> you want without forcing a change in an existing protocol. SCVP uses
> the 
> latter approach.
> 
	Extend the semantics is easier - that just requires an
additional definition.

	PLEASE NOTE - any extension to any protocol changes its
semantics as well as its syntax ..

> If you think it should use the former, I extend the same suggestion
> that I 
> extended to Mike Myers: do the work of changing the OCSP spec to
> include 
> the SCVP functionality and show it to the group. I sincerely think
> that you 
> will not find it easy, and that OCSP developers will find it as hard
> (or 
> even harder) to shoehorn in your changes to OCSP extension mechanism
> as 
> they would to use the SCVP request and response format. I could be
> wrong 
> about this, and would be happy to admit so if your draft looks easier
> than 
> SCVP. But Ambarish and I really looked at this before we created our
> own 
> format.
	All I can say if its difficult to extend OCSP then why have
extensions - see LDAP extensions

	There does not seem any techical  or engineering reason why this
extension cannot be done... and it would be much better for those on the
receiving end - customers...
	The implementations of extensions can be optional by the way...

	regards alan
	regards alan


> --Paul Hoffman, Director
> --VPN Consortium


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA10140 for <[e-mail]>; Thu, 2 Sep 1999 18:49:22 -0700 (PDT)
Received: from nma.com (pm06-44.sac.verio.net [209.162.64.251]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id SAA24138; Thu, 2 Sep 1999 18:48:01 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 02 Sep 1999 18:48:01 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ron Ramsay <[e-mail]>
CC: Bob Jueneman <[e-mail]>, [e-mail], [e-mail], Tom Gindin <[e-mail]>
Subject: Re: Deprecate the NR bit?
References: <D1A949D4508DD1119C8100400533BEDC151970@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ron Ramsay wrote:

> I disagree.

Ron:

It seems that  you tend to see things down under ;-) This is my conclusion,
the one that you disagree with:

>Ed Gerck wrote:
>>
>>Thus, I welcomed Tom's initiative and I ask you Bob to take a good hard look
>> at it and perhaps you will also agree that if this RFC is the most one can
>> have at the  moment ... then let's have it.

as one can see at the end of the message (that I have kept for reference).  But,
perhaps, it is just yet another simple confusion -- you simply confused my
argument with my conclusion. To make it clearer to distinguish them for future
reading,  you could note that the conclusion is almost always preceded by
"thus".

Cheers,

Ed Gerck


> What this group needs is a strictly technical definition of NR. This CAN
> be defined. Full NR is what has caused the fraught debate on this list.
> It CANNOT be defined.
>
> We can only provide (technical) procedures with specific outcomes that
> may support real world procedures. If we continue to debate 'full' NR I
> think we will sink without trace.
>
> I congratulate Tom for his brave first step.
>
> Ron.
>
> > -----Original Message-----
> > From: Ed Gerck [SMTP:[e-mail]]
> > Sent: Friday, September 03, 1999 4:23 AM
> > To:   Bob Jueneman
> > Cc:   [e-mail]; [e-mail]; Tom Gindin
> > Subject:      Re: Deprecate the NR bit?
> >
> >
> >
> > Bob Jueneman wrote:
> >
> > > But even if he [Tom Gindin] comes up with a satisfactory, suitably
> > limited definition of
> > > "technical NR" or something like that, I think we have clearly
> > identified a need for additional
> > > functionality that needs to be endorsed by the CA in order to
> > constitute adequate
> > > notice. so I think additional bits will be necessary.  Whether we
> > put them in the keyUsage
> > > or the extendedKeyUsage fields, I don't care.
> >
> > In my analysis, four cases are needed at least -- and, for heaven's
> > sake, yes, four different
> > names. Instead of calling all as "NR".  We now have "technical NR",
> > "full NR", and maybe,
> > following this track we will have "waning NR",  "quasi-empty NR", etc.
> > ;-)
> >
> > Of course (paraphrasing a very well-known text), no objection can be
> > raised
> > against the self-definition of NR itself in PKIX, at most one might
> > take exception
> > to the name "non-repudiation" given to this quantity on the ground
> > that the term is
> > reserved for another, "known" concept.  But, as far as the exposition
> > of PKIX
> > clarified by Tom's proposed RFC is concerned, the term was not "known"
> > -- as it has
> > appeared for the "first time" in PKIX and then was defined in a
> > precise form in Tom's
> > proposed RFC.
> >
> > It is true however that human beings, business and law do have a
> > concept of
> > non-repudiation which differs from PKIX usage, and I think it is
> > unfortunate that
> > these ends cannot meet when I would think it would be very easy to do
> > so.  But,
> > it just adds another level of indirection.
> >
> > However, I feel that today this issue is NOT the most relevant one.
> > The most
> > relevant issue today IMO is to massage Tom's RFC to an at least
> > passing grade.
> >
> > As I see it any full treatment will have to be formally defined, not
> > just protocol
> > defined -- since protocol is not the only way of implementing it and
> > protocol
> > cannot do it alone. I already circulated a draft on the formalism to
> > two people in
> > the WG but it seems that interest is not high enough at this time.  It
> > is like talking
> > about the need to have air traffic control in 1920, it seems ;-) ..
> > just too soon.  Thus,
> > I welcomed Tom's initiative and I ask you Bob to take a good hard look
> > at it
> > and perhaps you will also agree that if this RFC is the most one can
> > have at the
> > moment ... then let's have it.
> >
> > Cheers,
> >
> > Ed Gerck

--
Cheers,

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




Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA08799 for <[e-mail]>; Thu, 2 Sep 1999 18:06:36 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <S1ACJS65>; Fri, 3 Sep 1999 11:08:47 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC151970@DSG1>
From: Ron Ramsay <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>, Bob Jueneman <[e-mail]>
Cc: [e-mail], [e-mail], Tom Gindin <[e-mail]>
Subject: RE: Deprecate the NR bit?
Date: Fri, 3 Sep 1999 11:08:46 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain

I disagree.

What this group needs is a strictly technical definition of NR. This CAN
be defined. Full NR is what has caused the fraught debate on this list.
It CANNOT be defined.

We can only provide (technical) procedures with specific outcomes that
may support real world procedures. If we continue to debate 'full' NR I
think we will sink without trace.

I congratulate Tom for his brave first step.

Ron.

> -----Original Message-----
> From:	Ed Gerck [SMTP:[e-mail]]
> Sent:	Friday, September 03, 1999 4:23 AM
> To:	Bob Jueneman
> Cc:	[e-mail]; [e-mail]; Tom Gindin
> Subject:	Re: Deprecate the NR bit?
> 
> 
> 
> Bob Jueneman wrote:
> 
> > But even if he [Tom Gindin] comes up with a satisfactory, suitably
> limited definition of
> > "technical NR" or something like that, I think we have clearly
> identified a need for additional
> > functionality that needs to be endorsed by the CA in order to
> constitute adequate
> > notice. so I think additional bits will be necessary.  Whether we
> put them in the keyUsage
> > or the extendedKeyUsage fields, I don't care.
> 
> In my analysis, four cases are needed at least -- and, for heaven's
> sake, yes, four different
> names. Instead of calling all as "NR".  We now have "technical NR",
> "full NR", and maybe,
> following this track we will have "waning NR",  "quasi-empty NR", etc.
> ;-)
> 
> Of course (paraphrasing a very well-known text), no objection can be
> raised
> against the self-definition of NR itself in PKIX, at most one might
> take exception
> to the name "non-repudiation" given to this quantity on the ground
> that the term is
> reserved for another, "known" concept.  But, as far as the exposition
> of PKIX
> clarified by Tom's proposed RFC is concerned, the term was not "known"
> -- as it has
> appeared for the "first time" in PKIX and then was defined in a
> precise form in Tom's
> proposed RFC.
> 
> It is true however that human beings, business and law do have a
> concept of
> non-repudiation which differs from PKIX usage, and I think it is
> unfortunate that
> these ends cannot meet when I would think it would be very easy to do
> so.  But,
> it just adds another level of indirection.
> 
> However, I feel that today this issue is NOT the most relevant one.
> The most
> relevant issue today IMO is to massage Tom's RFC to an at least
> passing grade.
> 
> As I see it any full treatment will have to be formally defined, not
> just protocol
> defined -- since protocol is not the only way of implementing it and
> protocol
> cannot do it alone. I already circulated a draft on the formalism to
> two people in
> the WG but it seems that interest is not high enough at this time.  It
> is like talking
> about the need to have air traffic control in 1920, it seems ;-) ..
> just too soon.  Thus,
> I welcomed Tom's initiative and I ask you Bob to take a good hard look
> at it
> and perhaps you will also agree that if this RFC is the most one can
> have at the
> moment ... then let's have it.
> 
> Cheers,
> 
> Ed Gerck


Received: from imo11.mx.aol.com (imo11.mx.aol.com [198.81.17.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA08441 for <[e-mail]>; Thu, 2 Sep 1999 17:54:15 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo11.mx.aol.com (mail_out_v22.4.) id tGGTa07545 (7998); Thu, 2 Sep 1999 20:55:16 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 2 Sep 1999 20:55:15 EDT
Subject: Re: End-Entity Certificate Policies
To: [e-mail], [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 21

I would like to add my/our voice(s)in support of Dave's and Mack's responses.

We strongly resist the idea of restrictions.  Our community has some deployed 
infrastructure and proposed services that absolutely rely upon multiple 
policy OIDs.  In some cases it is helpful, in many other cases it is 
imperative that they be supported.  (full disclosure-some of my projects 
require this as well)

After a painful, but terribly productive last two days at the ANSI X9F5 
meeting at the ABA's offices it was discomforting to see the first parts of 
this thread.

I was very pleased to see that the response from the banking community.  
Historically it has been extremely helpful to many folk involved in policy 
making and standards setting to review the concrete requirements from 
communities such as Identrus, SWIFT, and ABAecom as well as the deployed 
infrastructures run by financial institutions in the wild.  Having those 
requirements accessible directly or through participation in discussions like 
these is essential to finding solutions that actually work and meet real 
needs.  

I would encourage everyone to take great care to determine whether proposals 
would cause already deployed systems to become unsupported or render them 
noncompliant.

I have more specific arguments if anyone would like to hear them.

...Kawika Daguio...


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA04836 for <[e-mail]>; Thu, 2 Sep 1999 13:57:59 -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 WAA16361; Thu, 2 Sep 1999 22:59:52 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 02 Sep 1999 23:00:13 +0200
To: Russ Housley <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: End-Entity Certificate Policies
In-Reply-To: <[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 NAA04838

Russ,

Comments in line.

At 03:33 PM 9/2/99 -0400, Russ Housley wrote:
>Wow.  I did not expect such a flurry of responses in such a short 
>time.  Clearly, there is not consensus on this topic (at least not 
>yet).  Many people have asked me to explain our reasoning.  I have not had 
>the opportunity to run this by Tim, so I hope he does not flame me.  So, 
>here goes.
>
>
>Single Certificate Policy OID
>
>When an end-entity certificate contains more than one certificate policy 
>OID, there is ambiguity about the intent of a signer.  On the other hand, 
>if the end-entity certificate contains only one certificate policy OID, 
>there is no ambiguity.  If an end-entity certificate contains two policies, 
>one that says the certificate id for use with non-binding e-mail and 
>another that says the certificate is intended for purchases up to $10,000, 
>then it is not clear the signer intends when a signature is generated.
>

This is to me a bad way to view certificate policies. Certificate Policies
are assertions by the CA to relying parties. It is NOT an assertion by the
signer. When a signer signs a message, the intention of the signer is only
expressed in that message, not in any certificate.

Even if there are many certificates out there for the signers public key,
the signer goes free of liability for any "bad" certificate. And if some of
these certificates has ambiguous policy OID:s, that says nothing about the
signers intent. It just points out a bad CA and that CA may get into trouble.

What you are talking about seams to be more appropriate for signature
policies, which would be asserted by the signer.

>One solution for this problem is specified in  RFC 2634, Section 5.4 
>(Signing Certificate Attribute Definition).  Here, the signer can state the 
>policy that was intended at the time the signature is generated.  Other 
>protocols that use the PKIX Certificate Profile do not have similar
mechanisms.

With all respect to the attacks expressed in section 5, any attempt to
solve this by having the signer assert appropriate certificate content, is
to address the issue from the wrong angle. These attacks do in the first
place assume that a relying party trusts any bad CA.

If that is so (i.e. the relying parties trust hierarchy is broken) or a CA
within that trust hierarchy is bad. Then there are so many other potential
problems, that you basically are sucked any way.

These problems must be treated by each relying party by having working
trust models originating from trusted roots. If you have that, then you are
fixing non-existing problems. If you don't have that, you can't fix
anything anyway.

>
>I understand the desires expressed by Mack Hicks and Dave Solo for multiple 
>certificate policy OIDs in a certificate.  And, I can imagine environments 
>where there would not be a problem with this practice.  Perhaps we need 
>some guidance about when it is acceptable and when it is not.
>

many OIDs are acceptable. The CA must however make sure that no certificate
contains conflicting policies. But I hope all CAs understand that.

>
>Limiting Certificate Policy Qualifiers to End-Entity Certificates
>
>A review of the certificate path validation algorithm shows that one of 
>it's outputs is a set of certificate policy qualifiers.  X.509-1997 says 
>that a successful validation returns "a set of policies constrained by the 
>CAs in the certification path, together with all qualifiers for these 
>policies encountered in the certification path."
>
>This means that the certificate user cannot tell which qualifier goes with 
>which certificate in the path.  Rather, an unordered set of the qualifiers 
>is provided. Since the purpose of qualifier is to provide additional policy 
>information to the certificate user (a.k.a. the relying party), it seems 
>important that the set of qualifiers not provide 
>contradictions.  Especially in the case of the qualifiers specified in RFC 
>2459.

I believe you read X.509 wrong here. The full text of that section continues:

"Unless any-policy is returned, the certificate user shall ONLY use the
certificate in accordance with ONE of the identified policies and shall
process all qualifiers for THAT policy present in the certification path."

Now how is that possible if you return an un-ordered set of the qualifiers,
not related to their associated policies.

The path processing algorithm does further not use separate variables for
policies and for qualifiers. A reasonable interpretation of the algorithm,
given these facts, must be that all policy objects in the process is
handled together with their associated qualifiers, and thus should be
presented that way in the output.

Your interpretation must be wrong here, or do you have an installed base of
softwares to back your view?

>
>Mike Myers suggests that CA certificates should be permitted to include the 
>CPS pointer qualifier.  Let's assume that there is a simple path of two 
>certificates, the CA certificate and the end-entity certificate.  The CA 
>certificate has two certificate policy OIDs, each with a CPS pointer 
>qualifier.  The end-entity certificate has a single certificate policy OID, 
>also with a CPS pointer qualifier.  When the certificate path validation 
>algorithm is executed, one of the outputs will be the certificate policy 
>OID that is common to both certificates and the two qualifiers (one from 
>the CA certificate and one from the end-entity certificate).  What is the 
>certificate user expected to do?  If the URLs are different, the 
>certificate user really has no idea what to do.
>

See above +
This example suggest that a CA issue a certificate under two different
CPSs, That seams to be a false case. 

If there would be a guideline it should say that a certificate may include
many policy OIDs but should only indicate one CPS. One CPS may very well
reflect multiple policies. 

>Russ

/Stefan

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

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


Received: from mail.phenix.com.au (fwuser@[203.37.128.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA04466 for <[e-mail]>; Thu, 2 Sep 1999 13:43:47 -0700 (PDT)
Message-ID: <1115E3FF8E9CD211A07C006008C2045001C45E@MAIL>
From: Charles Moore <[e-mail]>
To: "'Miklos, Sue A.'" <[e-mail]>, "'Mack Hicks'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: Charles Moore <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Date: Fri, 3 Sep 1999 06:45:55 +1000 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BEF584.2BD26BC0"

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_01BEF584.2BD26BC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=A0

-----Original Message-----
From: Miklos, Sue A. [mailto:[e-mail]]
Sent: Thursday, 2 September 1999 22:56
To: 'Mack Hicks'; Sharon Boeyen
Cc: 'Charles Moore'; '[e-mail]'; '[e-mail]'
Subject: RE: End-Entity Certificate Policies



Please forgive a potentially ignorant question, but I am at a loss to
understand the operational perspective when putting multiple policy =
oids (or
any attribute values) into a certificate when it is initially generated =
and
signed.=A0 Is the thought that when an EE gets a cert, that all of the
appropriate policy domains will be known and populated, in advance?
[Charles Moore]=A0Two assumptions: a) that the certificate policies =
directly
relate to the business activities=A0being supported, and hence it is
reasonable that the=A0CP(s) are known ( supporting an unknown business =
s
process sis difficult at best). b) the certificates are part of an
infrastructure, not really stand alone, c)=A0that a certificate is no =
more
difficult to manage than say a password.=A0 This discussions are not =
just
limited to certificates for the purposes of ID.

The use of policy qualifiers reduces the=A0need for multiple EE =
policies.
Weather one has single or multiple CP (oids) or one CP with several =
Policy
qualifiers is a business and system design issue, not a PKIX one...

=A0

=A0

=A0 Will the addition of subsequent oids require generating new certs =
(and the
accompanying revocation of the 'old' certs)?
[Charles Moore]=A0Generation yes, revocation depends on the business=A0 =
and
usage..

=A0Start with the basis that certificates are not useful on their own, =
and
most things fall into place...

Sandi Miklos=20

-----Original Message-----=20
From: Mack Hicks [ mailto:[e-mail]
<mailto:[e-mail]> ]=20
Sent: Wednesday, September 01, 1999 11:18 AM=20
To: Sharon Boeyen=20
Cc: 'Charles Moore'; '[e-mail]'; '[e-mail]'=20
Subject: Re: End-Entity Certificate Policies=20


Sharon,=20

I agree with you. I have a real business need for multiple OIDs in an =
End
Entity=20
Certificate.=20

In the Identrus community, all certificates under the Identrus Root =
must
have=20
the OID of Identrus. It is expected that relying parties may be =
receiving=20
certificates from multiple participants and sub-CAs within the =
structure. It
is=20
easier for the relying party to be able to identify an Identrus =
certificate
and=20
its context of use through the Identrus OID. Restricting the number of =
OIDs=20
means that the relying party has no way of determining a membership in =
a
broader=20
community. Further, the sub-CAs have no way for providing further =
policy
context=20
of an end-entity certificate. (I realize that cert path validation =
would=20
identify these communities, but the relying party may not have all the=20
certificates in the path.)=20

I do not see the any advantage to mandating=A0 only a single OID in an =
EE=20
certificate. From a business view, the result is to proliferate the =
number
of=20
policy documents.=20

Mack Hicks=20

Sharon Boeyen wrote:=20

> I don't support limiting to a single policy OID or limiting the use =
of=20
> qualifiers only to end-entity certs. Even if this was agreed as part =
of=20
> the PKIX profile for what CAs were to do, relying parties presumably =
would

> need to be able to deal with certs that were created outside of PKIX =
and=20
> these might very well have multiple policies in the end-entity certs =
and=20
> qualifiers in the CA certs. So at best this proposal might impose =
limits=20
> on CA behavior for PKIX CAs, but probably couldn't on PKIX relying =
parties

> unless we want to isolate the PKIX world from the rest of the world =
:-(=20
>=20
> Sharon=20
>=20

--=20
-------------------------------------------------------------------=20
Mack Hicks, VP=A0=A0=A0=A0 [e-mail]=20
Bank of America=A0 [phone]=20


------_=_NextPart_001_01BEF584.2BD26BC0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: End-Entity Certificate Policies</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
  size=2>-----Original Message-----<BR><B>From:</B> Miklos, Sue A. 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, 2 September 1999 
  22:56<BR><B>To:</B> 'Mack Hicks'; Sharon Boeyen<BR><B>Cc:</B> 'Charles Moore'; 
  '[e-mail]'; '[e-mail]'<BR><B>Subject:</B> RE: End-Entity 
  Certificate Policies<BR><BR></FONT></DIV></FONT>
  <P><FONT size=2>Please forgive a potentially ignorant question, but I am at a 
  loss to understand the operational perspective when putting multiple policy 
  oids (or any attribute values) into a certificate when it is initially 
  generated and signed.&nbsp; Is the thought that when an EE gets a cert, that 
  all of the appropriate policy domains will be known and populated, in 
  advance?<BR><SPAN class=921553420-02091999><FONT color=#0000ff 
  face=Arial>[Charles Moore]&nbsp;Two assumptions: a) that the certificate 
  policies directly relate to the business activities&nbsp;being supported, and 
  hence it is reasonable that the&nbsp;CP(s) are known ( supporting an unknown 
  business s process sis difficult at best). b) the certificates are part of an 
  infrastructure, not really stand alone, c)&nbsp;that a certificate is no more 
  difficult to manage than say a password.&nbsp; This discussions are not just 
  limited to certificates for the purposes of ID.</FONT></SPAN></FONT></P>
  <P><FONT color=#0000ff face=Arial size=2><SPAN class=921553420-02091999>The 
  use of policy qualifiers reduces the&nbsp;need for multiple EE policies. 
  Weather one has single or multiple CP (oids) or one CP with several Policy 
  qualifiers is a business and system design issue, not a PKIX 
  one...</SPAN></FONT></P>
  <P><FONT color=#0000ff face=Arial size=2><SPAN 
  class=921553420-02091999></SPAN></FONT>&nbsp;</P>
  <P><FONT size=2><SPAN class=921553420-02091999></SPAN></FONT>&nbsp;</P>
  <P><FONT size=2><SPAN class=921553420-02091999>&nbsp;</SPAN> Will the addition 
  of subsequent oids require generating new certs (and the accompanying 
  revocation of the 'old' certs)?<BR><FONT color=#0000ff face=Arial><SPAN 
  class=921553420-02091999>[Charles Moore]&nbsp;Generation yes, revocation 
  depends on the business&nbsp; and usage..</SPAN></FONT></FONT></P>
  <P><FONT size=2><FONT color=#0000ff face=Arial><SPAN 
  class=921553420-02091999>&nbsp;Start with the basis that certificates are not 
  useful on their own, and most things fall into 
  place...</SPAN></FONT></FONT></P>
  <P><FONT size=2>Sandi Miklos</FONT> </P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Mack 
  Hicks [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>Sent: Wednesday, September 01, 1999 11:18 AM</FONT> <BR><FONT 
  size=2>To: Sharon Boeyen</FONT> <BR><FONT size=2>Cc: 'Charles Moore'; 
  '[e-mail]'; '[e-mail]'</FONT> <BR><FONT size=2>Subject: Re: 
  End-Entity Certificate Policies</FONT> </P><BR>
  <P><FONT size=2>Sharon,</FONT> </P>
  <P><FONT size=2>I agree with you. I have a real business need for multiple 
  OIDs in an End Entity</FONT> <BR><FONT size=2>Certificate.</FONT> </P>
  <P><FONT size=2>In the Identrus community, all certificates under the Identrus 
  Root must have</FONT> <BR><FONT size=2>the OID of Identrus. It is expected 
  that relying parties may be receiving</FONT> <BR><FONT size=2>certificates 
  from multiple participants and sub-CAs within the structure. It is</FONT> 
  <BR><FONT size=2>easier for the relying party to be able to identify an 
  Identrus certificate and</FONT> <BR><FONT size=2>its context of use through 
  the Identrus OID. Restricting the number of OIDs</FONT> <BR><FONT size=2>means 
  that the relying party has no way of determining a membership in a 
  broader</FONT> <BR><FONT size=2>community. Further, the sub-CAs have no way 
  for providing further policy context</FONT> <BR><FONT size=2>of an end-entity 
  certificate. (I realize that cert path validation would</FONT> <BR><FONT 
  size=2>identify these communities, but the relying party may not have all 
  the</FONT> <BR><FONT size=2>certificates in the path.)</FONT> </P>
  <P><FONT size=2>I do not see the any advantage to mandating&nbsp; only a 
  single OID in an EE</FONT> <BR><FONT size=2>certificate. From a business view, 
  the result is to proliferate the number of</FONT> <BR><FONT size=2>policy 
  documents.</FONT> </P>
  <P><FONT size=2>Mack Hicks</FONT> </P>
  <P><FONT size=2>Sharon Boeyen wrote:</FONT> </P>
  <P><FONT size=2>&gt; I don't support limiting to a single policy OID or 
  limiting the use of</FONT> <BR><FONT size=2>&gt; qualifiers only to end-entity 
  certs. Even if this was agreed as part of</FONT> <BR><FONT size=2>&gt; the 
  PKIX profile for what CAs were to do, relying parties presumably would</FONT> 
  <BR><FONT size=2>&gt; need to be able to deal with certs that were created 
  outside of PKIX and</FONT> <BR><FONT size=2>&gt; these might very well have 
  multiple policies in the end-entity certs and</FONT> <BR><FONT size=2>&gt; 
  qualifiers in the CA certs. So at best this proposal might impose 
  limits</FONT> <BR><FONT size=2>&gt; on CA behavior for PKIX CAs, but probably 
  couldn't on PKIX relying parties</FONT> <BR><FONT size=2>&gt; unless we want 
  to isolate the PKIX world from the rest of the world :-(</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt; Sharon</FONT> <BR><FONT 
  size=2>&gt;</FONT> </P>
  <P><FONT size=2>--</FONT> <BR><FONT 
  size=2>-------------------------------------------------------------------</FONT> 
  <BR><FONT size=2>Mack Hicks, VP&nbsp;&nbsp;&nbsp;&nbsp; 
  [e-mail]</FONT> <BR><FONT size=2>Bank of America&nbsp; 
  [phone]</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BEF584.2BD26BC0--


Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.9.3/8.9.3) with SMTP id NAA04342 for <[e-mail]>; Thu, 2 Sep 1999 13:42:36 -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 QAA22751 for <[e-mail]>; Thu, 2 Sep 1999 16:45:26 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 02 Sep 1999 16:45:57 -0400
To: [e-mail]
From: Bill Burr <[e-mail]>
Subject: RE: End-Entity Certificate Policies
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 03:33 PM 9/2/99 -0400, you wrote:
>Wow.  I did not expect such a flurry of responses in such a short 
>time.  Clearly, there is not consensus on this topic (at least not 
>yet).  Many people have asked me to explain our reasoning.  I have not had 
>the opportunity to run this by Tim, so I hope he does not flame me.  So, 
>here goes.
>
>
>Single Certificate Policy OID
>
>When an end-entity certificate contains more than one certificate policy 
>OID, there is ambiguity about the intent of a signer.  On the other hand, 
>if the end-entity certificate contains only one certificate policy OID, 
>there is no ambiguity.  If an end-entity certificate contains two policies, 
>one that says the certificate id for use with non-binding e-mail and 
>another that says the certificate is intended for purchases up to $10,000, 
>then it is not clear the signer intends when a signature is generated.

But, is it clear that one CP will necessarily be that specific?  A single
policy  might allow several applications, or it might speak to assurance
level rather than constraining applications at all.

Moreover, when I sign something with my John Hancock, do I state the policy
under which I sign it, and have a separate signature for every kind of
document I sign?  Why do I have to with certificates?  And, is it your
supposition that the certificate used to sign a document is always bound
with the signed document?  
 
>
>One solution for this problem is specified in  RFC 2634, Section 5.4 
>(Signing Certificate Attribute Definition).  Here, the signer can state the 
>policy that was intended at the time the signature is generated.  Other 
>protocols that use the PKIX Certificate Profile do not have similar
mechanisms.
>
>I understand the desires expressed by Mack Hicks and Dave Solo for multiple 
>certificate policy OIDs in a certificate.  And, I can imagine environments 
>where there would not be a problem with this practice.  Perhaps we need 
>some guidance about when it is acceptable and when it is not.
>
>
>Limiting Certificate Policy Qualifiers to End-Entity Certificates
>
>A review of the certificate path validation algorithm shows that one of 
>it's outputs is a set of certificate policy qualifiers.  X.509-1997 says 
>that a successful validation returns "a set of policies constrained by the 
>CAs in the certification path, together with all qualifiers for these 
>policies encountered in the certification path."
>
>This means that the certificate user cannot tell which qualifier goes with 
>which certificate in the path.  Rather, an unordered set of the qualifiers 
>is provided. Since the purpose of qualifier is to provide additional policy 
>information to the certificate user (a.k.a. the relying party), it seems 
>important that the set of qualifiers not provide 
>contradictions.  Especially in the case of the qualifiers specified in RFC 
>2459.
>
>Mike Myers suggests that CA certificates should be permitted to include the 
>CPS pointer qualifier.  Let's assume that there is a simple path of two 
>certificates, the CA certificate and the end-entity certificate.  The CA 
>certificate has two certificate policy OIDs, each with a CPS pointer 
>qualifier.  The end-entity certificate has a single certificate policy OID, 
>also with a CPS pointer qualifier.  When the certificate path validation 
>algorithm is executed, one of the outputs will be the certificate policy 
>OID that is common to both certificates and the two qualifiers (one from 
>the CA certificate and one from the end-entity certificate).  What is the 
>certificate user expected to do?  If the URLs are different, the 
>certificate user really has no idea what to do.
>
>Russ
>
>
Regards,

Bill Burr


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA03633 for <[e-mail]>; Thu, 2 Sep 1999 12:32:32 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA28356 for <[e-mail]>; Thu, 2 Sep 1999 12:28:31 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 02 Sep 1999 15:33:28 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Wow.  I did not expect such a flurry of responses in such a short 
time.  Clearly, there is not consensus on this topic (at least not 
yet).  Many people have asked me to explain our reasoning.  I have not had 
the opportunity to run this by Tim, so I hope he does not flame me.  So, 
here goes.


Single Certificate Policy OID

When an end-entity certificate contains more than one certificate policy 
OID, there is ambiguity about the intent of a signer.  On the other hand, 
if the end-entity certificate contains only one certificate policy OID, 
there is no ambiguity.  If an end-entity certificate contains two policies, 
one that says the certificate id for use with non-binding e-mail and 
another that says the certificate is intended for purchases up to $10,000, 
then it is not clear the signer intends when a signature is generated.

One solution for this problem is specified in  RFC 2634, Section 5.4 
(Signing Certificate Attribute Definition).  Here, the signer can state the 
policy that was intended at the time the signature is generated.  Other 
protocols that use the PKIX Certificate Profile do not have similar mechanisms.

I understand the desires expressed by Mack Hicks and Dave Solo for multiple 
certificate policy OIDs in a certificate.  And, I can imagine environments 
where there would not be a problem with this practice.  Perhaps we need 
some guidance about when it is acceptable and when it is not.


Limiting Certificate Policy Qualifiers to End-Entity Certificates

A review of the certificate path validation algorithm shows that one of 
it's outputs is a set of certificate policy qualifiers.  X.509-1997 says 
that a successful validation returns "a set of policies constrained by the 
CAs in the certification path, together with all qualifiers for these 
policies encountered in the certification path."

This means that the certificate user cannot tell which qualifier goes with 
which certificate in the path.  Rather, an unordered set of the qualifiers 
is provided. Since the purpose of qualifier is to provide additional policy 
information to the certificate user (a.k.a. the relying party), it seems 
important that the set of qualifiers not provide 
contradictions.  Especially in the case of the qualifiers specified in RFC 
2459.

Mike Myers suggests that CA certificates should be permitted to include the 
CPS pointer qualifier.  Let's assume that there is a simple path of two 
certificates, the CA certificate and the end-entity certificate.  The CA 
certificate has two certificate policy OIDs, each with a CPS pointer 
qualifier.  The end-entity certificate has a single certificate policy OID, 
also with a CPS pointer qualifier.  When the certificate path validation 
algorithm is executed, one of the outputs will be the certificate policy 
OID that is common to both certificates and the two qualifiers (one from 
the CA certificate and one from the end-entity certificate).  What is the 
certificate user expected to do?  If the URLs are different, the 
certificate user really has no idea what to do.

Russ



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA02871 for <[e-mail]>; Thu, 2 Sep 1999 11:24:13 -0700 (PDT)
Received: from nma.com (pm07-20.sac.verio.net [209.162.65.39]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id LAA24420; Thu, 2 Sep 1999 11:23:04 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 02 Sep 1999 11:23:04 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail], Tom Gindin <[e-mail]>
Subject: Re: Deprecate the NR bit?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:

> But even if he [Tom Gindin] comes up with a satisfactory, suitably limited definition of
> "technical NR" or something like that, I think we have clearly identified a need for additional
> functionality that needs to be endorsed by the CA in order to constitute adequate
> notice. so I think additional bits will be necessary.  Whether we put them in the keyUsage
> or the extendedKeyUsage fields, I don't care.

In my analysis, four cases are needed at least -- and, for heaven's sake, yes, four different
names. Instead of calling all as "NR".  We now have "technical NR", "full NR", and maybe,
following this track we will have "waning NR",  "quasi-empty NR", etc. ;-)

Of course (paraphrasing a very well-known text), no objection can be raised
against the self-definition of NR itself in PKIX, at most one might take exception
to the name "non-repudiation" given to this quantity on the ground that the term is
reserved for another, "known" concept.  But, as far as the exposition of PKIX
clarified by Tom's proposed RFC is concerned, the term was not "known" -- as it has
appeared for the "first time" in PKIX and then was defined in a precise form in Tom's
proposed RFC.

It is true however that human beings, business and law do have a concept of
non-repudiation which differs from PKIX usage, and I think it is unfortunate that
these ends cannot meet when I would think it would be very easy to do so.  But,
it just adds another level of indirection.

However, I feel that today this issue is NOT the most relevant one.  The most
relevant issue today IMO is to massage Tom's RFC to an at least passing grade.

As I see it any full treatment will have to be formally defined, not just protocol
defined -- since protocol is not the only way of implementing it and protocol
cannot do it alone. I already circulated a draft on the formalism to two people in
the WG but it seems that interest is not high enough at this time.  It is like talking
about the need to have air traffic control in 1920, it seems ;-) .. just too soon.  Thus,
I welcomed Tom's initiative and I ask you Bob to take a good hard look at it
and perhaps you will also agree that if this RFC is the most one can have at the
moment ... then let's have it.

Cheers,

Ed Gerck



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA02217 for <[e-mail]>; Thu, 2 Sep 1999 10:35:38 -0700 (PDT)
Received: from nma.com (pm07-20.sac.verio.net [209.162.65.39]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id KAA12424; Thu, 2 Sep 1999 10:37:54 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 02 Sep 1999 10:37:54 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail]
Subject: Re: Real-world issues, Re: Deprecate the NR bit?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:

> Ed, I agree with much of what you said, but there is an important case
> which you left out, and that is where I as the signer do not trust
> certain applications, operating systems, etc., etc., to make use of my
> "death warrant" certificate keys, and in particular don't want to ever
> have such keys generated or stored in software,  as opposed to a
> (more) secure smart card.
>
Bob:

Agreed. However, this still does not apply to that case which Steve
mentioned and which I was commenting, namely as he said that "Not
all applications may be trusted to  properly assert invocation  of
NR services".  Because who invokes NR services is the relying-party,
that needs to prevent the denialof a previous act by the signer.  In
other words,  in *all* cases, the  signer is in a better position if NR
does NOT work ;-)  since, if  a belated need arrives, the signer can
then choose to repudiate using his "death warrant" key , but the
signer can  likewise choose not to repudiate as well.

I stay then with what I commented, that both the cert  issuer and the
cert subject (i.e., the signer) will be *relieved* of any "NR services"
 in case the "NR services" fail due to reasons not attributable to them
-- which  means that is irrelevant to either of them whether the
relying-party fails or not fails to use an application that can "be trusted
to properly assert invocation of NR services".

> So it is not only the relying party who may be concerned with such a
> bit, but the  signer as well.
>
Yes, but in different roles.  The signer must be concerned that his "death
warrant" certificate key is correctly used in order to assert the NR bit in a
signature (including the application he uses for this). OTOH, the
relying-party must be concerned that his system (including the
application he uses) will correctly prevent the denial of previous
signatures that had the NR bit set --  irrespective of who signed it,
could have been your secretary using your "death warrant" key when
you went elk hurting, sorry, hunting ;-)

In other words, in regard to the NR bit, the signer is concerned about
authentication (as always) while the relying-party is concerned about
non-repudiation (as specifically).

> Unless the CA is acting as either a notary or an insurance company, I
> see only a  very limited role for them in this discussion, however.
>
Yes, as I commented elsewhere, the non-repudiation mode of certification
is essentially verifier-centric -- not CA-centric.  This is perhaps what causes
so much confusion, since everyone is used to think more often in terms of
a CA-centric certification. Here, it is necessary to "shift gears" ;-)

Cheers,

Ed Gerck



Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA01734 for <[e-mail]>; Thu, 2 Sep 1999 10:07:24 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id KAA16930 for <[e-mail]>; Thu, 2 Sep 1999 10:09:37 -0700 (PDT)
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 02 Sep 1999 10:09:33 -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 KAA18937 for <[e-mail]>; Thu, 2 Sep 1999 10:09:32 -0700 (PDT)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 02 Sep 1999 10:09:32 -0700
Subject: Re: Deprecate the NR bit?
From: "Aram Perez" <[e-mail]>
To: PKIX <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:

> Steve, is exactly right, there -- this is precisely why I wanted to clearly
define
> what the NR bit meant, so we would know whether or not an application should
> be allowed to use such a key.

I don't think "Steve is exactly right". When he states "if one provides an
application with access to certs ONLY with NR=0", who is providing the
access? In my experience, it is the application that does the filtering, not
the directory/database service. It is the application asks the directory
service "find all certificates for Jon Doe that have NR=0".

>
> Unfortunately, by not defining the semantics of the bit precisely, we now have
the
> predictable situation where various CAs and institutions like DOD are using
> the bit in
> mutually contradictory fashion, making it nearly impossible to say anything
> meaningful
> about the purpose of that bit, and thereby degrading its utility to
> practically zero.
>
> Although I strongly agree with the concept of requiring either the presence or
> the absence of the NR bit with respect to certain applications, at this point
the
> meaning, and hence the value of the bit has been so degraded that personally,
> I despair of ever getting the horses back into the barn.

I agree that there should be an indicators depending on the applications,
but I think using bits is too limiting.

>
> That's why I suggested deprecating the existing bit, and defining some new
> ones with
> very carefully crafted semantics.

Agreed except not with bits.

>
> Maybe Tom Gundin can pull the fat out of the fire (I seem to be on a
> metaphor roll :-)
> and come up with a definition of some useful function that we can all agree to
for
> the existing bit -- if so, he will certainly deserve a medal.

Agreed.

>
> But even if he comes up with a satisfactory, suitably limited definition of
> "technical NR"
> or something like that, I think we have clearly identified a need for
additional
> functionality that needs to be endorsed by the CA in order to constitute
adequate
> notice. so I think additional bits will be necessary.  Whether we put them
> in the keyUsage
> or the extendedKeyUsage fields, I don't care.

No more bits please ;-)

Regards,
Aram Perez

>
> Bob
>
>
>
>>>> Stephen Kent <[e-mail]> 08/31/99 08:20AM >>>
> At 8:53 AM -0700 8/30/99, Aram Perez wrote:
>
>>Ron Ramsay wrote:
>>
>>> Except that the NR bit cannot be added to the certificate by the
>>> application!
>>
>>But the application can add a much better indicator to the data that needs
>>to be part of the evidence that supports non-repudiation as has been
>>proposed on this mailing list.
>
> Not all applications may be trusted to properly assert invocation  of NR
> services.  By including the NR bit in a cert, we have a (potentially)
> higher assurance mechanism that can allow or prohibit an application from
> invoking NR services.  For example, if one provides an application with
> access to certs ONLY with NR=0, we can ensure that these apps cannot assert
> that they are acting in an NR capacity on behalf of the user. This is a
> very useful security facility and a good reason to keep the NR bit.
>
> Steve
>



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id JAA01316 for <[e-mail]>; Thu, 2 Sep 1999 09:59:03 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 02 Sep 1999 11:00:51 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Thu, 02 Sep 1999 10:58:02 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Real-world issues, Re: Deprecate the NR bit?
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 JAA01321

This one was screwed up also, for reasons unknown as yet.  Sorry about that.

Bob

--

Ed, I agree with much of what you said, but there is an important case
which you left out, and that is where I as the signer do not trust certain applications,
operating systems, etc., etc., to make use of my "death warrant" certificate keys,
and in particular don't want to ever have such keys generated or stored in software, 
as opposed to a (more) secure smart card.

So it is not only the relying party who may be concerned with such a bit, but the 
signer as well.

Unless the CA is acting as either a notary or an insurance company, I see only a 
very limited role for them in this discussion, however.

Bob

>>> Ed Gerck <[e-mail]> 08/31/99 02:07PM >>>


Stephen Kent wrote:

> Not all applications may be trusted to properly assert invocation  of NR
> services.

Failure of NR services  (whatever "NR services" is understood to be, from
the options mentioned here) will  however flow back only to the
relying-party *if* the relying-party uses an application that causes that
failure by improperly asserting invocation of "NR services" -- which is
what you mention above.

Therefore, in the case you mention, both the cert  issuer and the cert subject
will be *relieved* of any "NR services" obligations -- which means that
is irrelevant to either of them whether the relying-party fails or not fails
to use an application that can "be trusted to properly assert invocation of
NR services".

This logic applies also when the issuer entity has a second hat as one of
the relying-parties -- for example, when the CA is internal to a company
and has the responsibility of selecting the application that will be
used to validate the certs at the workstations, because in this case the CA
is not acting as an issuer in this second role but as a relying-party to the
issuer and its failure in this second role cannot taint its first role as an
issuer.

Thus, the case you mention is moot in real-world cases -- it is the
relying-party's responsibility to select its applications, and also to use
them properly.

> By including the NR bit in a cert, we have a (potentially)
> higher assurance mechanism that can allow or prohibit an application from
> invoking NR services.

Agreed 100%. Whatever "NR services" is.  But that decision (to allow or
prohibit) can fall on the relying-party itself, on the cert issuer, on the cert
subject or on a fourth-party (validation service, etc.).   Thus, what you
mention needs to be expressively qualified -- either in the spec or in the
CPS, or in both (with default to CPS). I prefer the last option, for reasons
already mentioned.

Without qualification, what you mention is thus too ambiguous to be
useful in the real-world.  And, illegal if there was no previous provable consent
based on clear text with a choice not to use it.

>  For example, if one provides an application with
> access to certs ONLY with NR=0, we can ensure that these apps cannot assert
> that they are acting in an NR capacity on behalf of the user.

In your example, "one provides an application with access to certs ONLY
with NR=0" is a trust statement.  Someone trusts that "ONLY" -- either the
"one" that provided (e.g., a sysadmin) or the relying-party itself.  However,
what happens if that application may not in fact be properly trusted in the
real-workd operational context? Then, we are back to paragraph one.   So,
"we can ensure" nothing.

Again, it is the relying-party's responsibility to select its applications, and
also to use them properly.

> This is a very useful security facility and a good reason to keep the NR bit.

Not by this reason, though, as above.

Further, I think that is becoming increasingly clear by these and previous examples
that there is no real-world use model behind the "NR services" defined in PKIX.
And I say this not as an argument to deprecate the "NR bit" (which would be the
worse choice IMO) but as a strong argument to say the least about it in the spec
itself and leave the CPS as the authoritative source -- possibly with a simple
and clear default behavior in the spec if the CPS does not mention it.

To be fully backward and forward compatible  is not easy in this case but
suggestions were already presented.

BTW, as a side remark but also a real-world issue, it may be time for IETF to
also consider WG-authored RFCs and STDs -- which would avoid the problem
of one or a few authors being  confronted with the unfair pain of changing
their own words based on a large WG's work with many more eyes.   It is hard
to imagine RFCs on important and wide-reaching subjects that can really be
attributed to one person nowadays, even though this was possible some
Internet-years ago with John Postel and others.   If decisions are made by or
imply consensus and if there is wide  participation, attribution of RFCs to the
WG should afford more flexibility and actually reflect that participation.  One
recent example where this is being applied quite successfully in a difficult
subject can be seen in NSI's Registry Advisory  Board where I participate
and we decided to use anonymous attributions in the Meeting Minutes in
order to stress that they are the result of group work and to keep positions
flexible -- nonetheless, we can keep track of what has been decided and why.
The mechanism of group-authored text can be extended even to list discussions
as one Internet WG used in order to enhance the flow of ideas, by anonymizing
email addresses. Group-authored text can also be reduced in RFCs by selecting
one or two WG members as editors of contributions but not as writers.

Cheers,

Ed Gerck


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id JAA01246 for <[e-mail]>; Thu, 2 Sep 1999 09:58:51 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 02 Sep 1999 11:00:39 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Thu, 02 Sep 1999 10:54:20 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Deprecate the NR bit?
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 JAA01264

(I have absolutely no idea why the previous message came up blank -- maybe there is
something wrong with my html editor.  I'll try it again in plain text.)

Bob
---

Steve is exactly right, there -- this is precisely why I wanted to clearly define
what the NR bit meant, so we would know whether or not an application should
be allowed to use such a key.

Unfortunately, by not defining the semantics of the bit precisely, we now have the
predictable situation where various CAs and institutions like DOD are using the bit in 
mutually contradictory fashion, making it nearly impossible to say anything meaningful
about the purpose of that bit, and thereby degrading its utility to practically zero.

Although I strongly agree with the concept of requiring either the presence or 
the absence of the NR bit with respect to certain applications, at this point the 
meaning, and hence the value of the bit has been so degraded that personally,
I despair of ever getting the horses back into the barn.

That's why I suggested deprecating the existing bit, and defining some new ones with
very carefully crafted semantics.

Maybe Tom Gindin can pull the fat out of the fire (I seem to be on a metaphor roll today :-)
and come up with a definition of some useful function that we can all agree to for 
the existing bit -- if so, he will certainly deserve a medal.

But even if he comes up with a satisfactory, suitably limited definition of "technical NR"
or something like that, I think we have clearly identified a need for additional 
functionality that needs to be endorsed by the CA in order to constitute adequate
notice. so I think additional bits will be necessary.  Whether we put them in the keyUsage
or the extendedKeyUsage fields, I don't care.

Bob



>>> Stephen Kent <[e-mail]> 08/31/99 08:20AM >>>
At 8:53 AM -0700 8/30/99, Aram Perez wrote:

>Ron Ramsay wrote:
>
>> Except that the NR bit cannot be added to the certificate by the
>> application!
>
>But the application can add a much better indicator to the data that needs
>to be part of the evidence that supports non-repudiation as has been
>proposed on this mailing list.

Not all applications may be trusted to properly assert invocation  of NR
services.  By including the NR bit in a cert, we have a (potentially)
higher assurance mechanism that can allow or prohibit an application from
invoking NR services.  For example, if one provides an application with
access to certs ONLY with NR=0, we can ensure that these apps cannot assert
that they are acting in an NR capacity on behalf of the user. This is a
very useful security facility and a good reason to keep the NR bit.

Steve



Received: from citicorp.com (mango2.citicorp.com [192.193.195.141]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA01240 for <[e-mail]>; Thu, 2 Sep 1999 09:58:50 -0700 (PDT)
From: [e-mail]
Received: from spruce.citicorp.com (spruce.citicorp.com [192.193.195.184]) by citicorp.com (Pro-8.9.3/8.9.3) with ESMTP id NAA04384; Thu, 2 Sep 1999 13:00:05 -0400 (EDT)
Received: from x400prod2.cgin.us-md.citicorp.com (omroute1.email.citicorp.com [163.39.141.235]) by spruce.citicorp.com (8.8.5/8.8.5) with ESMTP id NAA24290; Thu, 2 Sep 1999 13:00:55 -0400 (EDT)
Received: from saturnalias.email.citicorp.com ([e-mail] [163.39.141.252]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA29331; Thu, 2 Sep 1999 12:16:43 -0400 (EDT)
Received: from localhost (root@localhost) by saturnalias.email.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA01744; Thu, 2 Sep 1999 12:16:35 -0400 (EDT)
X-OpenMail-Hops: 1
Date: Thu, 2 Sep 1999 12:12:21 -0400
Message-Id: <H0000cc404280d19@MHS>
Subject: RE: End-Entity Certificate Policies
MIME-Version: 1.0
TO: [e-mail], [e-mail]
Content-Type: multipart/mixed; boundary="openmail-part-0d0d07ad-00000001"

--openmail-part-0d0d07ad-00000001
Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT"
Content-Disposition: inline; filename="BDY.TXT"
Content-Transfer-Encoding: 7bit

Just adding my voice to the chorus - I'd strongly object to limiting EE certs 
to a single policy OID.  One of the planned deployment models uses policy OIDs 
as applicability labels (OK for email; OK for transactions; Ok for intranet 
access; OK for online banking; etc.)  These policy OIDs may well be 
standardized across multiple issuers/organizations.  Thus, a given cert may 
well have multiple such OIDs present (loosely like having multiple card network 
logos on the back of your ATM/credit card) if approved for multiple purposes.  
This model also makes RP configuration much simpler.  

As to policy qualifiers, you can deprecate them everywhere as far as I'm 
concerned.

Dave

> -----Original Message-----
> From: housley [mailto:[e-mail]]
> Sent: Tuesday, August 31, 1999 4:57 PM
> To: ietf-pkix
> Cc: housley
> Subject: End-Entity Certificate Policies
> 
> 
> Tim Polk and I got together today to discuss the changes 
> needed to address 
> the policy mapping bug (as discussed at the Oslo meeting).  
> As part of this 
> discussion, we discussed the certificate policy extension.
> 
> We believe that a CA certificate may contain one or more 
> certificate policy 
> OID.  On the other hand, we believe that an end-entity certificate 
> containing a certificate policy extension must  contain a single 
> certificate policy OID.  RFC 2459 says:
> 
>     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.
> 
> We would like to add words to make it more clear that an end-entity 
> certificate may only contain a single certificate policy OID.  The 
> explanation of this extension's purpose in a CA certificate 
> was not spelled 
> out, so we propose to fix that too.  Our proposed text is:
> 
>     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.  In an 
> end-entity certificate,
>     these policy information terms indicate the single policy 
> under which
>     the certificate has been issued and the purposes for 
> which the certificate
>     may be used.  In a CA certificate,  these policy information terms
>     limit the set of policies for certification paths which 
> include this
>     certificate.  Optional qualifiers, which may be present, are not
>     expected to change the definition of the policy.
> 
> Does anyone disagree?
> 
> Tim and I also discussed certificate policy qualifiers.  Tim 
> and I agree 
> that certificate policy qualifiers should only appear in end-entity 
> certificates.  That is, we agree that certificate policy 
> qualifier should 
> never appear in a CA certificate.  Does anyone (besides Mike 
> Baum) disagree?
> 
> Russ
> 

--openmail-part-0d0d07ad-00000001
Content-Type: application/ms-tnef; name="WINMAIL.DAT"
Content-Disposition: attachment; filename="WINMAIL.DAT"
Content-Transfer-Encoding: base64

eJ8+Iop2AQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5N
aWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEDkAYADAAAAAEAAAADABcAAQAA
ABwAAQOQBgAMAAAAAQAAAAMANgAAAAAAOgABBIABACQAAABSRTogRW5kLUVudGl0eSBDZXJ0
aWZpY2F0ZSBQb2xpY2llcwCNDAEDkAYADAAAAAEAAAALAAIAAQAAAA8AAQOQBgAMAAAAAQAA
AAsAKwAAAAAANwABA5AGAAwAAAABAAAAAwAuAAAAAAAyAAEDkAYARAAAAAEAAAACATEAAQAA
ADMAAAA0LjIuMC41OC4xOTk5MDgzMTE2MTMwNi4wMGEzZjRiMChhKW1haWwuc3B5cnVzLmNv
bQAA8Q0BA5AGABAAAAABAAAAQAA5AHA8R+Rd9b4BYgQBA5AGABwAAAABAAAAHgBCAAEAAAAM
AAAAU29sbywgRGF2aWQAPwQBA5AGABAAAAABAAAAQABIAIA3eORd9b4BrQQBA5AGADAAAAAB
AAAAHgBwAAEAAAAgAAAARW5kLUVudGl0eSBDZXJ0aWZpY2F0ZSBQb2xpY2llcwBMDAEDkAYA
KAAAAAEAAAACAXEAAQAAABYAAAABvvVd5EVI9JK0YTYR07MsAAA5E6MVAACmCQEDkAYADAAA
AAEAAAADAAYQbwMeA60AAQOQBgAMAAAAAQAAAAMABxB4CQAAnAABA5AGAHgAAAABAAAAHgAI
EAEAAABlAAAASlVTVEFERElOR01ZVk9JQ0VUT1RIRUNIT1JVUy1JRFNUUk9OR0xZT0JKRUNU
VE9MSU1JVElOR0VFQ0VSVFNUT0FTSU5HTEVQT0xJQ1lPSURPTkVPRlRIRVBMQU5ORURERVBM
TwAAAAAcHgEDkAYADAAAAAEAAAADABAQAAAAACQAAQOQBgAMAAAAAQAAAAMAERABAAAAJgAB
A5AGABQAAAABAAAAHgBCEAEAAAABAAAAAAAAAHMAAQOQBgAQAAAAAQAAAEAABzBgwqrtXPW+
AUEFAQOQBgAQAAAAAQAAAEAACDAAC3DQXfW+AdUDAQOQBgAgAAAAAQAAAAIBCzABAAAAEAAA
ALKS9Eg2YdMRsywAADkToxUuBgEDkAYADAAAAAEAAAADAN4/r28AAD8CAQOQBgAkAAAAAQAA
AAMAmc4IIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAANAMBA5AGACQAAAABAAAAAwCazggg
BgAAAAAAwAAAAAAAAEYAAAAAUoUAAPATAAB6BAEDkAYAJAAAAAEAAAADAJvOCCAGAAAAAADA
AAAAAAAARgAAAAABhQAAAAAAACcDAQOQBgAsAAAAAQAAAB4AnM4IIAYAAAAAAMAAAAAAAABG
AAAAAFSFAAABAAAABAAAADguNQA2BAEDkAYAJAAAAAEAAAALAJ3OCCAGAAAAAADAAAAAAAAA
RgAAAAAOhQAAAAAAAD4DAQOQBgAkAAAAAQAAAAMAns4IIAYAAAAAAMAAAAAAAABGAAAAABGF
AAAAAAAAOgMBA5AGACQAAAABAAAAAwCfzgggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAABC
AwEDkAYALAAAAAEAAAAeAKDOCCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAA
fgMBA5AGACwAAAABAAAAHgChzgggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAA
AIADAQOQBgAsAAAAAQAAAB4Aos4IIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAA
AACCAwEDkAYAJAAAAAEAAAALAKPOCyAGAAAAAADAAAAAAAAARgAAAAAAiAAAAAAAADwDAQOQ
BgAkAAAAAQAAAAsApM4LIAYAAAAAAMAAAAAAAABGAAAAAAWIAAAAAAAAQgMBA5AGACQAAAAB
AAAACwClzgggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAA+AwEDkAYAGAAAAAEAAAAeAD0A
AQAAAAUAAABSRTogAAAAAFMBAQOQBgAMAAAAAQAAAAMAgBD/////kAQBCQAEAAIAAAAAAAAA
AQOQBgAMAAAAAQAAAAsAIwAAAAAALwABA5AGAAwAAAABAAAACwApAAAAAAA1AAEEkAYA4AIA
AAIAAAARAAAAAwAAMAMAAAALAA8OAAAAAAIB/w8BAAAAOAAAAAAAAACBKx+kvqMQGZ1uAN0B
D1QCAAAAAGhvdXNsZXkAU01UUABob3VzbGV5QHNweXJ1cy5jb20AHgACMAEAAAAFAAAAU01U
UAAAAAAeAAMwAQAAABMAAABob3VzbGV5QHNweXJ1cy5jb20AAAMAFQwBAAAAAwD+DwYAAAAe
AAEwAQAAAAoAAAAnaG91c2xleScAAAACAQswAQAAABgAAABTTVRQOkhPVVNMRVlAU1BZUlVT
LkNPTQADAAA5AAAAAAsAQDoBAAAAAwBxOgAAAAAeAPZfAQAAAAgAAABob3VzbGV5AAIB918B
AAAAOAAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAGhvdXNsZXkAU01UUABob3VzbGV5QHNw
eXJ1cy5jb20AAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAAMRAAAAAwAAMAQAAAAL
AA8OAAAAAAIB/w8BAAAAOQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAGlldGYtcGtpeABT
TVRQAGlldGYtcGtpeEBpbWMub3JnAAAAAB4AAjABAAAABQAAAFNNVFAAAAAAHgADMAEAAAAS
AAAAaWV0Zi1wa2l4QGltYy5vcmcAAAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAMAAAAJ2ll
dGYtcGtpeCcAAgELMAEAAAAXAAAAU01UUDpJRVRGLVBLSVhASU1DLk9SRwAAAwAAOQAAAAAL
AEA6AQAAAAMAcToAAAAAHgD2XwEAAAAKAAAAaWV0Zi1wa2l4AAAAAgH3XwEAAAA5AAAAAAAA
AIErH6S+oxAZnW4A3QEPVAIAAAAAaWV0Zi1wa2l4AFNNVFAAaWV0Zi1wa2l4QGltYy5vcmcA
AAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAAQKiA==

--openmail-part-0d0d07ad-00000001--



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id JAA00553 for <[e-mail]>; Thu, 2 Sep 1999 09:29:14 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 02 Sep 1999 10:31:01 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Thu, 02 Sep 1999 10:30:52 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Real-world issues, Re: Deprecate the NR bit?


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id JAA00327 for <[e-mail]>; Thu, 2 Sep 1999 09:18:58 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 02 Sep 1999 10:20:45 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Thu, 02 Sep 1999 10:20:37 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Deprecate the NR bit?
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_FFA90BCD.9CFD9EAE"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_FFA90BCD.9CFD9EAE
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Steve, is exactly right, there -- this is precisely why I wanted to =
clearly define
what the NR bit meant, so we would know whether or not an application =
should
be allowed to use such a key.

Unfortunately, by not defining the semantics of the bit precisely, we now =
have the
predictable situation where various CAs and institutions like DOD are =
using the bit in=20
mutually contradictory fashion, making it nearly impossible to say =
anything meaningful
about the purpose of that bit, and thereby degrading its utility to =
practically zero.

Although I strongly agree with the concept of requiring either the =
presence or=20
the absence of the NR bit with respect to certain applications, at this =
point the=20
meaning, and hence the value of the bit has been so degraded that =
personally,
I despair of ever getting the horses back into the barn.

That's why I suggested deprecating the existing bit, and defining some new =
ones with
very carefully crafted semantics.

Maybe Tom Gundin can pull the fat out of the fire (I seem to be on a =
metaphor roll :-)
and come up with a definition of some useful function that we can all =
agree to for=20
the existing bit -- if so, he will certainly deserve a medal.

But even if he comes up with a satisfactory, suitably limited definition =
of "technical NR"
or something like that, I think we have clearly identified a need for =
additional=20
functionality that needs to be endorsed by the CA in order to constitute =
adequate
notice. so I think additional bits will be necessary.  Whether we put them =
in the keyUsage
or the extendedKeyUsage fields, I don't care.

Bob



>>> Stephen Kent <[e-mail]> 08/31/99 08:20AM >>>
At 8:53 AM -0700 8/30/99, Aram Perez wrote:

>Ron Ramsay wrote:
>
>> Except that the NR bit cannot be added to the certificate by the
>> application!
>
>But the application can add a much better indicator to the data that =
needs
>to be part of the evidence that supports non-repudiation as has been
>proposed on this mailing list.

Not all applications may be trusted to properly assert invocation  of NR
services.  By including the NR bit in a cert, we have a (potentially)
higher assurance mechanism that can allow or prohibit an application from
invoking NR services.  For example, if one provides an application with
access to certs ONLY with NR=3D0, we can ensure that these apps cannot =
assert
that they are acting in an NR capacity on behalf of the user. This is a
very useful security facility and a good reason to keep the NR bit.

Steve

--=_FFA90BCD.9CFD9EAE
Content-Type: text/plain
Content-Disposition: attachment; filename="TEXT.htm"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff 
style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
<DIV>Steve, is exactly right, there -- this is precisely why I wanted to clearly 
define</DIV>
<DIV>what the NR bit meant, so we would know whether or not an application 
should</DIV>
<DIV>be allowed to use such a key.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Unfortunately, by not defining the semantics of the bit precisely, we now 
have the</DIV>
<DIV>predictable situation where various CAs and institutions like DOD are using 
the bit in </DIV>
<DIV>mutually contradictory fashion, making it nearly impossible to say anything 
meaningful</DIV>
<DIV>about the purpose of that bit, and thereby degrading its utility to 
practically zero.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Although I strongly agree with the concept of requiring either the presence 
or </DIV>
<DIV>the absence of the NR bit with respect to certain applications, at this 
point the </DIV>
<DIV>meaning, and hence the value of the bit has been so degraded that 
personally,</DIV>
<DIV>I despair of ever getting the horses back into the barn.</DIV>
<DIV>&nbsp;</DIV>
<DIV>That's why I suggested deprecating the existing bit, and defining some new 
ones with</DIV>
<DIV>very carefully crafted semantics.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Maybe Tom Gundin can pull the fat out of the fire (I seem to be on a 
metaphor roll :-)</DIV>
<DIV>and come up with a definition of some useful function that we can all agree 
to for </DIV>
<DIV>the existing bit -- if so, he will certainly deserve a medal.</DIV>
<DIV>&nbsp;</DIV>
<DIV>But even if he comes up with a satisfactory, suitably limited definition of 
&quot;technical NR&quot;</DIV>
<DIV>or something like that, I think we have clearly identified a need for 
additional </DIV>
<DIV>functionality that needs to be endorsed by the CA in order to constitute 
adequate</DIV>
<DIV>notice. so I think additional bits will be necessary.&nbsp; Whether we put 
them in the keyUsage</DIV>
<DIV>or the extendedKeyUsage fields, I don't care.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Bob</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt;&gt;&gt; Stephen Kent &lt;<A 
href="mailto:[e-mail]">[e-mail]</A>&gt; 08/31/99 08:20AM 
&gt;&gt;&gt;<BR>At 8:53 AM -0700 8/30/99, Aram Perez wrote:<BR><BR>&gt;Ron 
Ramsay wrote:<BR>&gt;<BR>&gt;&gt; Except that the NR bit cannot be added to the 
certificate by the<BR>&gt;&gt; application!<BR>&gt;<BR>&gt;But the application 
can add a much better indicator to the data that needs<BR>&gt;to be part of the 
evidence that supports non-repudiation as has been<BR>&gt;proposed on this 
mailing list.<BR><BR>Not all applications may be trusted to properly assert 
invocation&nbsp; of NR<BR>services.&nbsp; By including the NR bit in a cert, we 
have a (potentially)<BR>higher assurance mechanism that can allow or prohibit an 
application from<BR>invoking NR services.&nbsp; For example, if one provides an 
application with<BR>access to certs ONLY with NR=0, we can ensure that these 
apps cannot assert<BR>that they are acting in an NR capacity on behalf of the 
user. This is a<BR>very useful security facility and a good reason to keep the 
NR bit.<BR><BR>Steve<BR></DIV></BODY></HTML>

--=_FFA90BCD.9CFD9EAE--


Received: from walnut.nbsi.com (walnut.nbsi.com [167.70.219.4]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA29577 for <[e-mail]>; Thu, 2 Sep 1999 08:49:59 -0700 (PDT)
Received: from smtpsw01 ([167.70.64.80]) by walnut.nbsi.com (Netscape Messaging Server 3.61)  with ESMTP id AAB2A90; Thu, 2 Sep 1999 10:46:43 -0500
Date: Thu, 02 Sep 1999 08:51:23 -0700
From: Mack Hicks <[e-mail]>
Subject: Re: End-Entity Certificate Policies
To: "Miklos, Sue A." <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <[e-mail]>

Sandi

As you may well imagine, in our case with many financial institutions
participating in a certificate hierarchy, it is virtually impossible for
all institutions to agree on minor details of policy. Our attempt to
address this issue is to have an overarching  policy that says: this
certificate is part of the hierarchy (proven by cert. path). The other
policies (optional) will be used by institutions to further define their
policies which may have applicability both within the hierarchy and
within other hierarchies.

All the policies domains for the EE are known in advance through
contract between EE and Institution. The relying parties may not know of
a particular EE's additional policy domains, but these can be made clear
by on-line query to the relying party's institution. We see no need to
generate additional certificates or attribute certificates since
additional information can be obtained on-line from the relying party's
institution who communicates with the EE's institution.

Mack

"Miklos, Sue A." wrote:

>
>
> Please forgive a potentially ignorant question, but I am at a loss to
> understand the operational perspective when putting multiple policy
> oids (or any attribute values) into a certificate when it is initially
> generated and signed.  Is the thought that when an EE gets a cert,
> that all of the appropriate policy domains will be known and
> populated, in advance?  Will the addition of subsequent oids require
> generating new certs (and the accompanying revocation of the 'old'
> certs)?
>
> Sandi Miklos
>

--
-------------------------------------------------------------------
Mack Hicks, VP     [e-mail]
Bank of America  [phone]




Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA27433 for <[e-mail]>; Thu, 2 Sep 1999 06:57:04 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA19222; Thu, 2 Sep 1999 06:52:32 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 02 Sep 1999 09:56:58 -0400
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: some comments on ISPs, wiretaps, etc.
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Peter & Steve:

 >>> In the specific case of the Authenticode example, I agree that it might be
 >>> reasonable to amend 2459 to allow the NR bit to be set as well as the DS
 >>> bit.
 >>
 >>This was discussed before, and the list agreed with
 >>my assertion then, as you evidently do now. Unaccountable
 >>offline msgs got the bit removed, presumably.
 >
 >I don't recall that "the list agreed" on this topic, but then the length of
 >many of your messages precludes reading them to the end :-).  If the 2459
 >authors agree, then we're OK.

Nothing in this very long series of NR-related threads has convinced me 
that a change to the RFC 2459 section on key usage is necessary.  Of 
course, the other authors are free to express their own thoughts on the matter.

Russ


Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.9.3/8.9.3) with SMTP id GAA27290 for <[e-mail]>; Thu, 2 Sep 1999 06:55:48 -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 JAA18012; Thu, 2 Sep 1999 09:57:15 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 02 Sep 1999 09:57:40 -0400
To: "Miklos, Sue A." <[e-mail]>, "'Mack Hicks'" <[e-mail]>, Sharon Boeyen <[e-mail]>
From: Bill Burr <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Cc: "'Charles Moore'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail] c.mil>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"

Sandi,


I don't think that it's obvious what you would do in every case.  In most
cases I suspect that CA's who wished to add a policy OID to a certificate
would first revoke the old certificate, but I don't think that there is
necessarily any reason that they must revoke the existing certificate,
when they add a new policy OID and issue a new certificate.  There may
even be some operational reasons not to revoke the old certificate, so
that old signatures executed with it continue to verify for some period
with a current CRL.


If you need to remove a policy OID from a certificate, then I think that
you have to revoke it and issue another.


I think that a lot of disparate things have been swept under the
certificate policies rug.  Lacking attribute certificates, and given a
state machine for processing certificate policy OIDs in identity
certificates, various folks seem to want to use what they believe they
have now, the certificate policies extension, to solve problems that
might be better addressed by separate attribute certificates.  It looks
to me like Mack's use of certificate policies might well be better
addressed by attribute certificates.  But we don't have attribute
certificate now (nor, truly, do we have many clients today that process
the certificate policies extension).  




At 08:55 AM 9/2/99 -0400, Miklos, Sue A. wrote: 

>>>>

<excerpt>

<smaller>Please forgive a potentially ignorant question, but I am at a
loss to understand the operational perspective when putting multiple
policy oids (or any attribute values) into a certificate when it is
initially generated and signed.  Is the thought that when an EE gets a
cert, that all of the appropriate policy domains will be known and
populated, in advance?  Will the addition of subsequent oids require
generating new certs (and the accompanying revocation of the 'old'
certs)?

</smaller>

<smaller>Sandi Miklos</smaller> 


<smaller>-----Original Message-----</smaller> 

<smaller>From: Mack Hicks
[<<mailto:[e-mail]>mailto:[e-mail]]</smaller> 

<smaller>Sent: Wednesday, September 01, 1999 11:18 AM</smaller> 

<smaller>To: Sharon Boeyen</smaller> 

<smaller>Cc: 'Charles Moore'; '[e-mail]';
'[e-mail]'</smaller> 

<smaller>Subject: Re: End-Entity Certificate Policies</smaller> 



<smaller>Sharon,</smaller> 


<smaller>I agree with you. I have a real business need for multiple OIDs
in an End Entity</smaller> 

<smaller>Certificate.</smaller> 


<smaller>In the Identrus community, all certificates under the Identrus
Root must have</smaller> 

<smaller>the OID of Identrus. It is expected that relying parties may be
receiving</smaller> 

<smaller>certificates from multiple participants and sub-CAs within the
structure. It is</smaller> 

<smaller>easier for the relying party to be able to identify an Identrus
certificate and</smaller> 

<smaller>its context of use through the Identrus OID. Restricting the
number of OIDs</smaller> 

<smaller>means that the relying party has no way of determining a
membership in a broader</smaller> 

<smaller>community. Further, the sub-CAs have no way for providing
further policy context</smaller> 

<smaller>of an end-entity certificate. (I realize that cert path
validation would</smaller> 

<smaller>identify these communities, but the relying party may not have
all the</smaller> 

<smaller>certificates in the path.)</smaller> 


<smaller>I do not see the any advantage to mandating  only a single OID
in an EE</smaller> 

<smaller>certificate. From a business view, the result is to proliferate
the number of</smaller> 

<smaller>policy documents.</smaller> 


<smaller>Mack Hicks</smaller> 


<smaller>Sharon Boeyen wrote:</smaller> 


<smaller>> I don't support limiting to a single policy OID or limiting
the use of</smaller> 

<smaller>> qualifiers only to end-entity certs. Even if this was agreed
as part of</smaller> 

<smaller>> the PKIX profile for what CAs were to do, relying parties
presumably would</smaller> 

<smaller>> need to be able to deal with certs that were created outside
of PKIX and</smaller> 

<smaller>> these might very well have multiple policies in the end-entity
certs and</smaller> 

<smaller>> qualifiers in the CA certs. So at best this proposal might
impose limits</smaller> 

<smaller>> on CA behavior for PKIX CAs, but probably couldn't on PKIX
relying parties</smaller> 

<smaller>> unless we want to isolate the PKIX world from the rest of the
world :-(</smaller> 

<smaller>></smaller> 

<smaller>> Sharon</smaller> 

<smaller>></smaller> 


<smaller>--</smaller> 

<smaller>-------------------------------------------------------------------</smaller> 

<smaller>Mack Hicks, VP     [e-mail]</smaller> 

<smaller>Bank of America  [phone]</smaller> 


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




Regards,


Bill Burr


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA26071 for <[e-mail]>; Thu, 2 Sep 1999 05:53:56 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA27549 for <[e-mail]>; Thu, 2 Sep 1999 08:56:16 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA27495 for <[e-mail]>; Thu, 2 Sep 1999 08:56:05 -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 IAA29082 for <[e-mail]>; Thu, 2 Sep 1999 08:55:51 -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]>; Thu, 02 Sep 1999 08:55:35 -0400
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <Q2Z2HYZB>; Thu, 2 Sep 1999 08:55:49 -0400
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Mack Hicks'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: "'Charles Moore'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Date: Thu, 2 Sep 1999 08:55:48 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BEF542.7AA8AC56"

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_01BEF542.7AA8AC56
Content-Type: text/plain;
	charset="iso-8859-1"

Please forgive a potentially ignorant question, but I am at a loss to
understand the operational perspective when putting multiple policy oids (or
any attribute values) into a certificate when it is initially generated and
signed.  Is the thought that when an EE gets a cert, that all of the
appropriate policy domains will be known and populated, in advance?  Will
the addition of subsequent oids require generating new certs (and the
accompanying revocation of the 'old' certs)?

Sandi Miklos

-----Original Message-----
From: Mack Hicks [mailto:[e-mail]]
Sent: Wednesday, September 01, 1999 11:18 AM
To: Sharon Boeyen
Cc: 'Charles Moore'; '[e-mail]'; '[e-mail]'
Subject: Re: End-Entity Certificate Policies


Sharon,

I agree with you. I have a real business need for multiple OIDs in an End
Entity
Certificate.

In the Identrus community, all certificates under the Identrus Root must
have
the OID of Identrus. It is expected that relying parties may be receiving
certificates from multiple participants and sub-CAs within the structure. It
is
easier for the relying party to be able to identify an Identrus certificate
and
its context of use through the Identrus OID. Restricting the number of OIDs
means that the relying party has no way of determining a membership in a
broader
community. Further, the sub-CAs have no way for providing further policy
context
of an end-entity certificate. (I realize that cert path validation would
identify these communities, but the relying party may not have all the
certificates in the path.)

I do not see the any advantage to mandating  only a single OID in an EE
certificate. From a business view, the result is to proliferate the number
of
policy documents.

Mack Hicks

Sharon Boeyen wrote:

> I don't support limiting to a single policy OID or limiting the use of
> qualifiers only to end-entity certs. Even if this was agreed as part of
> the PKIX profile for what CAs were to do, relying parties presumably would
> need to be able to deal with certs that were created outside of PKIX and
> these might very well have multiple policies in the end-entity certs and
> qualifiers in the CA certs. So at best this proposal might impose limits
> on CA behavior for PKIX CAs, but probably couldn't on PKIX relying parties
> unless we want to isolate the PKIX world from the rest of the world :-(
>
> Sharon
>

--
-------------------------------------------------------------------
Mack Hicks, VP     [e-mail]
Bank of America  [phone]


------_=_NextPart_001_01BEF542.7AA8AC56
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: End-Entity Certificate Policies</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Please forgive a potentially ignorant question, but I =
am at a loss to understand the operational perspective when putting =
multiple policy oids (or any attribute values) into a certificate when =
it is initially generated and signed.&nbsp; Is the thought that when an =
EE gets a cert, that all of the appropriate policy domains will be =
known and populated, in advance?&nbsp; Will the addition of subsequent =
oids require generating new certs (and the accompanying revocation of =
the 'old' certs)?</FONT></P>

<P><FONT SIZE=3D2>Sandi Miklos</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mack Hicks [<A =
HREF=3D"mailto:[e-mail]">mailto:mack.hicks@bankofame=
rica.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, September 01, 1999 11:18 AM</FONT>
<BR><FONT SIZE=3D2>To: Sharon Boeyen</FONT>
<BR><FONT SIZE=3D2>Cc: 'Charles Moore'; '[e-mail]'; =
'[e-mail]'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: End-Entity Certificate Policies</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Sharon,</FONT>
</P>

<P><FONT SIZE=3D2>I agree with you. I have a real business need for =
multiple OIDs in an End Entity</FONT>
<BR><FONT SIZE=3D2>Certificate.</FONT>
</P>

<P><FONT SIZE=3D2>In the Identrus community, all certificates under the =
Identrus Root must have</FONT>
<BR><FONT SIZE=3D2>the OID of Identrus. It is expected that relying =
parties may be receiving</FONT>
<BR><FONT SIZE=3D2>certificates from multiple participants and sub-CAs =
within the structure. It is</FONT>
<BR><FONT SIZE=3D2>easier for the relying party to be able to identify =
an Identrus certificate and</FONT>
<BR><FONT SIZE=3D2>its context of use through the Identrus OID. =
Restricting the number of OIDs</FONT>
<BR><FONT SIZE=3D2>means that the relying party has no way of =
determining a membership in a broader</FONT>
<BR><FONT SIZE=3D2>community. Further, the sub-CAs have no way for =
providing further policy context</FONT>
<BR><FONT SIZE=3D2>of an end-entity certificate. (I realize that cert =
path validation would</FONT>
<BR><FONT SIZE=3D2>identify these communities, but the relying party =
may not have all the</FONT>
<BR><FONT SIZE=3D2>certificates in the path.)</FONT>
</P>

<P><FONT SIZE=3D2>I do not see the any advantage to mandating&nbsp; =
only a single OID in an EE</FONT>
<BR><FONT SIZE=3D2>certificate. From a business view, the result is to =
proliferate the number of</FONT>
<BR><FONT SIZE=3D2>policy documents.</FONT>
</P>

<P><FONT SIZE=3D2>Mack Hicks</FONT>
</P>

<P><FONT SIZE=3D2>Sharon Boeyen wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I don't support limiting to a single policy OID =
or limiting the use of</FONT>
<BR><FONT SIZE=3D2>&gt; qualifiers only to end-entity certs. Even if =
this was agreed as part of</FONT>
<BR><FONT SIZE=3D2>&gt; the PKIX profile for what CAs were to do, =
relying parties presumably would</FONT>
<BR><FONT SIZE=3D2>&gt; need to be able to deal with certs that were =
created outside of PKIX and</FONT>
<BR><FONT SIZE=3D2>&gt; these might very well have multiple policies in =
the end-entity certs and</FONT>
<BR><FONT SIZE=3D2>&gt; qualifiers in the CA certs. So at best this =
proposal might impose limits</FONT>
<BR><FONT SIZE=3D2>&gt; on CA behavior for PKIX CAs, but probably =
couldn't on PKIX relying parties</FONT>
<BR><FONT SIZE=3D2>&gt; unless we want to isolate the PKIX world from =
the rest of the world :-(</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Sharon</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
----</FONT>
<BR><FONT SIZE=3D2>Mack Hicks, VP&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Bank of America&nbsp; [phone]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BEF542.7AA8AC56--


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA04163 for <[e-mail]>; Wed, 1 Sep 1999 18:38:27 -0700 (PDT)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 1 Sep 1999 18:40:42 -0700
Message-ID: <[e-mail]>
Date: Wed, 01 Sep 1999 21:38:36 -0400
From: Alfred Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: PKIX certs with iPAddress
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Folks,

	Does anybody know of a pointer to some "PKIX-compliant" certs with an
iPAddress in the subjectAltName extension?  I've been cobbling together
some software to parse various claimed-2459-compliant certs, and I'd
like to get a few of those to test against.  (I think I have most of the
other extensions/values that I care about to test already.)

	Thanks in advance for any help,

			Al Arsenault


Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA01238 for <[e-mail]>; Wed, 1 Sep 1999 17:50:33 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id RAA25013 for <[e-mail]>; Wed, 1 Sep 1999 17:51:53 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 01 Sep 1999 17:55:03 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: SCVP-01
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

When OCSP was winding into WG last call, I asked at the PKIX meeting (in
Orlando?) to make OCSP's signature mechanism syntactically optional, for
exactly this reason.

I think maybe two other people in the room thought this was a good idea
at that time.

		Marc


"David P. Kemp" wrote:
> 
> > From: "Peter Williams" <[e-mail]>
> >
> > Policy WG, and reuse: I would like to see the SCVP
> > specification take component form, enabling its
> > object to be reused in the extension mechanisms of other
> > suitable value-adding services, including CMP and DCS.
> 
> I would like to see that too.  It's in the spirit of the (now-defunct)
> Certificate Management Message Format (CMMF):
> 
>  * define a set of messages, and define the sequence of messages exchanged
>     to perform a particular action.
>  * encapsulate/protect the messages using whatever transport/security
>     mechanism (CMP, CMS, DCS, AH/ESP, ...) fits the bill.
> 
> Defining transport-independent message sets for specific purposes
> reduces the difference between "a lot of single-purpose protocols" and
> "one big do-everything protocol", enables reuse of existing transport
> modules/APIs, and as a design paradigm should be a no-brainer.
> 
> Whatever happened to CMMF anyway?  Is this the time to revive it, before
> CMP and CMC go to Draft?


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA00712 for <[e-mail]>; Wed, 1 Sep 1999 17:21:56 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id RAA26409; Wed, 1 Sep 1999 17:24:11 -0700 (PDT)
Received: from rsalaptop ([192.168.3.230]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id RAA16768; Wed, 1 Sep 1999 17:24:11 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Carlisle Adams" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: SCVP-01
Date: Wed, 1 Sep 1999 17:25:28 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>

Carlisle:

> Are you suggesting that if, in fact, DCS is not "tied to the ISO NR
> framework" then DCS is a reasonable place to put the SCVP syntax and
> functionality?


I see it as perfectly reasonable for DCS to offer its
users a validation service. This is currently a side-effect,
and not the main purpose of DCS, however. 

If a DCS authority can perform path validation for its own 
ends, upon  whose outcome its signature is contingent,
then surely it can perform the same processing
as a service for other relying parties. This
logic was my original thinking in suggesting
and investigating a DCS linkup. 

Ambarish had a different perspective,
and asked if a conforming DCS client could be 
implemented in a week? As we could not break DCS up into
components, and believed that it was necessary to 
provide for NR-grade validation, things went another 
direction. It was taking longer to talk about
it then to implement it.

Specifying a wrapper in DCS to incorporate the
SCVP ASN.1 seems like a perfect match. SCVP
stands by itself, small and light, like OCSP. But it
can play a supporting role in DCS, for those
who implement and use DC authorities. DCS should
treat OCSP similarly, perhaps. DCS can act
as the feature aggregating service, for those who
want "comprehensive, full-service PKI" - to
use a marketing phrase. I'm not sure why
a small router would want to implement a
full-service layer 7 data certification suite, 
however. And this is why SCVP should be
both a reusable and stand alone component.
 
Regards,
Peter.

 
 

  


Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mail.proper.com (8.9.3/8.9.3) with SMTP id QAA29885 for <[e-mail]>; Wed, 1 Sep 1999 16:13:25 -0700 (PDT)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Sep 1999 16:14:52 -0700 (Pacific Daylight Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.14) id <R9R7YWBG>; Wed, 1 Sep 1999 16:14:52 -0700
Message-ID: <CB6657D3A5E0D111A97700805FFE6587DBE294@RED-MSG-51>
From: Vic Heller <[e-mail]>
To: Trevor Freeman <[e-mail]>, [e-mail]
Cc: "'?@0fHq'" <[e-mail]>
Subject: RE: New Microsoft cert extension?
Date: Wed, 1 Sep 1999 16:14:49 -0700 
X-Mailer: Internet Mail Service (5.5.2650.14)

The red, underlined text below is ambiguous.  When generating a new key, the
Key Index is set to match the new Cert Index.
Read my recent mail for further details.

> -----Original Message-----
> From:	Trevor Freeman 
> Sent:	Wednesday, September 01, 1999 11:08 AM
> To:	[e-mail]
> Cc:	'?@0fHq'
> Subject:	RE: New Microsoft cert extension?
> 
> This extension in a Win2K CA certificate is a counter as to how many
> certificate/keys the CA has.
> If you renew a win2K CA's certificate and re-certify the current key we
> increment the certificate index. If renew a win2K CA's certificate and
> certify a new key we increment the certificate and key indexes. We treat
> the
> integer as a DWORD, taking the low 16 bits as the cert index and the high
> 16
> bits as the key index. so in our UI we represent it as cert index.key
> index.
> This extension is used by us when a Win2K CA is restored, as a hint to
> rebuild the certificate\key lists. It has no other purpose.
> 
> -----Original Message-----
> From: ¿À°æÈñ [mailto:[e-mail]]
> Sent: Tuesday, August 31, 1999 6:11 PM
> To: [e-mail]
> Subject: Re: New Microsoft cert extension?
> 
> 
> PRIVATE ENTERPRISE NUMBERS
>  SMI Network Management Private Enterprise Codes:
> Prefix: iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)
> 
> This file is
>           ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers
> 
> Decimal   Name                                                References
> -------   ----                                                ----------
>   311   Microsoft             John M. Ballard   [e-mail]
> 
> 
> Try to mail to the address above.
> 
> If you get the answer, please let me know.
> 
> 
> 
> Marc Branchaud wrote:
> 
> > Found an extension with this OID in a Win2K cert: 1.3.6.1.4.1.311.21.1.
> > Here's what it looks like from Peter Gutmann's dumpasn1:
> >
> >  576 30   16:         SEQUENCE {
> >  578 06    9:           OBJECT IDENTIFIER '1 3 6 1 4 1 311 21 1'
> >  589 04    3:           OCTET STRING, encapsulates {
> >  591 02    1:               INTEGER 0
> >             :               }
> >             :           }
> >
> > I believe that 1.3.6.1.4.1.311 belongs to Microsoft, but does anyone
> > know what this extension is?
> >
> >                 Marc


Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.9.3/8.9.3) with SMTP id PAA29106 for <[e-mail]>; Wed, 1 Sep 1999 15:25:04 -0700 (PDT)
Received: 	id SAA02904; Wed, 1 Sep 1999 18:23:17 -0400
Received: by gateway id <NP65NKDY>; Wed, 1 Sep 1999 18:25:55 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Peter Williams'" <[e-mail]>
Cc: [e-mail]
Subject: RE: SCVP-01
Date: Wed, 1 Sep 1999 18:25:54 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Hi Peter,

> ----------
> From: 	Peter Williams[SMTP:[e-mail]]
> Sent: 	Tuesday, August 31, 1999 9:54 AM
> To: 	Alan Lloyd
> Cc: 	[e-mail]
> Subject: 	RE: SCVP-01
 
(...some text deleted...)

> I was disappointed in the Microsoft message: ...
> 
> I was disappointed by the Novell message: ...
> 
> Carlisle's ambiguous message ...
 
What a depressing couple of days you must have had!  How in the world are
you still finding the motivation to get up in the morning?  :-)

> DCS. There was consideration of using DCS as the vehicle
> by which to introduce validation checking into PKIX: we
> were halted in our tracks when the authors required things be
> tied to the ISO NR framework.  Sensibly, Ambarish heeded the
> simplicity goal, and chose not to be tied to a heavy-weight
> concept.  
 
I just looked again at the (off-line) e-mails we exchanged a few months ago
regarding this topic.  Our objections had nothing whatsoever to do with
wanting DCS to be tied to the ISO NR framework.  You and Ambarish suggested
splitting DCS into a base document and multiple smaller documents that
provide details for particular services.  Rob and I thought that although
this sounds great in theory, in practice it tends to be confusing and
ultimately unproductive (and we cited CMP/CRMF/CMMF/CMC as an example that
would loom fresh in PKIX minds).  Our preference was to keep a single
document, essentially structured as-is with its reasonable extension
mechanism for future additional services.  Somehow you took this to mean
that DCS was tied to the non-repudiation framework in a leap of logic that
mystified me then and still mystifies me now.

In any case, our objection to splitting up DCS was not intended to "halt you
in your tracks" and force you to create a different protocol.

> We can recall, that DCS extension can
> easily wrap the SCVP ASN.1 info object and thereby incorporate
> the standard validation protocol into DCS, for the NR-grade
> certificate handling. Presumably, the NR requirements
> will add to SCVP requirements for remote path processing,
> as to-be-specified in the DCS draft.
 
Are you suggesting that if, in fact, DCS is not "tied to the ISO NR
framework" then DCS is a reasonable place to put the SCVP syntax and
functionality?

Carlisle.



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA26902 for <[e-mail]>; Wed, 1 Sep 1999 12:17:39 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id MAA24384; Wed, 1 Sep 1999 12:19:53 -0700 (PDT)
Received: from rsalaptop ([192.168.3.230]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id MAA10297; Wed, 1 Sep 1999 12:19:52 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Bill Burr" <[e-mail]>, <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Date: Wed, 1 Sep 1999 12:21:12 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>

 
> Good idea, as far as I can see.  If policy qualifiers have a use, it's
> surely for EE certs.  Heaven forbid that every successive CA cert 
> in a path
> should cause a message to be displayed, or require a click acceptance.
 

The particular processing you suggest for handling qualifiers in
critical policy extensions w/qualifiers should
be distinguished from the mere existence of
a qualifier value, in critical or non-critical policy
extensions.

If you check a VeriSign public intermediate CA using
the Windows UI interface, for example, it *offers*
you a button, which you *may* click, to chase
down the https URL built into the qualifier
of a non-critical policy extension, and learn
today's details of what reliance means, and determine
the warranted financial protections offered today. 
There is no downside to this design. There are many
upsides for PKIs addressing trade
and commerce whose activates are backed
by reinsurance. Removing it serves no purpose. It
has zero relevance to the cited bug fix, and
seems to reflect Russ' personal preference
to remove qualifiers from the face of the earth.

His preference was not reasonable during
2459 design, and is still not reasonable.
No particular military of US Federal assurance domain 
is required to use or accept them, however. Those 
other domains that do, accrue many benefits.

As the internet PKI is a collection of autonomous
domains, who can evidently interoperate using
PKIX rules, the current working infrastructure 
should continue.






Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA26268 for <[e-mail]>; Wed, 1 Sep 1999 11:29:48 -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 OAA11725 for <[e-mail]>; Wed, 1 Sep 1999 14:32:33 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 01 Sep 1999 14:33:01 -0400
To: [e-mail]
From: Bill Burr <[e-mail]>
Subject: Re: End-Entity Certificate Policies
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Russ and Tim,

Wow, I'm somewhat in shock.  Limiting qualifiers to EE certs is probably a
good idea, but what problem does limiting EE certs to a single policy fix?
Comments in-line below:

At 04:56 PM 8/31/99 -0400, you wrote:
>Tim Polk and I got together today to discuss the changes needed to address 
>the policy mapping bug (as discussed at the Oslo meeting).  As part of this 
>discussion, we discussed the certificate policy extension.
>
>We believe that a CA certificate may contain one or more certificate policy 
>OID.  On the other hand, we believe that an end-entity certificate 
>containing a certificate policy extension must  contain a single 
>certificate policy OID.  

<SNIP>

>
>Does anyone disagree?


As you know, the Gov. of Canada, the US DoD and the US Federal PKI at
least, contemplate using policies for some sort of ordered "assurance
level."  The GOC defines four: rudimentary, low, medium and high.  I
believe that the assumption has been that anyone who would accept low would
also accept medium or high.  The straightforward way to handle this would
then be to put all four OIDs in high assurance certificates, medium, low
and rudimentary in medium assurance certificates, etc.  Your proposal seems
to break that.

The alternative is to make the relying party's initial set include all the
higher assurance level policies.  This seems cumbersome to me, and to move
the complexity to the client at run time, when we could handle it in the
certificates.     

Also, wouldn't it be useful to have separate OIDs in an EE cert for on-line
banking, stock trading, and other separable services that a single
financial institution might offer?  Do we want to force one bank or one
association to issued different certificates to the same person, for every
separate application?

What problem are we fixing here???

>
>Tim and I also discussed certificate policy qualifiers.  Tim and I agree 
>that certificate policy qualifiers should only appear in end-entity 
>certificates.  That is, we agree that certificate policy qualifier should 
>never appear in a CA certificate.  Does anyone (besides Mike Baum) disagree?

Good idea, as far as I can see.  If policy qualifiers have a use, it's
surely for EE certs.  Heaven forbid that every successive CA cert in a path
should cause a message to be displayed, or require a click acceptance.

>
>Russ
>
>
Regards,

Bill Burr


Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA25866 for <[e-mail]>; Wed, 1 Sep 1999 11:07:23 -0700 (PDT)
Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Sep 1999 11:08:50 -0700 (Pacific Daylight Time)
Received: by INET-IMC-04 with Internet Mail Service (5.5.2524.0) id <SAVJWFZA>; Wed, 1 Sep 1999 11:08:50 -0700
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0F526651@RED-MSG-56>
From: Trevor Freeman <[e-mail]>
To: [e-mail]
Cc: "'¿À°æÈñ'" <[e-mail]>
Subject: RE: New Microsoft cert extension?
Date: Wed, 1 Sep 1999 11:08:18 -0700 
X-Mailer: Internet Mail Service (5.5.2524.0)

This extension in a Win2K CA certificate is a counter as to how many
certificate/keys the CA has.
If you renew a win2K CA's certificate and re-certify the current key we
increment the certificate index. If renew a win2K CA's certificate and
certify a new key we increment the certificate and key indexes. We treat the
integer as a DWORD, taking the low 16 bits as the cert index and the high 16
bits as the key index. so in our UI we represent it as cert index.key index.
This extension is used by us when a Win2K CA is restored, as a hint to
rebuild the certificate\key lists. It has no other purpose.

-----Original Message-----
From: ¿À°æÈñ [mailto:[e-mail]]
Sent: Tuesday, August 31, 1999 6:11 PM
To: [e-mail]
Subject: Re: New Microsoft cert extension?


PRIVATE ENTERPRISE NUMBERS
 SMI Network Management Private Enterprise Codes:
Prefix: iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)

This file is
          ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers

Decimal   Name                                                References
-------   ----                                                ----------
  311   Microsoft             John M. Ballard   [e-mail]


Try to mail to the address above.

If you get the answer, please let me know.



Marc Branchaud wrote:

> Found an extension with this OID in a Win2K cert: 1.3.6.1.4.1.311.21.1.
> Here's what it looks like from Peter Gutmann's dumpasn1:
>
>  576 30   16:         SEQUENCE {
>  578 06    9:           OBJECT IDENTIFIER '1 3 6 1 4 1 311 21 1'
>  589 04    3:           OCTET STRING, encapsulates {
>  591 02    1:               INTEGER 0
>             :               }
>             :           }
>
> I believe that 1.3.6.1.4.1.311 belongs to Microsoft, but does anyone
> know what this extension is?
>
>                 Marc


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA25583 for <[e-mail]>; Wed, 1 Sep 1999 10:53:56 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id KAA23723; Wed, 1 Sep 1999 10:56:10 -0700 (PDT)
Received: from rsalaptop ([192.168.3.230]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id KAA08337; Wed, 1 Sep 1999 10:56:10 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Nick Pope" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: New Internet Draft on Non-Repudiation Requirements
Date: Wed, 1 Sep 1999 10:57:30 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <000701bef46c$bdab0660$0500000a@npwork2>

What is a "non-repudiation of data" service?

I have never heard that phrase before, in
10 years of doing PKI and/or secure layer
services.

(a) Is it the same as the X.400 proof of origin
with NR, service?

(b) is it the same as the DCS signature, on data
to be certified?

(a) and (b) and quite different, one notes. One
applies to messages in a communication
context, the other to data with no semantics
or context.

In the first case, one is asserting a undeniable
claim of origination, the other of existence. Clearly,
in other service variants, there are other
claims including X.435 "responsibility", and X.400's
claims of receipt, and/or delivery. There
are other telematic-service
related claims, backed up by NR assurances,
including legitimacy and authority, though
these are not modeled by OSI security model or
the ISO NR framework, to my knowledge.

> -----Original Message-----
> From: Nick Pope [mailto:[e-mail]]
> Sent: Wednesday, September 01, 1999 4:26 AM
> To: Denis Pinkas; [e-mail]
> Cc: [e-mail]
> Subject: RE: New Internet Draft on Non-Repudiation Requirements
>
>
> Denis,
>
> It is worth noting that in X.509 clause 11.2, note 2 states:
>
> " If a non-repudiation of data service is dependent on keys
> provided by the
> CA, the service should ensure that all relevant keys of the CA (revoked or
> expired) and the timestamped revocation lists are archived and
> certified by
> a current authority."
>
> This has relevance to our current work together as well as this list.  I
> believe that the word "timestamp"  refers to just a date a time
> value, not a
> trusted timestamp produced by a timestamping authory.
>
> Nick
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: 01 September 1999 09:22
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: New Internet Draft on Non-Repudiation Requirements
> >
> >
> > Tom,
> >
> > You said:
> >
> > >      I think that we should remember that the NR bit is
> > supposed to cause CRL
> > > archiving  as well.
> >
> > I am not sure what you mean by this statement. If you mean archiving
> > by the CA that issued the CRL, then I disagree. If you mean
> > archiving of CRL by the verifier when it first verifies the
> > signature, then I agree (but this archiving is not triggered by the
> > presence of the NR bit). But maybe you mean something else.
> >
> > Denis
> >
>



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA25174 for <[e-mail]>; Wed, 1 Sep 1999 10:19:53 -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 KAA25852; Wed, 1 Sep 1999 10:18:15 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 01 Sep 1999 10:18:18 -0700
To: Stephen Kent <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Multi-national company listing issues
Cc: <[e-mail]>
In-Reply-To: <v04020a15b3f1edd11300@[128.89.0.111]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:14 PM 8/31/99 -0400, Stephen Kent wrote:
>Tony,
>
>Ideally it would be the case that a party constructing a name under the
>C=US arc would be registered, but this is the exception rather than the
>rule.

OK.  I am major-ignorant in this area :)

But then there are two issues.  First, even in the case where the party
"gets registered" under C=US, does this designation have any universal
meaning to anyone (besides "ANSI-registered").

Second, if I were to declare my backyard a sovereign nation (TL, Tonyland)
and set up a CA service, are directory services prepared to store certs
under the designation "C=TL"?

Curious.

___tony___

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


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA24915 for <[e-mail]>; Wed, 1 Sep 1999 10:08:26 -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 KAA21652; Wed, 1 Sep 1999 10:10:27 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 01 Sep 1999 10:10:31 -0700
To: [e-mail], Denis Pinkas <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: New Internet Draft on Non-Repudiation Requirements
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:41 AM 9/1/99 -0400, [e-mail] wrote:
>     I was referring to X.509 (June '97 edition) section 11.2 note 2, which says
>"If a non-repudiation of data service is dependent on keys provided by the CA,
>the service should ensure that all relevant keys of the CA (revoked or expired)
>and the timestamped revocation lists are archived and certified by a current
>authority."  This is one of the very few statements in X.509 or RFC 2459 which
>makes clear demands on the CA in connection with the non repudiation service.
>Perhaps my reading of this passage as applying only to those CRL's which record
>the revocation of certificates with NR set but not to those which don't is
>debatable, but it certainly applies to them at a minimum.

Tom,

My strict interpretation of the statement:

>"If a non-repudiation of data service is dependent on keys provided by the CA,
>the service should ensure that all relevant keys of the CA (revoked or expired)
>and the timestamped revocation lists are archived and certified by a current
>authority."

... does not place demands upon the CA, per se.  What it says is that the
"non-repudiation of data service" should ensure that the relevant CA stuff
 is archived and certified."

Are you assuming that the NR-service is strictly provided by the CA?

___tony___




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


Received: from exchng-fairfax.p-e-c.com (exchng-fairfax.pec.com [204.254.216.13]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA24621 for <[e-mail]>; Wed, 1 Sep 1999 09:56:23 -0700 (PDT)
Received: by EXCHNG-FAIRFAX with Internet Mail Service (5.0.1460.8) id <QMYH603F>; Wed, 1 Sep 1999 12:59:13 -0400
Message-ID: <186F6BB05130D311902F0008C7F450FD03CFAD@EXCHNG-FAIRFAX>
From: MHenry <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: End-Entity Certificate Policies
Date: Wed, 1 Sep 1999 12:59:10 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain

Russ,
	The meaning of the sentence " In a CA certificate, these policy
information terms
	    limit the set of policies for certification paths which include
this
    certificate." is not clear to me. Could you explain?

Mike Henry

> -----Original Message-----
> From:	Russ Housley [SMTP:[e-mail]]
> Sent:	Tuesday, August 31, 1999 4:57 PM
> To:	[e-mail]
> Subject:	End-Entity Certificate Policies
> 
> Tim Polk and I got together today to discuss the changes needed to address
> 
> the policy mapping bug (as discussed at the Oslo meeting).  As part of
> this 
> discussion, we discussed the certificate policy extension.
> 
> We believe that a CA certificate may contain one or more certificate
> policy 
> OID.  On the other hand, we believe that an end-entity certificate 
> containing a certificate policy extension must  contain a single 
> certificate policy OID.  RFC 2459 says:
> 
>     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.
> 
> We would like to add words to make it more clear that an end-entity 
> certificate may only contain a single certificate policy OID.  The 
> explanation of this extension's purpose in a CA certificate was not
> spelled 
> out, so we propose to fix that too.  Our proposed text is:
> 
>     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.  In an end-entity
> certificate,
>     these policy information terms indicate the single policy under which
>     the certificate has been issued and the purposes for which the
> certificate
>     may be used.  In a CA certificate,  these policy information terms
>     limit the set of policies for certification paths which include this
>     certificate.  Optional qualifiers, which may be present, are not
>     expected to change the definition of the policy.
> 
> Does anyone disagree?
> 
> Tim and I also discussed certificate policy qualifiers.  Tim and I agree 
> that certificate policy qualifiers should only appear in end-entity 
> certificates.  That is, we agree that certificate policy qualifier should 
> never appear in a CA certificate.  Does anyone (besides Mike Baum)
> disagree?
> 
> Russ


Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with SMTP id IAA23640 for <[e-mail]>; Wed, 1 Sep 1999 08:20:55 -0700 (PDT)
Received: from PC1 by gmtsw.com (SMI-8.6/SMI-SVR4) id IAA05136; Wed, 1 Sep 1999 08:22:56 -0700
Message-ID: <007a01bef48f$e9d98540$[e-mail]>
From: "todd@gmtsw" <[e-mail]>
To: "Nick Pope" <[e-mail]>, "Denis Pinkas" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "Hoyt L. Kesterson II" <[e-mail]>, "Sharon Boeyen" <[e-mail]>
References: <000701bef46c$bdab0660$0500000a@npwork2>
Subject: X509 Language - Was Re: New Internet Draft on Non-Repudiation Requirements
Date: Wed, 1 Sep 1999 08:37:28 -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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Nick, Denis... with regard to the X.509 language... not the issue of the NR
bit -

----- Original Message -----
From: Nick Pope <[e-mail]>
To: Denis Pinkas <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, September 01, 1999 4:25 AM
Subject: RE: New Internet Draft on Non-Repudiation Requirements


> Denis,
>
> It is worth noting that in X.509 clause 11.2, note 2 states:
>
> " If a non-repudiation of data service is dependent on keys provided by
the
> CA, the service should ensure that all relevant keys of the CA (revoked or
> expired) and the timestamped revocation lists are archived and certified
by
> a current authority."

This should maybe read "Timebase Certified revocation lists" rather than
timestamped, unless the operations of CRL will embrace TS and DCS
technologies. The problem is that there is too much generic use of the term
'timestamp'. Since the format of the actual Timestamp is not defined in the
X.509 standard as well, it is confusing and makes the X.509 system dependant
on some undefined, external entity, called in this case "a timestamp"...
Unless the X.509 Timestamp is also to be defined too... maybe not such a bad
idea... (Hoyt/Sharon would X.509 look at embracing timestamping Tokens as
part of the token structure standards?)

It was a good thought to include this language, but in cert processing, the
key issue (pardon the pun)  is that the time data that is included in one
reference point, being *directly* comparable to that coming from other
entities. Otherwise the interoperability gets flushed. Here again we are
back to what the timestamping token or process is used for. To insure that
one is not trying to compare apples to oranges at the transaction level.
That the proofs issued by multiple systems are all comparable against each
other.

>
> This has relevance to our current work together as well as this list.  I
> believe that the word "timestamp"  refers to just a date a time value, not
a
> trusted timestamp produced by a timestamping authory.
>
> Nick

The context of the term timestamp, in this instance, maybe also refers to a
"legally binding" time value. This is the first place for a parametric data
source, that the term "legally binding" is justified in its use, since if
the trust-anchors for the X.509 process, that is the key info, the timebase
data, the source of the time, etc etc etc, are to be used to support
Commerce, then they too must be referencable. (any comments?)


Todd



Received: from walnut.nbsi.com (walnut.nbsi.com [167.70.219.4]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA23413 for <[e-mail]>; Wed, 1 Sep 1999 08:16:35 -0700 (PDT)
Received: from smtpsw01 ([167.70.64.80]) by walnut.nbsi.com (Netscape Messaging Server 3.61)  with ESMTP id AAB607B; Wed, 1 Sep 1999 10:13:05 -0500
Date: Wed, 01 Sep 1999 08:17:31 -0700
From: Mack Hicks <[e-mail]>
Subject: Re: End-Entity Certificate Policies
To: Sharon Boeyen <[e-mail]>
Cc: "'Charles Moore'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <[e-mail]>

Sharon,

I agree with you. I have a real business need for multiple OIDs in an End Entity
Certificate.

In the Identrus community, all certificates under the Identrus Root must have
the OID of Identrus. It is expected that relying parties may be receiving
certificates from multiple participants and sub-CAs within the structure. It is
easier for the relying party to be able to identify an Identrus certificate and
its context of use through the Identrus OID. Restricting the number of OIDs
means that the relying party has no way of determining a membership in a broader
community. Further, the sub-CAs have no way for providing further policy context
of an end-entity certificate. (I realize that cert path validation would
identify these communities, but the relying party may not have all the
certificates in the path.)

I do not see the any advantage to mandating  only a single OID in an EE
certificate. From a business view, the result is to proliferate the number of
policy documents.

Mack Hicks

Sharon Boeyen wrote:

> I don't support limiting to a single policy OID or limiting the use of
> qualifiers only to end-entity certs. Even if this was agreed as part of
> the PKIX profile for what CAs were to do, relying parties presumably would
> need to be able to deal with certs that were created outside of PKIX and
> these might very well have multiple policies in the end-entity certs and
> qualifiers in the CA certs. So at best this proposal might impose limits
> on CA behavior for PKIX CAs, but probably couldn't on PKIX relying parties
> unless we want to isolate the PKIX world from the rest of the world :-(
>
> Sharon
>

--
-------------------------------------------------------------------
Mack Hicks, VP     [e-mail]
Bank of America  [phone]




Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA23171 for <[e-mail]>; Wed, 1 Sep 1999 08:06:11 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id RAA20066; Wed, 1 Sep 1999 17:07:53 +0200
Message-ID: <[e-mail]>
Date: Wed, 01 Sep 1999 17:07:48 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: New Internet Draft on Non-Repudiation Requirements
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom,
 
>      I was referring to X.509 (June '97 edition) section 11.2 note 2, which says
> "If a non-repudiation of data service is dependent on keys provided by the CA,
> the service should ensure that all relevant keys of the CA (revoked or expired)
> and the timestamped revocation lists are archived and certified by a current
> authority."  

As far as I know, notes in an ISO standard are not normative.
Secondly, the sentence says "should". So this is not mandated.

> This is one of the very few statements in X.509 or RFC 2459 which
> makes clear demands on the CA in connection with the non repudiation service.
> Perhaps my reading of this passage as applying only to those CRL's which record
> the revocation of certificates with NR set but not to those which don't is
> debatable, but it certainly applies to them at a minimum.

The content of the note is very debatable and I suspect subject to
multiple interpretations. I would not even try to make it better
understandable.

I only wanted to point out that CAs issuing certificates with the NR
bit set are not *mandated* to do anything more than CA issuing
certificates with the NR bit not set.

Denis


 
>           Tom Gindin
> 
> Denis Pinkas <[e-mail]> on 09/01/99 04:22:04 AM
> 
> To:   Tom Gindin/Watson/IBM@IBMUS
> cc:   [e-mail]
> Subject:  Re: New Internet Draft on Non-Repudiation Requirements
> 
> Tom,
> 
> You said:
> 
> >      I think that we should remember that the NR bit is supposed to cause CRL
> > archiving  as well.
> 
> I am not sure what you mean by this statement. If you mean archiving
> by the CA that issued the CRL, then I disagree. If you mean
> archiving of CRL by the verifier when it first verifies the
> signature, then I agree (but this archiving is not triggered by the
> presence of the NR bit). But maybe you mean something else.
> 
> Denis


Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA22663 for <[e-mail]>; Wed, 1 Sep 1999 07:40:40 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA239420; Wed, 1 Sep 1999 10:42:25 -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.04) with SMTP id KAA79456; Wed, 1 Sep 1999 10:42:49 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567DF.0050CE78 ; Wed, 1 Sep 1999 10:42:37 -0400
X-Lotus-FromDomain: IBMUS
To: Denis Pinkas <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 1 Sep 1999 10:41:28 -0400
Subject: Re: New Internet Draft on Non-Repudiation Requirements
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I was referring to X.509 (June '97 edition) section 11.2 note 2, which says
"If a non-repudiation of data service is dependent on keys provided by the CA,
the service should ensure that all relevant keys of the CA (revoked or expired)
and the timestamped revocation lists are archived and certified by a current
authority."  This is one of the very few statements in X.509 or RFC 2459 which
makes clear demands on the CA in connection with the non repudiation service.
Perhaps my reading of this passage as applying only to those CRL's which record
the revocation of certificates with NR set but not to those which don't is
debatable, but it certainly applies to them at a minimum.

          Tom Gindin


Denis Pinkas <[e-mail]> on 09/01/99 04:22:04 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   [e-mail]
Subject:  Re: New Internet Draft on Non-Repudiation Requirements





Tom,

You said:

>      I think that we should remember that the NR bit is supposed to cause CRL
> archiving  as well.

I am not sure what you mean by this statement. If you mean archiving
by the CA that issued the CRL, then I disagree. If you mean
archiving of CRL by the verifier when it first verifies the
signature, then I agree (but this archiving is not triggered by the
presence of the NR bit). But maybe you mean something else.

Denis




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA21692 for <[e-mail]>; Wed, 1 Sep 1999 06:56:51 -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 PAA31669; Wed, 1 Sep 1999 15:58:27 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 01 Sep 1999 15:58:47 +0200
To: Charles Moore <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <1115E3FF8E9CD211A07C006008C2045001C457@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 GAA21694

I would agree with Charles here,

What are the reasons for limiting to one policy OID in end-entity certificates.

The case I see is when a community of relying parties accept 2 different
policies, which are possible to meet within the same certificate. The CA
want to issue a certificate and assure that both these policies are
fullfilled. The CA document how these two ploicies are implemented in a CPS.

This scenario is fully compatible with validation algorithms in X.509.

Why should this be forbidden.

Further I have troubble to see why policy qualifiers should be forbidden in
CA-certificates. In most cases I have seen, CA certificates carry the same
policy as end-entity certificates issued under that CA. I therefore fail to
see why the policy information should be expressed differently in
CA-certificates.

Please elaborate on what problems you try to fix with these changes.

/Stefan

At 07:25 PM 9/1/99 +1000, Charles Moore wrote:
>
>
>----- Original Message -----
>From: Russ Housley <[e-mail]>
>To: <[e-mail]>
>Sent: Wednesday, September 01, 1999 6:56 AM
>Subject: End-Entity Certificate Policies
>
>
>> Tim Polk and I got together today to discuss the changes needed to address
>> the policy mapping bug (as discussed at the Oslo meeting).  As part of
>this
>> discussion, we discussed the certificate policy extension.
>>
>> We believe that a CA certificate may contain one or more certificate
>policy
>> OID.  On the other hand, we believe that an end-entity certificate
>> containing a certificate policy extension must  contain a single
>> certificate policy OID.  RFC 2459 says:
>>
>>     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.
>
>cm>Believe we should stick to the above text and not limit to one OID...
>
>>
>> We would like to add words to make it more clear that an end-entity
>> certificate may only contain a single certificate policy OID.  The
>> explanation of this extension's purpose in a CA certificate was not
>spelled
>> out, so we propose to fix that too.  Our proposed text is:
>>
>>     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.  In an end-entity
>certificate,
>>     these policy information terms indicate the single policy under which
>>     the certificate has been issued and the purposes for which the
>certificate
>>     may be used.
>Cm> See above, should not limit...The rest is ok...
>For info what is the rational for limiting??
>
> In a CA certificate,  these policy information terms
>>     limit the set of policies for certification paths which include this
>>     certificate.  Optional qualifiers, which may be present, are not
>>     expected to change the definition of the policy.
>cm> Believe the intent is "expected to restrict the definition of the
>policy"
>rather than 'change'
>
>>
>> Does anyone disagree?
>>
>> Tim and I also discussed certificate policy qualifiers.  Tim and I agree
>> that certificate policy qualifiers should only appear in end-entity
>> certificates.  That is, we agree that certificate policy qualifier should
>> never appear in a CA certificate.  Does anyone (besides Mike Baum)
>disagree?
>
>cm> I see no reason to limit the aplication of policy qualifiers, a CP can
>cover a CA as well so why not allow qualification of the CP at any
>element....
>
>Would be interested in the rational as well...
>
>>
>> Russ
>>

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

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


Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.9.3/8.9.3) with SMTP id GAA21418 for <[e-mail]>; Wed, 1 Sep 1999 06:48:00 -0700 (PDT)
Received: 	id JAA24137; Wed, 1 Sep 1999 09:44:54 -0400
Received: by gateway id <NP65NG3A>; Wed, 1 Sep 1999 09:47:33 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Charles Moore'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Date: Wed, 1 Sep 1999 09:47:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

I don't support limiting to a single policy OID or limiting the use of 
qualifiers only to end-entity certs. Even if this was agreed as part of 
the PKIX profile for what CAs were to do, relying parties presumably would
need to be able to deal with certs that were created outside of PKIX and
these might very well have multiple policies in the end-entity certs and
qualifiers in the CA certs. So at best this proposal might impose limits
on CA behavior for PKIX CAs, but probably couldn't on PKIX relying parties 
unless we want to isolate the PKIX world from the rest of the world :-(

Sharon 


-----Original Message-----
From: Charles Moore [mailto:[e-mail]]
Sent: Wednesday, September 01, 1999 5:25 AM
To: '[e-mail]'
Cc: '[e-mail]'
Subject: RE: End-Entity Certificate Policies




----- Original Message -----
From: Russ Housley <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, September 01, 1999 6:56 AM
Subject: End-Entity Certificate Policies


> Tim Polk and I got together today to discuss the changes needed to address
> the policy mapping bug (as discussed at the Oslo meeting).  As part of
this
> discussion, we discussed the certificate policy extension.
>
> We believe that a CA certificate may contain one or more certificate
policy
> OID.  On the other hand, we believe that an end-entity certificate
> containing a certificate policy extension must  contain a single
> certificate policy OID.  RFC 2459 says:
>
>     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.

cm>Believe we should stick to the above text and not limit to one OID...

>
> We would like to add words to make it more clear that an end-entity
> certificate may only contain a single certificate policy OID.  The
> explanation of this extension's purpose in a CA certificate was not
spelled
> out, so we propose to fix that too.  Our proposed text is:
>
>     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.  In an end-entity
certificate,
>     these policy information terms indicate the single policy under which
>     the certificate has been issued and the purposes for which the
certificate
>     may be used.
Cm> See above, should not limit...The rest is ok...
For info what is the rational for limiting??

 In a CA certificate,  these policy information terms
>     limit the set of policies for certification paths which include this
>     certificate.  Optional qualifiers, which may be present, are not
>     expected to change the definition of the policy.
cm> Believe the intent is "expected to restrict the definition of the
policy"
rather than 'change'

>
> Does anyone disagree?
>
> Tim and I also discussed certificate policy qualifiers.  Tim and I agree
> that certificate policy qualifiers should only appear in end-entity
> certificates.  That is, we agree that certificate policy qualifier should
> never appear in a CA certificate.  Does anyone (besides Mike Baum)
disagree?

cm> I see no reason to limit the aplication of policy qualifiers, a CP can
cover a CA as well so why not allow qualification of the CP at any
element....

Would be interested in the rational as well...

>
> Russ
>


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA20919 for <[e-mail]>; Wed, 1 Sep 1999 06:17:19 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQheuf03847; Wed, 1 Sep 1999 13:19:23 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA01553; Wed, 1 Sep 99 09:17:48 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA16009; Wed, 1 Sep 1999 09:19:22 -0400
Date: Wed, 1 Sep 1999 09:19:22 -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], [e-mail], [e-mail]
Subject: RE: New Internet Draft on Non-Repudiation Requirements
References: <[e-mail]> <000701bef46c$bdab0660$0500000a@npwork2>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Nick" == Nick Pope <[e-mail]> writes:

 Nick> Denis, It is worth noting that in X.509 clause 11.2, note 2
 Nick> states:

 Nick> " If a non-repudiation of data service is dependent on keys
 Nick> provided by the CA, the service should ensure that all relevant
 Nick> keys of the CA (revoked or expired) and the timestamped
 Nick> revocation lists are archived and certified by a current
 Nick> authority."

 Nick> This has relevance to our current work together as well as this
 Nick> list.  I believe that the word "timestamp" refers to just a
 Nick> date a time value, not a trusted timestamp produced by a
 Nick> timestamping authory.

I would think it does need to be a trusted timestamp, because you need 
to be able to verify that information bearing on the validity of
signatures (such as CRLs) indeed did exist at the claimed time.

For example, suppose the CA key was compromised at some time and
revoked.  CRLs known to have been issued before then would be good,
but CRLs not provably issued by then are suspect even if internal data 
in them claims they were old.

	paul


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA20566 for <[e-mail]>; Wed, 1 Sep 1999 06:06:11 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA15247; Wed, 1 Sep 1999 09:08:29 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA15239; Wed, 1 Sep 1999 09:08: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 JAA16291; Wed, 1 Sep 1999 09:08:15 -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 JAA01875; Wed, 1 Sep 1999 09:06:35 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 1 Sep 1999 09:06:35 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: SCVP-01
To: [e-mail], [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Iw0k2lDYFbfKwanmwaBkCw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Peter Williams" <[e-mail]>
> 
> Policy WG, and reuse: I would like to see the SCVP
> specification take component form, enabling its
> object to be reused in the extension mechanisms of other
> suitable value-adding services, including CMP and DCS.


I would like to see that too.  It's in the spirit of the (now-defunct)
Certificate Management Message Format (CMMF):

 * define a set of messages, and define the sequence of messages exchanged
    to perform a particular action.
 * encapsulate/protect the messages using whatever transport/security
    mechanism (CMP, CMS, DCS, AH/ESP, ...) fits the bill.

Defining transport-independent message sets for specific purposes
reduces the difference between "a lot of single-purpose protocols" and
"one big do-everything protocol", enables reuse of existing transport
modules/APIs, and as a design paradigm should be a no-brainer.

Whatever happened to CMMF anyway?  Is this the time to revive it, before
CMP and CMC go to Draft?



Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.65.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA18945 for <[e-mail]>; Wed, 1 Sep 1999 04:20:13 -0700 (PDT)
Received: from npwork2 (e1h1p80.scotland.net [148.176.233.81]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id MAA16784; Wed, 1 Sep 1999 12:21:43 +0100 (BST)
From: "Nick Pope" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: New Internet Draft on Non-Repudiation Requirements
Date: Wed, 1 Sep 1999 12:25:48 +0100
Message-ID: <000701bef46c$bdab0660$0500000a@npwork2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Denis,

It is worth noting that in X.509 clause 11.2, note 2 states:

" If a non-repudiation of data service is dependent on keys provided by the
CA, the service should ensure that all relevant keys of the CA (revoked or
expired) and the timestamped revocation lists are archived and certified by
a current authority."

This has relevance to our current work together as well as this list.  I
believe that the word "timestamp"  refers to just a date a time value, not a
trusted timestamp produced by a timestamping authory.

Nick

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: 01 September 1999 09:22
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: New Internet Draft on Non-Repudiation Requirements
>
>
> Tom,
>
> You said:
>
> >      I think that we should remember that the NR bit is
> supposed to cause CRL
> > archiving  as well.
>
> I am not sure what you mean by this statement. If you mean archiving
> by the CA that issued the CRL, then I disagree. If you mean
> archiving of CRL by the verifier when it first verifies the
> signature, then I agree (but this archiving is not triggered by the
> presence of the NR bit). But maybe you mean something else.
>
> Denis
>



Received: from mail.phenix.com.au (fwuser@[203.37.128.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA10514 for <[e-mail]>; Wed, 1 Sep 1999 02:23:05 -0700 (PDT)
Message-ID: <1115E3FF8E9CD211A07C006008C2045001C457@MAIL>
From: Charles Moore <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Date: Wed, 1 Sep 1999 19:25:05 +1000 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

----- Original Message -----
From: Russ Housley <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, September 01, 1999 6:56 AM
Subject: End-Entity Certificate Policies


> Tim Polk and I got together today to discuss the changes needed to address
> the policy mapping bug (as discussed at the Oslo meeting).  As part of
this
> discussion, we discussed the certificate policy extension.
>
> We believe that a CA certificate may contain one or more certificate
policy
> OID.  On the other hand, we believe that an end-entity certificate
> containing a certificate policy extension must  contain a single
> certificate policy OID.  RFC 2459 says:
>
>     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.

cm>Believe we should stick to the above text and not limit to one OID...

>
> We would like to add words to make it more clear that an end-entity
> certificate may only contain a single certificate policy OID.  The
> explanation of this extension's purpose in a CA certificate was not
spelled
> out, so we propose to fix that too.  Our proposed text is:
>
>     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.  In an end-entity
certificate,
>     these policy information terms indicate the single policy under which
>     the certificate has been issued and the purposes for which the
certificate
>     may be used.
Cm> See above, should not limit...The rest is ok...
For info what is the rational for limiting??

 In a CA certificate,  these policy information terms
>     limit the set of policies for certification paths which include this
>     certificate.  Optional qualifiers, which may be present, are not
>     expected to change the definition of the policy.
cm> Believe the intent is "expected to restrict the definition of the
policy"
rather than 'change'

>
> Does anyone disagree?
>
> Tim and I also discussed certificate policy qualifiers.  Tim and I agree
> that certificate policy qualifiers should only appear in end-entity
> certificates.  That is, we agree that certificate policy qualifier should
> never appear in a CA certificate.  Does anyone (besides Mike Baum)
disagree?

cm> I see no reason to limit the aplication of policy qualifiers, a CP can
cover a CA as well so why not allow qualification of the CP at any
element....

Would be interested in the rational as well...

>
> Russ
>


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA08316 for <[e-mail]>; Wed, 1 Sep 1999 01:20:27 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id KAA28674; Wed, 1 Sep 1999 10:22:07 +0200
Message-ID: <[e-mail]>
Date: Wed, 01 Sep 1999 10:22:04 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: New Internet Draft on Non-Repudiation Requirements
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom,

You said:
 
>      I think that we should remember that the NR bit is supposed to cause CRL
> archiving  as well.

I am not sure what you mean by this statement. If you mean archiving
by the CA that issued the CRL, then I disagree. If you mean
archiving of CRL by the verifier when it first verifies the
signature, then I agree (but this archiving is not triggered by the
presence of the NR bit). But maybe you mean something else.

Denis