Re: [IETF-PKIX] Question about SubjectAltNames

[Andreas Berger <[e-mail]>]

Bob Jueneman wrote:
>
> >Phil,
> >
> >I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
> >require "Distinguished Names" to be "Directory Names"?

To my opinion, the X.509 certificates were intended to authenticate
users for access of the X.500 directory system. Certificates must
contain an acceptable name for the application in question. Therefore,
distinguished names for the X.500 are the appropriate namespace for this
application. For other applications there may well be other namespaces
acceptable.

> 1.  Does the DN in a certificate have to be globally unambiguous, so that no
> two people with the same common name could possibly be confused?
>
> Answering that question "yes" will force name subordination to be applied
> everywhere, even in cases where the obvious ways of doing it (geopolitical
> name qualification, down to the street address level) are either
> unacceptable (e.g., due to privacy concerns), or not workable (because the
> state or locality entities have not bought into the system, or because the
> natural domain of a CA (e.g., an ISP) is not confined by regional
> boundaries. This in turn tends to force the use of multiple RDNs as the leaf
> component, in order to avoid changing someone's common name while still
> maintaining global unambiguity.
>
> Answering the question "no" seems (at least on the surface) to significantly
> weaken the legal status of a digital signature for purposes of commerce,
> unless some other name mechanism (e.g., a unique account number) is included
> somewhere else, e.g, in an alternateSubjectName.  In the past, the legal
> system was somewhat cavalier about the assignment of names -- in fact it
> doesn't matter if you sign your checks as "Santa Claus" -- it is still your
> mark, whether unique or not.  But more recently, the issue of who owns
> domain names has become increasingly contentious. Whereas at one time Apple
> the computer company and Apple the music company had little to do with each
> other, today the separation is much less clean cut.  Even today, if there
> exists a David Kemp or a Robert Jueneman in Uganda somewhere, no significant
> legal confusion is likely to result. But who can say what will happen
> tomorrow? On the Internet, no one knows you live in Uganda (at least if you
> have an e-mail account with CompuServe. or some other domestic ISP).

We don't need a global unique name for users in a certificate in the way
you described it. We have to be very careful not to mix the attributes
of a person (Name, Address...) with the requirement of the technical
"name". That is a problem that X.500 created with typed RDNs.

For electronic commerce applications (or legally binding transactions)
we need a name that is acceptable to the other party. This acceptance
depends largely on the trustworthiness of the issuer of the certificate
and defined measures to get hold of the physical person in case a
dispute arises. Therefore, it should be enough to identify an end entity
relativly unique to the issuer. And this identification may well be made
by a number or some other means. People may have several identities in
this respect - and nobody will care unless the resolution of these
pseudonymity is required.

> 2. Does the use of X.509 envision at least the possibility of a globally
> interconnected directory to be used for certificate retrieval and perhaps
> CRL retrieval?  If so, doesn't require the assumption that the DN in the
> certificate is one to one with respect to the DIT?  If we don't start out
> deploying certificates with that assumption in mind, will it not prove to be
> impossible to migrate to such a scheme later on?

If an application accepts simple DNs (such as CN=High Speed Modem) it
has to have some knowledge on how to retrieve such names from a
directory (if a directory is employed at all). I would not want to make
very piece of equiment in a corporate network "worldwide unique". And
yes, this certificate would have no meaning outside the corporate
network, but is this really necessary?

For the (relativly simple) operations needed for retrieving security
attribute from directories (i.e. find a certificate for a person,
retrieve a CRL and so on) we could as well use URLs (LDAP, HTTP, FTP,
FINGER or something similar). We do not need a very complex "directory
service" for these operations.

But I agree that we should develop some guidelines for creating DNs. Or
at least write down what is already there (see the NT4 LDAP server,
verisign certificates, X.400 mailaddresses an so on). Perhaps we can
converge on an accepted practice. We should stress the point that these
DNs are automatically resolvable to machine/service names (on the
internet or other) so that applications (e.g. eMail clients or payment
systems) can access a direcory service to retrieve additional
information desired.

> 3.  And speaking of schemes, what schema is to be assumed for acceptable
> components of a DN in a certificate, if we are to ever move toward a common
> directory?  At present, I am not aware of any definition of what constitutes
> allowable, deprecated, or not allowable attribute types within a PKIX DN,
> yet if we ever expect that the current islands of LDAP usage will ever merge
> into archipelagoes, and finally continents, some agreement on acceptable
> schemas will have to be enforced.  Should we just leave it up to the public
> CAs like VeriSign to say what kinds of DN attributes they will support, and
> let all of the directory providers eat dirt?  Or vice versa?
I doubt that we will get a common directory for each and every entity on
the planet. Companies will severly restrict access to corporate
directories and even I personally would not want to publish a massive
amount of information globally.

> I believe that the working consensus is still the same that it was in the
> PEM days -- that we should strive to be interoperable with X.500
> directories, but should not presume their existence to be either necessary
> or sufficient.
Agreed. But what I would like to see is the seperation of the DN as a
name for an entry from identity information needed in certificates. The
DN for an entry is just a name (like an URL or bettern URN) that - in my
opionion - may be changed as often. What matters is the content of the
entry. If a CA wants to certify attributes of a person THAT ARE RELEVANT
to the application, it should put these into the certificate as well -
but not as part of the DN.

Andreas
--
 Andreas Berger, GMD - German National         eMail:
[e-mail]
 Research Center for Information Technology,
 Institute for Telecooperation Technology      Tel:   [phone]
 Dolivostrasse 15, D-64293 Darmstadt, GERMANY  Fax:   [phone]



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sat, 6 Dec 1997 17:58:15 -0700
Received: from firewater.vfi.com (firewater.vfi.com [207.90.128.27]) by Tandem.com (8.8.8/2.0.1) with SMTP id PAA04475 for <[e-mail]>; Sat, 6 Dec 1997 15:48:52 -0800 (PST)
Received: (qmail 24541 invoked from network); 6 Dec 1997 23:48:52 -0000
Received: from boomstick.vfi.com (207.90.129.3) by firewater.vfi.com with SMTP; 6 Dec 1997 23:48:52 -0000
Received: (qmail 24344 invoked from network); 6 Dec 1997 23:48:52 -0000
Received: from kroma.eit.com (207.90.129.2) by boomstick.vfi.com with SMTP; 6 Dec 1997 23:48:52 -0000
Received: from vfi.com (pm5.vfi.com [207.90.130.215]) by kroma.eit.com (8.8.5/8.8.5) with ESMTP id PAA08949 for <[e-mail]>; Sat, 6 Dec 1997 15:48:50 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 06 Dec 1997 15:52:15 -0800
From: Deepak Nadig <[e-mail]>
Reply-To: [e-mail]
Organization: Verifone/Internet Commerce Division
X-Mailer: Mozilla 4.03 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Comments on IPKI Part V: Time Stamp Protocols
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

The following are my comments on the specification.

1. [Page 2, Section 2.2]

    The semantics of a 'valid request' should be described. I can only
derive that a valid request is one that can be decoded properly. Is
there more ?

2. [Page 2, Section 2.4]

    It looks like the TMP is restricted to timestamp messages. Shouldn't
the TMP timestamp any data, and leave the contents of the data to be
defined by the application ? If the concern is the size of the data,
then TMP should recommend that the sizes be made small by sending the
Digest of the data (I would recommend the use of PKCS DetachedDigest
type here), instead of the data itself.

3. [Page 2, Section 4]

    I recommend that the request message should carry a Nonce that is
reflected in the response. This is to prevent replay attacks.

4. [Page 2, Section 4]

   I would recommend that the messages also carry a version field in
them. In general, this applies to other PKI protocol messages (like
OCSP, etc.) as well.

5. [Page 2, Section 4]

   Following (2), messageImprint should be an open type.

6. [Page 3, Section 4]

   Please consider using PKCS SignedData for defining the response
message. Is there a reason why it is not used ?

7. [Page 3, Section 7]

   Applications using TMP should also be concerned about the the amount
of time it is willing to wait for a response. A 'man in the middle' can
introduce delays in the request message, to determine the time that the
application sees in the response.

Thanks
Deepak




Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sat, 6 Dec 1997 10:42:21 -0700
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id IAA16240 for <[e-mail]>; Sat, 6 Dec 1997 08:47:12 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id IAA17685; Sat, 6 Dec 1997 08:46:40 -0800 (PST)
Received: from wford-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA29344; Sat, 6 Dec 1997 08:46:35 -0800 (PST)
Message-Id: <3.0.32.19971206115701.008619e0@mail>
X-Sender: wford@mail
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sat, 06 Dec 1997 11:57:07 -0800
To: [e-mail] (David P. Kemp)
From: Warwick Ford <[e-mail]>
Subject: RE: draft-ietf-smime-crs-00.txt
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Dave:

What you are asking for is exactly what many of us had been trying to
achieve for a long time.  We had the plan, well over a year ago, that PKIX
Part 3 should be a 2-layered protocol - a set of messages at the top layer,
and a security enveloping mechanism, which could be either PKCS#7 or an
alternative mechanism favored by Entrust, at the lower layer.

Unfortunately this was not achieved, and our extensive efforts to achieve
this at Munich proved fruitless.  The problem is that the current CMP
specification simply does not reflect layer independence.  The messages
described in Section 3, in particular several of the PKIHeader components,
are inherently tied to the Entrust protection mechanism.

At Munich, we asked the PKIX CMP editor if he could rearrange the
specification to make the separation of these two layers pure, but he found
this unacceptable.

I see no point in reopening this issue again now.  Why would the outcome be
any different?  I see no alternative to letting the CMP protocol be
published as is, meanwhile the PKCS#7-based protocol will be developed as a
fully-independent specification.  The PKCS protocol should, of course, try
to reuse components of the CMP message formats where possible; in fact, I
am still hopeful we can meaningfully consider CRS to be an "interpretation"
of CMP.  However, it would be unreasonable to encumber the PKCS design with
unwanted baggage.

Regards,
Warwick
 

At 12:37 PM 12/5/97 -0500, David P. Kemp wrote:
>
>Mike,
>   With respect, I've admitted to you and others privately that I find
>the *document describing* CMP which is now in Last Call to be overly
>complex.  But I fail to understand why you refuse to make your proposal
>compatible with the CMP protocol itself, which in it's minimal form,
>is not that complex.
>
>
>> There is a serious disconnect here which no amount of artful optional
>> syntax will repair and we might as well admit it.
>
>There is a disconnect in someone's understanding, perhaps mine.  But
>IMHO the "artful optional syntax" is not an attempt to repair anything,
>it is the fundamental design principle which enables one to start small
>and add on later.  Stripped of everything optional, CMP can be
>described in just a few lines:
>
>
>    PKIMessage ::= SEQUENCE {
>        header    PKIHeader,
>        body      PKIBody  }
>
>    PKIHeader ::= SEQUENCE {
>        pvno      INTEGER,
>        sender    GeneralName,
>        recipient GeneralName }
>
>    PKIBody ::= SEQUENCE {
>        p10cr     [4] CertificationRequest }  -- PKCS#10 certification
request*
>
>
>Are you claiming that adding one integer, two names, and a couple of
>nested SEQUENCEs to PKCS #10 is so much of a burden that S/MIME
>developers, toolkit vendors, and CAs will be unable to accomplish it
>within the next release cycle?
>
>As Blake said, if there is something wrong with this tiny bit of
>required CMP syntax, then suggest that it be fixed.  Otherwise, just
>get about the business of writing your draft describing a minimal cert
>request syntax in a manner that is compatible with CMP, instead of
>insisting on a non-extensible alternative with no future growth path.
>
>
>> The issues and forces are readily apparent.  If x% of the PKI-using
>> community does something other than CMP for their own internal reasons,
>> then at some value of x we must perform a reality check.  I would claim the
>> current value of x far exceeds this threshold.
>
>Reality check: 100% of browser vendors do not support TLS in their
>current products.  Yet I don't see that being used as an argument claiming
>that the IETF must write a Standards Track protocol that enshrines
>SSL v3.0 as a permanent parallel alternative to TLS 1.0.  One Standard
>is enough - implementations are always free to support as many additional
>non-standard or de-facto standard options as business needs dictate.
>
>
>-------------
>* as an aside, I'll express my opinion that using the CMP "cr" message
>  and eliminating the redundant "p10cr" message would also not be a
>  major burden for developers, and would have the benefit of simplifying
>  the codebase.  But in the spirit of compromise, I won't
>  argue for that here. 
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [e-mail]; Tel: [phone] x225; Fax: [phone]
---------------------------------------------------------------------
 



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sat, 6 Dec 1997 07:09:16 -0700
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id QAA21955 for <[e-mail]>; Fri, 5 Dec 1997 16:38:59 -0800 (PST)
From: [e-mail]
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id QAA01767; Fri, 5 Dec 1997 16:38:27 -0800 (PST)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id QAA02518; Fri, 5 Dec 1997 16:38:26 -0800 (PST)
Message-Id: <3.0.32.19971205163819.008fc980@mail>
X-Sender: mmyers@mail
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 05 Dec 1997 16:38:27 -0700
To: "IETF X.509-based public key infrastructure mailing list"              <[e-mail]>, [e-mail]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP
Mime-Version: 1.0
Content-Type: text/plain

Tim,

A very thoughtful analysis.  I believe however there are several critical
points the list's readership should consider before they come to any firm
conclusions regarding the suitability of proposed mechanism to the
requirements at hand:

1. CRLs are more complex than needed to satisfy OCSP requirements.  While I
don't wish to presume to speak for those who evolved the concepts, CRLs are
architected towards an operational concept that is orthogonal to the needs
of online status checking.  They were and are static objects intended to
aggregate information in a central repository.  An OCSP response is (or, to
be fair, must be capable of being) a dynamic object intended to distribute
a single piece of information throughout a large-scale network.

2. CRLs fail to address the extensibility and value-added requirements
asserted by Rich Ankey and Bob Juenemann.

3. In separate works, Silvio Micali and Santosh Chokani have amply
demonstrated the devastating effect that even modest CRL distribution
transmission schedules can have on the costs of operating a network.  This
effect is particularly acute when the proposed mechanism is applied to
dynamic production of responses--precisely the requirement an online status
mechanism must support with minimal impact.

4. A CRL only confirms revocation.  It does not assert that a given
certificate is valid if not present on the CRL.  Thus relying parties are
ill-equipped with the proposed alternative to acquire the answer they most
wish to receive.

5.  The analysis fails to recognize the diversity of uses of public key
technology, and consequently leads to false conclusions regarding cache hit
ratios at the periphery of a distributed network.  For example, the
population of parties relying on certificates that validate the
authenticity of signed code objects is orders of magnitude larger than the
population of signed code publishers.  A similar asymmetry exists with
respect to SSL server authentication.  Lastly, SMIME message originators
could include as an authenticated attribute an OCSP response validating
their certificate.

Now, to respond to your specific points:


At 09:17 AM 12/2/97 -0500, Tim Moses wrote:
>Colleagues - I have been reviewing the OCSP and the 'FTP and HTTP'
>drafts, and it occurs to me that OCSP can be considered to be a special
>case of the latter scheme.  This would not be the case if OCSP could
>offer a 'live' response in a large-scale system, but clearly this is not
>practical.

Quite the opposite, I would claim.  OCSP is specifically intended to enable
live responses for large-scale environments with a need.  I would define
large-scale to be at least as large as the number of parties currently or
potentially relying on signed code objects.

Liveness at this scale is strongly driven by cryptographic throughput.
There exist on the market today a number of high-speed cryptographic
devices with sufficient per-signature performance and throughput capacity
to enable such a service.

Liveness is also governed by bandwidth requirements.  However, predictions
on required bandwidth are subject to a range of operational models.  I will
identify some of these in a moment.  When integrated across the complete
set of PKI usage environments, the practicality of OCSP should become
readily apparent.


>I assume that OCSP is designed to provide notification of revocation
>over the Internet in the absence of a replicated directory.  Clearly,
>there is a need to solve this problem. But the use of CRLs over HTTP
>offers a more general solution to the same problem.

But with generality comes complexity and redundancy.  Here I would assert
another fundamental requirement: bounded simplicity.  With CRL extensions
and CRL entry extensions, CRLs are far from simple constructs.  For
example, does this proposal apply as well to the Indirect CRL case as well?
 Knowing the intended purpose of that construct (having been a contributor
to its formation), I would expect it could.  Thus, in order to deliver on
the same set of capabilities OCSP provides, the proposed alternative
requires a considerable investment in CRL implementation to achieve the
same effects that OCSP's much simpler syntax and operational concept provides.

>In addition, it is
>a more robust solution, offers greater flexibility in engineering
>implementations, exhibits lower cost and makes better re-use of existing
>software.

One must consider the totality of the definition of "cost".  As a (former)
software developer, flexibility is a good thing.  But if I were a product
manager and all I wanted was my Java-based applet to determine if *this*
certificate is good *now*, why would I want to pay to develop needless
flexibility?  Because I might need it someday?  I've been in these
discussions before; the outcome is quite predictable.  From this
perspective, the proposed alternative increases costs and product
development cycle time to the point where revocation checking *might* show
up in version N+1 of that Java applet.  Thus the proposed alternative
inhibits the growth of PKI when compared to the original OCSP solution.

>HTTP-caching must be used with either protocol, in order to
>achieve adequate scalability.  In which case, the CA can control the
>cache retention interval in intermediate HTTP servers, in order to
>ensure that they will be refreshed when new revocation status
>information is scheduled to become available.

This is exactly the case I've been making, where caching is operationally
relevant.  I fail to see though how it benefits the CRL over OCSP argument.

>An illustrative example to support these conclusions is provided at the
>end.
>
>Summary
>
>OCSP places a heavy load on the most highly shared components of the
>system, making it unnecessarily expensive to offer a scaleable and
>compliant service.

In other words, OCSP performance tuning can be centrally managed and
scaled.  I would expect many IT managers to welcome this aspect of OCSP
over the burden CRLs transmission places across a network.  In the first
case, one buys a more powerful server.  In the latter case, one is faced
with an organizational-wide upgrade of networking capability to accomodate
the proposed alternative.

As Silvio Micali's and Santosh Chokani's studies have shown, CRL
transmission injects large amounts of unrequested information into and
throughout a network.  This burden can quickly overwhelm any other costs
associated with operating a PKI.  It was these and other well-considered
analyses that led to the notion of an online status mechanism in the first
place.


>This is because dividing revocation information into
>its smallest parts makes the probability of a cache hit in the periphery
>of the network insignificant.  This may be appropriate if, for some
>reason, one wants to ensure that each individual revocation status
>request is serviced directly by the CA, but a more general solution is
>required for situations where this is not a consideration.

I read in the above the requirement for trust distribution.  This has
nothing to do with CRLs and everything to do with liability apportionment.
I don't know how many reading the list have had the pleasure of actually
working out the business details of such agreements, but experience has
shown the diligence required can far outweigh the costs associated with
technical implementation.  If I may brutally condense the DSG, it's not the
signature that's important, it's the trust that lies behind the signature.  

Thus, the policy generality implied by the trust distribution requirement
is in no way met by the technical generality of the proposed alternative.


>Moreover, the general solution can, if necessary, be engineered to provide a
>service equivalent to that offered by OCSP where this is appropriate.

There is no requirement for a general solution that can be reduced to the
intended functionality.  There does however exist a diversity of needs.
Some of these can be satisfied by CRL retrieval mechanisms.  Where CRLs are
either unworkable, untimely or unavailable, a quick direct connection is
needed.


>
>Conclusions
>
>OCSP and the 'single monolithic CRL for the entire subscriber-base'
>approaches represent two extremes of the general solution represented by
>CRL distribution points accessed over the HTTP infrastructure.  OCSP can
>be considered equivalent to assignment of a single subscriber to each
>distribution point, and the single monolithic CRL can be considered
>equivalent to the assignment of the entire subscriber-base to a single
>distribution point.
>
>The special case of OCSP leads to a solution which minimizes the
>consumption of network resource in the dedicated data-link between the
>relying party and its ISP.  But, this is not a scarce resource (largely
>because it is not shared).

It is however the only one relying parties are concerned about.

>The penalty paid for this is that there is
>increased demand placed on the most highly shared components (the
>data-link between the Internet and the CA and the CA's signature
>facility).  This leads to excessive hardware and communication costs.

The cost model needs refinement.  Clearly one can construct an example case
to fit any cost model.  I have some further observations to this point
later on.


>Using CRLs over HTTP represents the general solution of which the other
>two can be considered special cases.

Again, there is no requirement for a general case that reduces to the
required functionality.  This strikes me as an argument one hears in the
SPKI camp (with all due respect to those working on some very difficult
issues over there.)

>Therefore, each implementation of
>the general case can be engineered, as appropriate, to satisfy the
>requirements of the specific application.  Those for whom the
>characteristics of OCSP are attractive may tailor the general solution
>to recreate OCSP-like characteristics.

But for all its claimed generality, the proposed alternative is still
absent the value-added features that commentators such as Rich Ankey and
Bob Juenemann have requested.

As I indicated in an earlier note, syntactic restructuring of the baseline
OCSP syntax could easily accomodate these needs while maintaining baseline
functionality.  How does a CRL convey a reliance limit?  How does a CRL
bind a message hash to an attestation of certificate validity?  How does
one incrementally add other context information?

The fact is CRLs serve one well-defined set of needs.  OCSP serves a
complementary set.  Force-fitting requirements onto a solution ill-suited
to satisfy those requirements leads to dissatisfied customers, redesign and
redeployment.  As I see it, the proposed alternative to online status will
lead to such scenarios.


>Others can make different choices, without having to modify the
>operation of the relying party software.

Assuming that relying party software is capable of managing hundreds of
partitioned CRLs.  How does a web browser select from among these partioned
CRLs, assuming local caching is being leveraged?  The proposed alternative
presumes a pre-placed technical development infrastructure.

>So, I propose that we examine the Internet Draft protocol for
>distributing CRLs over HTTP and ensure that it adequately accommodates
>the concerns that led to the proposal for the OCSP protocol.

The basis for OCSP's existence was a fairly broad and long-held consensus
that CRLs fail to meet timeliness and bandwith needs.  A mechanism based on
CRLs to now meet this need is self-contradictory.

>Analysis
>
>The effect of caching at the periphery of the Internet becomes apparent
>by considering this illustrative example.
>
>The architecture consists of ten components connected linearly in order
>from 1 to 10.
>
>Component 1: The relying party.
>Component 2: The relying party's HTTP cache.
>Component 3: The relying party's data-link to its ISP.
>Component 4: The ISP (let's assume that each ISP serves 1,000 relying
>parties).
>Component 5: The ISP's HTTP cache.
>Component 6: The ISP's data-link to the Internet backbone.
>Component 7: The Internet (let's assume that all the relying parties are
>represented by 1,000 ISPs).
>Component 8: The data-link connecting the Internet backbone to the CA.
>Component 9: The CA's HTTP cache.
>Component 10: The CA's signature facility.
>
>In this architecture, the CA serves 1 million subscribers and 1 million
>relying parties, via 1,000 ISPs.

As I will note below, this is but one example of these types of
relationships.  There are a number of different cases that need to be
considered when trying to do scalability assessments.  One can prove or
disprove the case for CRLs depending on what assumptions you make and what
your domain looks like.

>
>Other assumptions we need are these.
>
>Assumption 1.  Each use of the OCSP protocol consumes 6 kilobits of
>network resource.  This number includes the signature on the OCSP
>response (assumed to be 1024b or 170 base64 characters), but it also
>includes bits associated with establishing and destroying a TCP
>connection and sending the HTTP message.
>
>Assumption 2.  In the case of CRLs over HTTP, let's assume that the 1
>million subscribers are assigned to 500 distribution points, and that
>10% of subscribers are revoked at all times.  This situation might
>obtain in a corporate setting, where certificates are issued with a one
>year validity, they are revoked when the holder leaves the corporation
>and the corporation suffers a 10% staff turnover.  I believe these are
>very conservative assumptions.  Under these assumptions, the network
>resource consumed by retrieving a distribution point entry may be 50kb,
>including the bits associated with the connection and message.  While
>this number is almost ten times that for OCSP, it is much more
>efficient, because it conveys information about 2,000 certificates.

Conversely, it places onto the wire ten times more information than the
relying party requested.  What is the likelihood one would find the next
certificate on this partion again?  The model as presented strongly
suggests it would be on the order of a 2% likelihood (2000/100000).  In the
instance when "most-current" updates are needed--exactly the timeliness
requirement OCSP was intended to satisfy--and the CA operates a more or
less fixed policy of CRL partition size, there is no cache effect to be
obtained.  Thus almost every validation is going to result in the
transmission of nearly 50kb of useless information.

It is true that one could increase the granularity of the CRL partition to
mitigate this effect, but now implemetors and designers of a online service
would be faced with the complexity associated with CRL size partition
management.  Does this require a policy management module/subarchitecture?
It would seem so if the proposed alternative were to be reduced to practice
as proposed.  It is much more likely the partition size would be fixed.
Consider as well that if some compromise were struck in the design
process--say, five different partition sizes for five different levels of
service--then one is face with producting five different CRLs to answer
essentially the same question.

It is easily predictable that when operated in the manner which OCSP is
intended to operate, applications which dared to implement the proposed
alternative would quickly flood their communications channels with
unrequested information.  This is exactly the scenario Silvio and Santosh
warned us against.


>
>Assumption 3.  Each relying party validates 0.01 certificates per second
>during the "busy-hour" (this pattern of behavior  is consistent with use
>for signed and encrypted email, in which all relying parties work
>through their "overnight" email first thing in the morning).
>
>Assumption 4.  The relying parties are spread geographically over three
>time zones.
>
>Assumption 5.  In order to keep delays caused by contention for shared
>resources to an acceptable level, shared components will be engineered
>with a capacity three times the calculated busy-hour average demand.
>
>In the case of the OCSP protocol ·
>
>OCSP component 2 (relying party HTTP cache).  The probability of a hit
>on the relying party's cache is zero.
>
>OCSP component 3 (relying party data-link).  The average resource
>consumption in the data-link between the relying party and the ISP is
>6kb * 0.01 per sec = 60b/s.
>
>OCSP component 5 (ISP HTTP cache).  The probability of a hit on the
>ISP's cache is essentially zero (the ISP receives 36,000 requests during
>the busy-hour.  If you pick at random, from 1 million items, 36,000
>times (replacing them after each pick), then the probability of picking
>the same item twice is negligible).

The analysis is fundamentally flawed in that it over-simplifies the
population assumptions.  There are many operational environments and
communications habit factors that could substantially increase the
likelihood of a cache hit.

The probability of a hit will increase as relying party's queries are
retained in the cache.  The first few RPs will not hit, but later ones
will.  The analysis is also over-simplified in failing to consider the
traffic patterns.  In many organizations, there exist well-established
channels of external communications:  between trading partners, well-known
customers, geographically dispersed organizations and so forth.  It is
further well known that a large percentage of one's daily email is with
other members of the organization.

The analysis also fails to acknowledge well-known population relationships
in the PKI marketplace today.  In the code signing or SSL server
authentication case, the size of the domain of relying parties is very
large compared to the size of the domain of subscribers.  This population
asymmetry would in many cases raise the probability of a cache hit to near
unity in queries on a signed code publisher or secure server certificate.

Consider also equivalent architectures:  Authenticating Firewalls, Secure
Mail Gateways, Secure Mail Lists, an IPSEC router.  The entire
client-server paradigm is completely ignored in this example.

In the case of SMIME the population size of subscriber and relying parties
are indeed more nearly matched as the assumption asserts.  However, given
an OCSP status service, message orginators could acquire and attach their
current OCSP status to the SMIME message.  This could be done quite easily
as an Authenticated Attribute.  This can become a very convenient mechanism
for non-repudiation needs.  At baseline assumption of 50kb per CRL
partition, the proposed alternative call into question the practicality of
this potentially indispensible practice.

>OCSP component 6 (ISP data-link).  Each ISP passes 36,000 requests per
>hour to the Internet backbone.  So, the resource consumed in the
>data-link between the ISP and the Internet backbone is 1,000 * 60b/s =
>60kb/s.  Applying Assumption 5, a 256kb/s data link is required.

Assuming no cache hits in the peripery of the network.  As previously shown
however, this assumption is fundamentally flawed.

>
>OCSP component 8 (CA data-link).  If the ISPs each serve one time zone,
>then 333 of them will be generating busy-hour traffic levels at the same
>time.  Therefore, resource consumption in the data-link between the
>Internet and the CA will be 333 * 60kb/s = 20Mb/s.  So again, by
>Assumption 5, a 60Mb/s ATM link is required.

Again, the resulting bandwidth estimate is arrived at via an oversimplified
assumption regarding population structures and well-known usage patterns.

>
>OCSP component 9 (CA HTTP cache).  The CA's cache outputs is 36,000 *
>333 = 12 million requests per hour.  So, a database capable of serving
>3,333 read operations per second is required.

Same issue regarding population structures.

>
>OCSP component 10 (CA signature facility).  If the CA takes 3 hours to
>replenish its cache with a new entry for each of its 1 million
>subscribers, then the CA's signature facility must support a rate of 90
>signatures per second, and responses may be up to three hours out of
>date.

Which is easily within reach of today's hardware cryptographic
accelerators.  Given the current state of the art, signature production
throughput is a well-contained problem.  There no shortage of hardware
crypto vendors eager to prove their product line is up to this task.

>
>In the case of the CRLs over HTTP protocol. ·
>
>CRLs over HTTP component 2 (relying party HTTP cache).  The probability
>of a hit on the relying party's cache is zero.
>
>CRLs over HTTP component 3 (relying party data-link).  The average
>resource consumption in the data-link between the relying party and the
>ISP is 50kb * 0.01 per sec = 500b/s.
>
>CRLs over HTTP component 5 (ISP HTTP Cache).  The ISP's HTTP cache
>receives 36,000 requests per hour for one of 500 distribution points.
>Therefore, the probability of a cache hit is 0.986.  Although each
>request consumes about ten times as much network resource, only slightly
>more than one in every hundred requests are transferred to the Internet.
> So the amount of Internet traffic generated is approximately one tenth.

But, as noted earlier, in the case of a need for dynamic refresh--exactly
the requirement OCSP is intended to satisfy--the overall network burden is
dramatically impacted.  Further, this effect is transferred directly onto
the local organization subnet, flooding it with unrequested and very likely
useless information.

>
>CRLs over HTTP component 6 (ISP data-link). The average data rate
>transferred by the ISP cache to the Internet is the number of relying
>parties times the average data rate per relying party times one minus
>the efficiency of the case.  I.e. 1,000 * 500 * (1 - 0.986) b/s.= 7
>kb/s.  Therefore, by Assumption 5, a 32kb/s link would be adequate
>between the ISP and the Internet backbone.
>
>CRLs over HTTP component 8 (CA data-link).  If the ISPs each serve one
>time zone, then 333 of them will be generating busy-hour traffic levels
>at the same time.  Therefore, resource consumption in the data-link
>between the Internet and the CA will be 333 * 7 kb/s = 2.3 Mb/s.  So, by
>Assumption 5, a 7Mb/s data link is required between the Internet and the
>CA.
>
>CRLs over HTTP component 9 (CA HTTP cache).  The CA's cache receives 333
>* 500 requests per hour.   So, a database capable of servicing 50 read
>operations per second is required.
>
>CRLs over HTTP component 10 (CA signature facility).  If the CA were
>capable of performing 90 signature operations per second, then
>theoretically, it could update all of its 500 entries once every six
>seconds.  If, however, it were to update them every three hours, then
>its signature capacity must be 0.04 signatures per second.

If CRLs were updated with this frequency, then bandwidth needs of component
6 and component 8 can easily exceed those of the OCSP case for some
reasonable assumptions on CRL partition granularity.

>
>
>--------------------------------------------------------------
>Tim Moses, Entrust Technologies,
>Tel: [phone],
>email: [e-mail].
>
>




Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 21:22:25 -0700
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id TAA08616 for <[e-mail]>; Fri, 5 Dec 1997 19:11:40 -0800 (PST)
From: [e-mail]
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id TAA05495; Fri, 5 Dec 1997 19:11:07 -0800 (PST)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id TAA09080; Fri, 5 Dec 1997 19:11:06 -0800 (PST)
Message-Id: <3.0.32.19971205191107.007aede0@mail>
X-Sender: mmyers@mail
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 05 Dec 1997 19:11:08 -0700
To: Marc Branchaud <[e-mail]>, [e-mail]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Marc,

At 10:37 AM 12/5/97 -0800, Marc Branchaud wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>I agree with Phill's comments below, and would like to add what I think is
>a slightly different perspective.
>
>OCSP is an attempt to address some of the flaws of the CRL model.  For the
>most part, the flaw with the most attention has been the untimeliness of
>CRL revocation information.  But there's another CRL flaw that deserves
>equal attention, and which isn't being properly addressed with the current
>OCSP discussion.
>
>The flaw is that the decision of when to release new revocation
>information rests with the CA.  In other words, a relying party who needs
>up-to-date revocation information in a CRL-only environment has to wait
>for the next CRL to be published.  The relier has no power to influence
>the CA into releasing revocation information earlier.
>
>OCSP allows the relier to get the revocation information when it's needed,
>without being subject to the CA's CRL schedule.  Because CRLs can only be
>released periodically, they are at best a compromise solution to the needs
>of relying parties.

Keep in mind there's still a periodicity effect in the event of caching.
Section 2.3 of the current draft sets out the requirements.

>
>Of course, OCSP can't be used in all situations.  A caching mechanism is
>needed to relieve bandwidth pressures.  But CRLs are poor candidates for
>a caching mechanism, because they still dictate to relying parties when
>their caches can be refreshed.
>
>It is crucial that relying parties get the revocation information they
>need when they need it.  To accomplish that, CRLs need to be avoided
>entirely.  Instead, relying parties should cache OCSP responses, and
>decide for themselves when to refresh their caches.
>
>Luckily, it's easy to charge for an OCSP query.  So we have the makings of
>a self-regulating system.  Parties who need real-time revocation
>information can pay for it.  On the other hand, once I find the validity
>of my buddy's email signature certificate it's unlikely that I'll feel a
>desperate need to refresh that validity information every time I read one
>of his messages.  Especially if I have to pay $x every time I do so.
>
>The point is that in order to allow CAs to serve the widest community of
>users, they need to be flexible enough to properly serve those users'
>needs.  CRLs simply do not provide the required flexibility.

I think it's fair to say we are in violent agreement here.

>The OCSP proposal, as it stands, is also inadequate. Along with the OCSP
>specification, we need a description of the caching mechanism, which can
>be simple, but is definiately required.  We also need to define user
>interface behavior, because real people are ultimately the relying
>parties in most of the situations we want to support.  By this I mean that
>we need to explain that the users must be shown the ages of the satuses
>(stati?) of the certificates they're about to rely on, and they must be
>given the opportunity to refresh that status if they desire.

Again, I completely agree.  However, we must be cautious about overly
constraining implementors.  We can and should standardize what's
standarizable.

>
>OCSP only becomes viable with proper caching and user interaction. 
>Otherwise, it's a tool without an instruction manual.
>
>		Marc
>
>+------------------------------------------------------------------------+
> Marc Branchaud                                       \/
> Chief PKI Architect                                  /\CERT SOFTWARE INC.
> [e-mail]        PKI References page:              www.xcert.com
> 604-640-6227          www.xcert.com/~marcnarc/PKI/
>+------------------------------------------------------------------------+
>  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
>
>
>
>On Fri, 5 Dec 1997, Phillip M Hallam-Baker wrote:
>> 
>> Re Tim Moses <[e-mail]> comments concerning the alledged 'non
>> scalability of OCSP'.
>> 
>> I have been reviewing Tim's comments concerning the 'scalability of OCSP'.
>> First I note that Tim does not address scalability but the relative
>> performance of OCSP and the Entrust approach under his chosen set of
>> assumptions.
>> 
>> Scalability is about  whether an architecture limits the size of the
problem
>> that can be handled. e.g. resource requirements scale O(n^2)or worse or it
>> assumes a big enough mainframe can be purchased.
>> 
>> OCSP supports a function call end clients make routinely: 'Is this
>> certificate valid'. It allows the function 'check every certificate in my
>> address book' to be supported cleanly. Unless you want to either handle
CRLs
>> in the client or route all traffic through a central bottleneck OCSP is the
>> obvious approach.
>> 
>> To gain perspective on scaling issues I believe we should look at a billion
>> certificates or more rather than Tim's million. At least two applications
>> will involve this number of certificates:
>> 
>>     * Credit card processing
>>     * Certificate based equities
>> 
>> Both these scenarios are much smaller than systems I have previously helped
>> design, ZEUS and the Web. Simulation is the only way to prove viability of
>> such systems. I see OCSP as a usefull tool in meeting such challenges which
>> require a 'full toolbox'.
>> 
>>         Phill
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNIhJ4lrdFXNdDxPlAQEsFwL9GyGA7p9xeIBBiMYfkeVvqCfEGFHD71Ga
>FdIDELmR42ksY7bjVlpuh0O7BuqvXBeV+Atx8EIV8TlrHFaWuZzxPSbyp93RoCr3
>0FHsGlcoyRQsjaUZAMMi1g5LwWOkdrWX
>=Sp+F
>-----END PGP SIGNATURE-----
>
>
>




Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 21:03:50 -0700
Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id SAA07683 for <[e-mail]>; Fri, 5 Dec 1997 18:59:59 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id PAA29400; Sat, 6 Dec 1997 15:59:55 +1300 (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <88137719422746>; Sat, 6 Dec 1997 15:59:54 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Encoding of INTEGER fields in PKIX certs
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 6 Dec 1997 15:59:54 (NZDT)
Message-ID: <[e-mail]>

David P. Kemp <[e-mail]> writes:
 
>ASN.1 INTEGERS are encoded as two's-complement numbers, which implies that if 
>a BER-encoded value is decoded into a larger native storage value, the high 
>bit of the encoded value will be sign-extended into the excess bits of the 
>native value. For cryptographic purposes, it is my understanding that bignums 
>are always the same size as the encoded values, so the issue of sign 
>extension never arises.  (Additionally, for cryptographic algorithms using 
>modular arithmetic with a 2^n modulus, any sign-extended bits larger than the 
>modulus are ignored - chopped off in the modular reduction.)
>
>[...]
>Since a distinguished encoding of these values is required, there MUST be an 
>encoding convention for whether to do sign padding when MSB=1. Most of the 
>cert examples I have seen do not do sign padding.
 
The only certs I've seen that very consistently do this are the ones produced 
by Microsoft software, who encode all (well, strictly speaking about 50% on 
average) of their INTEGERs incorrectly.  Everyone else seems to get it right 
(this is from a random sample of 50-odd CA certs pulled from browsers and 
things).  My ASN.1 dump program 
http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c, will flag negative integers 
as encoding errors and can be used to check for this problem.
 
>* Does a convention for sign padding of INTEGERs already exist anywhere?
 
Yes.  X.680 says:
 
  8.3.2 If the contents octets of an integer value encoding consists of more 
        than one octet then [the first 9 bits]
        
        a) shall not be all ones; and
        b) shall not be zero.
 
  8.3.3 The contents octets shall be a two's complement binary number equal to 
        the integer value and consisting of [lots of stuff on how the bits are 
        ordered].
 
Therefore if the high bit in the value to be encoded is set, the first octet 
is zero; if the high bit is not set, the first octet is nonzero (in other 
words INTEGERs have to be zero-padded).
 
>If not, Part 1 should be amended to specify that compliant CAs SHALL NOT 
>generate padding 00 bytes for INTEGERs, and that verifiers SHOULD accept both 
>padded and unpadded INTEGERs.  And I will correct the examples accordingly.
 
Doing this would be in violation of the BER and DER, which is unhealthy (you 
could try asking about messing with the encoding rules on the OSS ASN.1 list, 
but I'm pretty sure I know what they'd say).  It should be the other way 
around, always pad 00 for integers.
 
(As an aside, it's a bit of a pain to work with these padding bytes because 
your encoded integers have a 50% chance of growing by 1 byte after your 
signature is generated.  However the standard says you have to do this, and it 
makes sense even if it's a bit of a nuisance).
 
Peter.




Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 19:55:31 -0700
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id RAA01349 for <[e-mail]>; Fri, 5 Dec 1997 17:49:27 -0800 (PST)
From: [e-mail]
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id RAA03576; Fri, 5 Dec 1997 17:48:55 -0800 (PST)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id RAA05938; Fri, 5 Dec 1997 17:48:54 -0800 (PST)
Message-Id: <3.0.32.19971205174854.008edc10@mail>
X-Sender: mmyers@mail
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 05 Dec 1997 17:48:55 -0700
To: Bob Jueneman <[e-mail]>, [e-mail], [e-mail]
Subject: Re: OCSP Considerations
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Bob,

At 11:09 AM 12/5/97 -0700, Bob Jueneman wrote:
>Mike, sorry if I too negative. Sometimes it is difficult to know if someone
>agrees with you but hasn't had time to say so, vs. is still thinking, vs.
>disagreeing and/or ignoring you.  I appreciate the fact that we all have
>other jobs to do as well.

No problem.  The intent of the note was simply to stimulate constructive
comments towards consensus.


>
>With regard to your strawman proposal, my comments would be the following:
>
>1.  I see no particularly good reason to avoid the use of ASN.1. Despite
>some of its complexity, it provides a uniform way of documenting the
>specifications that can be validated by use of a compiler (minimizing the
>possibility of a misunderstanding). Anyone who is implementing any kind of a
>PKI implementation is going to be up to their ears in ASN.1 -- a little more
>won't hurt. But I wouldn't go to war on this issue.

In this instance, and especially this transport model, there exist
compelling reasons to not do ASN.1 simply because that's what PKIX does.
If all an application needs for ASN.1 is certificate decoding, this is or
soon will become an API-level issue.  The same applies to a perhaps lesser
scale for those who wish to use PKCS7 in creative ways.

For a general specification mechanism, it's great.  But in this instance we
can do our job without it, to the benefit, for example, of the small
Java-based developers who are using an API for certificate deconstruction.

>2. Regardless of the ASN.1 decision, providing a means of easily extending
>the protocol is absolutely vital. In particular, it is highly likely that
>billing information will have to be conveyed in both directtions, and
>ultimately a transaction value field as well.

I agree, and as I said earlier, began going down this path on the basis of
Certco's request in Munich. Going into the redraft though, the then-current
request syntax did not easily accomodate extensibility.  I was also wary of
over-engineering the solution in isolation. What I felt myself lacking
however were the voices of those who had similar expectations of usage.  I
concluded that it would be best to hear from others first before presuming
OCSP extensibility was meeting the needs of the WG as a whole.

After sitting back and taking another look at the draft, and especially the
recent spate of comments, it was clear that a couple of simple corrections
would accomodate mutually opposed needs.  That is, extensions that
incorporate transactions identifiers do an equally effective job at
breaking caching behavior.  However, the OCSP draft needs also be
accomodate enterprise-level operations where trust and policy is implicit
and all they really want back is a 1 or a 0.

So, I believe we're in agreement here.

>
>3. Both the request and the response need to be signed, at least optionally,
>and particularly if there is billing or other information associated.

I agree, particularly with the optional part.

Now, there is a converse side to this capability--unsigned responses.  Some
may wish to take advantage of this design effect for enterprise-level
needs.  Within an enterprise, trust is often implicit and security policy
enforced procedurally.

>
>4. I haven't studied the timestamping proposal, so I have no comment on the
>use of an OID in this area.  It is sufficient, I believe, that the CA or
>repository which is acting as an agent of the CA include the time, since in
>most cases I believe that time per se will not be of critical importance.

May I draw your attention to recent work by Todd Glassey and David Mills
regarding the instrumentation of trusted time?  Todd recently posted notice
to the PKIX of this work.  Their work is at
ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-00.txt

>
>5.  I don't see any particular utility in making the nonce field optional in
>the request -- if someone is really convinced that they don't need it, they
>can just fill in zeroes, without adding the addtiional complexity of
>deciding whether or not it was included, and therefore whether it should be
>included in the response.

But doing so then creates complexity and potential breakage at the backend.

I presume this practice is intended to enable pre-production and caching.
However, this then requires CAs or other trust providers to reliably
predict the default value in the event they wish to pre-produce signed
responses.  We could easily agree on an industry-standard default value but
this alternative also invites the possibility that a given developer will
get it wrong, deploy their product, and break.  This kind of thing happens
more frequently than perhaps we all care to admit.

Also, there would need to be at least some minor amount of code written on
the client to examine the default setting and branch appropriately.  So I'd
prefer to have this branch to a default of "no inclusion" vs. "default
value" because it seems to me the client-end complexity is roughly
equivalent while also providing some benefit at the  backend.

>
>7.  It would be nice, but perhaps not essential, to have something in the
>request that specifically identifies the nonce as consisting of a message
>digest (SHA-1 by default) of the date/time of the request concatenated with
>the digital signature which is being validated by this OCSP request.

I can see where this might be useful for certain applications.  But I would
not want to assert any requirement that the trust provider confirm this
construction.  From the trust provider's point of view, the underlying
structure of the nonce, when included, should be opaque.  Now, this does
lead us predictably into who is attesting to what in this interaction.  If
the CA behaves "opaquely", then it is just a status service and subjecting
itself to one set of potential damages.  If the CA confirms the
construction, did it just unwittingly become a digital notary?


Mike




Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 17:55:28 -0700
Received: from gateway-int.StructuredArts.COM (gateway-ext.structuredarts.com [206.127.192.30]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA14697 for <[e-mail]>; Fri, 5 Dec 1997 15:45:41 -0800 (PST)
Received: from StructuredArts.com (6.structuredarts.com [206.127.206.6]) by gateway-int.StructuredArts.COM (8.8.5/8.8.5) with ESMTP id QAA15940; Fri, 5 Dec 1997 16:45:56 -0800
Message-ID: <[e-mail]>
Date: Fri, 05 Dec 1997 15:46:12 -0800
From: "Anil R. Gangolli" <[e-mail]>
Reply-To: [e-mail]
Organization: Structured Arts Computing Corp.
X-Mailer: Mozilla 4.03 [en] (Win95; U)
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Encoding of INTEGER fields in PKIX certs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It's not really sign extension that is the issue here.  It is the
representation of the sign itself. INTEGER represents a two's
complement signed integer.

The most significant bit represents the
sign bit in the encoded integer.  If what you intend to
encode is a positive value and the most significant bit
would otherwise be a 1, then you must add a  zero octet 
to preserve the intended sign.

--a.


David P. Kemp wrote:
> 
> ASN.1 Folks,
> 
> I have the following certificate, which is intended for use
> in the PKIX Certificate and CRL Profile examples draft.
> 
> There are several fields representing cryptographic bignums which
> are encoded as INTEGERs: the DSA parameters p, q, and g; the
> DSA public key y, and the DSA signature values r and s.
> 
> ASN.1 INTEGERS are encoded as two's-complement numbers, which
> implies that if a BER-encoded value is decoded into a larger
> native storage value, the high bit of the encoded value will be
> sign-extended into the excess bits of the native value.
> For cryptographic purposes, it is my understanding that bignums
> are always the same size as the encoded values, so the issue
> of sign extension never arises.  (Additionally, for cryptographic
> algorithms using modular arithmetic with a 2^n modulus, any
> sign-extended bits larger than the modulus are ignored - chopped
> off in the modular reduction.)
> 
> With that in mind, is it ever necessary to do sign-bit protection
> of BER-encoded INTEGERs (adding an extra 00 whenever the MSB of
> the value is 1)?
> 
> In the following example, p and q each have MSB=1, and have the extra 00
> octet added.  g and s have MSB=0, so no extra octet is needed.
> The public key (y) and r both have MSB=1 and no extra octet, thus the
> encoding of y and r is inconsistent with the encoding of p and q.
> 
> Since a distinguished encoding of these values is required, there MUST
> be an encoding convention for whether to do sign padding when MSB=1.
> Most of the cert examples I have seen do not do sign padding.
> 
> I believe that padding:
> 
>  * is always unnecessary,
>  * is an added complication,
>  * is seen less often than unpadded INTEGERS in existing certs, and
>  * is inconsistent with the treatment of parameters encoded
>       as BIT STRINGs or OCTET STRINGs, which are never padded
> 
> so I would prefer to document the convention that sign padding is not
> to be used.
> 
> Questions:
> 
>  * Does a convention for sign padding of INTEGERs already exist anywhere?
>  * Is there ever a need to do sign-extension of encoded INTEGERS
>     (in which case padding would be necessary)?
>  * Does anyone feel that sign padding is desirable, regardless of whether
>     it is necessary?
> 
> If not, Part 1 should be amended to specify that compliant CAs SHALL
> NOT generate padding 00 bytes for INTEGERs, and that verifiers SHOULD
> accept both padded and unpadded INTEGERs.  And I will correct the
> examples accordingly.
> 
> -----------------------------------------------------------------------
> 
>       Version: v3
> Serial Number: 256
> Signature Alg: id-dsa-with-sha-1 (1.2.840.10040.4.3)
>    Parameters: NULL
>        Issuer: C=US, O=gov, OU=nist
>      Validity: Not Before 970609050000Z
>                Not After  980609050000Z
>       Subject: C=US, O=gov, OU=nist
> SubjectPKInfo: id-dsa (1.2.840.10040.4.1)
>    Parameters:
>       p:
>         00 93 e8 96 5d af d9 df ec fd 00 b4 66 b6 8f 90
>         ea 68 af 5d c9 fe d9 15 27 8d 1b 3a 13 74 71 e6
>         55 96 c3 7f ed 0c 78 29 ff 8f 83 31 f8 1a 27 00
>         43 8e cd cc 09 44 7d c3 97 c6 85 f3 97 29 4f 72
>         2b cc 48 4a ed f2 8b ed 25 aa ab 35 d3 5a 65 db
>         1f d6 2c 9d 7b a5 58 44 fe b1 f9 40 1e 67 13 40
>         93 3e e4 3c 54 e4 dc 45 94 00 d7 ad 61 24 8b 83
>         a2 62 48 35 b3 1f ff 2d 95 95 a5 b9 0b 27 6e 44
>         f9
>       q:
>         00 bb 5d fe 42 de 11 5c 00 db 5e f1 b0 38 83 44
>         d6 c1 54 85 ad
>       g:
>         69 27 9f 8e ba b8 0e 8f 24 f0 18 46 21 96 63 6c
>         4c 22 54 64 f0 13 3e 0f 2f 21 e7 bb ed 1d 85 3f
>         06 eb 94 9a 86 85 0a 30 a9 b5 b2 ce a8 30 ea ad
>         00 e7 bd f6 1e bc 81 cc 41 de ba ff 1b 5b fd 9f
>         2a a4 b1 13 29 b1 3c 3d c6 95 11 27 fb c8 6b 4d
>         35 33 82 3b f9 7a 58 de 2f f1 f9 c9 b3 17 7b a3
>         49 4e d5 e0 00 38 3d bd 6a 69 9d 57 89 54 8f ce
>         f5 07 36 8e 4b e6 6e eb 0f 08 75 73 8c bc fc c5
>    Public Key:
>         8b 20 50 88 00 73 c1 35 95 44 c5 5f ef b4 d8 08
>         b8 8d 21 ec 91 06 6e 2e 8a a7 a8 92 97 75 2d fa
>         87 f3 94 b7 72 3d 21 c8 5d 1e 3a 59 7a 6c c7 62
>         5b 2f c5 bc ae ce 68 ad 52 85 6a 83 5c a6 43 7d
>         d8 8e bc 7e ea 12 74 89 ec ad 89 fe 7a be fb fb
>         2a 0e 2e 28 8d 92 a1 7a 67 3d b2 52 73 39 63 8f
>         0f 79 c6 b2 f6 40 46 83 bf 62 6e 1c d2 25 b5 e5
>         5a ff d1 ad 4d b3 bc cc 65 bd 08 04 4e 11 32 45
>    Issuer UID: none
>   Subject UID: none
>    Extensions: 2
>   Extension 1: Critical basicConstraints (2.5.29.19)
>     CA = Yes, Pathlen = unlimited
>   Extension 2: Critical keyUsage (2.5.29.15)
>     Usage Bits= { keyCertSign cRLSign }
> Signature Alg: id-dsa-with-sha-1 (1.2.840.10040.4.3)
>    Parameters: NULL
> Signature Value:
>       r:
>         b3 2d dd 5e c9 f6 6d a7 91 c0 3f aa e7 43 77 40
>         f3 1f b1 64
>       s:
>         68 fd 1a 69 da 08 9c 27 9c 34 32 8b 43 23 cb d1
>         84 13 32 ca

-- 
Anil R. Gangolli
Structured Arts Computing Corp.
http://www.StructuredArts.com
mailto:[e-mail]



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 17:55:17 -0700
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA11364 for <[e-mail]>; Fri, 5 Dec 1997 15:22:43 -0800 (PST)
Received: from localhost (marcnarc@localhost) by crack.x509.com (8.8.7/8.8.7) with SMTP id PAA12430 for <[e-mail]>; Fri, 5 Dec 1997 15:16:22 -0800 (PST)
Date: Fri, 5 Dec 1997 15:16:19 -0800 (PST)
From: Marc Branchaud <[e-mail]>
X-Sender: marcnarc@crack
To: [e-mail]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP
In-Reply-To: <[e-mail]>
Message-ID: <Pine.SGI.3.96.971205145050.4683D-100000@crack>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----


On Fri, 5 Dec 1997, David P. Kemp wrote:
> 
> > From: Marc Branchaud <[e-mail]>
> > 
> > OCSP is an attempt to address some of the flaws of the CRL model.  For the
> > most part, the flaw with the most attention has been the untimeliness of
> > CRL revocation information.  But there's another CRL flaw that deserves
> > equal attention, and which isn't being properly addressed with the current
> > OCSP discussion.
> > 
> > The flaw is that the decision of when to release new revocation
> > information rests with the CA.  In other words, a relying party who needs
> > up-to-date revocation information in a CRL-only environment has to wait
> > for the next CRL to be published.  The relier has no power to influence
> > the CA into releasing revocation information earlier.
> 
> I don't see how OCSP with caching allows the relying party any more control
> over the timeliness of revocation information than does CRL with caching.
> 

If the relying party can decide whether or not to ignore the cache, then
the RP has more control.  Although your model of CRLs is different -- I'll
get to it below -- having CRLs sitting in a repository and refreshed
periodically does not give the RP the option of ignoring the cache,

> Of course, if a particular CA publishes CRLs once per month, many RPs will
> not find it sufficient.  But in the limit, there is no reason for CRLs
> to be published more frequently than on an event-driven basis - a new
> CRL issued every time the status of any covered certificate changes, or
> whenever the nextUpdate field kicks in if there have been no intervening
> status changes.
> 
> The CA (or CRL publisher) is the only entity authoritative for
> revocation events, so it makes more sense for the CA to push updates
> than for caching OCSP servers to decide to refresh based on some
> necessarily arbitrary criteria.  In the case of all but leaf
> certificates, it seems obvious that status-change events will occur
> *far* less frequently than status queries, so the CRL push model is
> more appropriate.
> 
> For leaf certs, I agree with you and Phill that simulations should be
> run over many parameter variations.  But my gut feeling is that if the
> RP needs status information that is accurate to within some fixed
> limit, that pushing CRLs out to caches based on status events or
> refreshing the caches based on some acceptably fine nextUpdate
> resolution, partitioned by name and/or reason, will again prove to be
> more bandwidth and processor efficient than OCSP over a wide range of
> parameters.
> 

CRL pushing and event-driven publishing are interesting ideas that deserve
as much consideration as OCSP.  I was addressing the more traditional
CRL-in-a-repository approach that PKIX is working with, and those two
solutions sound just as plausible as OCSP.

My main concerns with (traditional) CRLs are their untimeliness and
inflexibility.  OCSP is one way to address those problems, although
serious concerns have been raised about the current proposal.  But call it
OCSP or CRL push or whatever, there needs to be a formal part of PKIX that
describes how to obtain and support timely revocation information.

> 
> > This is an interesting approach.  We have a proposal that may not scale
> > to a million under reasonable assumptions.  Let's do some simulation to
> > see whether it can scale to a billion...
> 
> As B&B would say:  "Heh heh heh heh ..."
> 

Isn't that usually something more like "Uh huh, uh huh, uh huh huh, uh
huh..."?  :)

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNIiLRFrdFXNdDxPlAQHXygL/SF0V2d1lTVg7xIywmG9csFPlj7YFO4g7
HNDKQFs+GfDkYF0oE2iX4+SAPo3pVNkWZGMTSSkGIabLxG2d1TvbxgCfs1KW6fdz
zv9doVgKWFX/3ONy2tvmVkc4nAP7aEwM
=8DDk
-----END PGP SIGNATURE-----




Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 17:49:01 -0700
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA13317 for <[e-mail]>; Fri, 5 Dec 1997 15:35:32 -0800 (PST)
From: [e-mail]
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id PAA29970; Fri, 5 Dec 1997 15:34:58 -0800 (PST)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id PAA28949; Fri, 5 Dec 1997 15:34:56 -0800 (PST)
Message-Id: <3.0.32.19971205153458.008f8be0@mail>
X-Sender: mmyers@mail
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 05 Dec 1997 15:34:59 -0700
To: "Arsenault, Al W." <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Marc Branchaud'" <[e-mail]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Al,

At 03:03 PM 12/5/97 -0500, Arsenault, Al W. wrote:
>One question on Marc Branchaud's posting:
>
>You wrote:
>>
>>The flaw is that the decision of when to release new revocation
>>information rests with the CA.  In other words, a relying party who needs
>>up-to-date revocation information in a CRL-only environment has to wait
>>for the next CRL to be published.  The relier has no power to influence
>>the CA into releasing revocation information earlier.
>>
>>OCSP allows the relier to get the revocation information when it's needed,
>>without being subject to the CA's CRL schedule.  Because CRLs can only be
>>released periodically, they are at best a compromise solution to the needs
>>of relying parties.
>
>In most models/products with which I am familiar, the only entity which
>can mark a certificate as revoked is the CA who signed it in the first
>place.

As an initial condition, I agree.  But especially in the commercial space
we should not discount the utility of delegation of this authority by
contract.

I would also further sharpen the focus by observing that the private key
used to sign the certificate need not be the same private key used to sign
the corresponding CRL or OCSP response.

>
>Given this, why is an OCSP any less subject to the CA's schedule than a
>CRL strategy? That is:
>	- the CA receives from some source a request to mark a certificate it
>issued as revoked.  Possibly the request comes from the user himself
>("My private key has been compromised..."); possibly by the user's
>supervisor ("She no longer works here ..."); possibly from the CA's
>management chain ("He didn't pay his bill; kill his certificate").  
>	- the CA takes some finite amount of time to decide whether or not to
>actually mark the certificate as revoked.  (Automatically accepting
>revocation requests without some sort of validation on them is an open
>invitation to denial of service attacks.)
>A conscientious CA who is
>worried about liability will do this quickly, but it may take a while to
>propagate results out.


The model should also take into account the presence of an RA.  Depending
on the relationship established between and RA and a CA, the CA could
perform automatically.  Responsibility for diligence in this instance rests
on the RA.  In these instances, the RA legitimately considers itself more
authoritative for subscriber status than the CA.  It is willing to enter
into an agreement with the CA to this effect.


>	- thus, the OCSP solution still leaves a "window of vulnerability"
>wherein the certificate may be bad but this information is not available
>to the user.  Yes, it's the CA who assumes the liability during this
>interval, but that's the same as the CRL case.

I would agree that even in the case of a self-empowered RA above, this
window still exists.  OCSP is not a magic oracle able to peer directly onto
the user's hardware token, her daily actions or the state of her status as
a trusted employee (for examples).  Such is an ideal, like the theoretical
random number generator of cryptographic academia.

>
>Now, I'm a fan in general of something like an OCSP (as Mike Myers knows
>from one of his previous lives :-), and I recognize the limitations of
>CRLs.  They leave (sometimes very) large windows of vulnerability.  They
>can consume enormous amounts of bandwidth just being transferred across
>the network. They can cause significant workloads on the CA.  
>
>But let's be honest about this.  OCSP as it currently stands has some
>shortfalls.  As I pointed out above, there's still a window of
>vulnerability that extends until the CA actually agrees to mark the
>certificate as revoked. The protocol is vulnerable to replay, and denial
>of service related to replay.  

I would agree to the existance of window between event, report,
investigation and database marking.  Towards the replay issue though, I
believe we might be closer to a solution.  This is basically the
nonce-based argument.  I recently put to the list a proposal regarding an
optional OCSP nonce (with all due respect to the diligence of Ambarish, Bob
and Carlisle).

>
>Also, I think it's important to point out again:  OCSP is only good for
>answering one question:  "Does the CA who issued this certificate still
>stand behind it?"  That's not the same question as "Is this certificate
>valid right now?"  We need to recognize that, and make sure we all agree
>that that's what we want a protocol to do.

As noted, I see this more as difference between a Certificate Status Oracle
and that which is realistically achievable.  OCSP takes us much closer to
the CSO ideal than does CRLs.  Given a risk management model that is able
to accomodate contract-based protection, I believe we can get quite close
to a CSO.  We can close that window to an arbitrary degree of assurance.
In this case, parties reliant on a trusted third party's representations of
certificate validity may be at least as concerned with your first question
as with your second.

For organizations where contract-based risk management is not an option, I
would agree that OCSP fails to close the window quite as fully.

>
>			Al Arsenault
>	- I speak only for myself.  My opinions do not necessarily reflect
>those of my employer.
>>
>>
>
>




Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 16:48:49 -0700
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id OAA06856 for <[e-mail]>; Fri, 5 Dec 1997 14:52:30 -0800 (PST)
Received: from localhost (marcnarc@localhost) by crack.x509.com (8.8.7/8.8.7) with SMTP id OAA11384 for <[e-mail]>; Fri, 5 Dec 1997 14:46:08 -0800 (PST)
Date: Fri, 5 Dec 1997 14:45:58 -0800 (PST)
From: Marc Branchaud <[e-mail]>
X-Sender: marcnarc@crack
To: "'[e-mail]'" <[e-mail]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP
In-Reply-To: <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
Message-ID: <Pine.SGI.3.96.971205141252.4683C-100000@crack>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----


On Fri, 5 Dec 1997, Carlisle Adams wrote:
> 
> Unfortunately, your "slightly different perspective" is no longer
> supported in the latest OCSP revision.  The OCSP response message now
> contains "produced_at" and "expires_on" fields.  Recall Mike's message
> to the list:
>

[ snip ]

> 
> So, it turns out that the CA still controls when new revocation
> information is released.  Furthermore,  the functionality you're looking
> for is actually supported in the Notary protocol...
> 

I agree that the current proposal is inadequate.

Also, the CA obviously and inevitably is the sole authority regarding how
and when new revocation information is released.  OCSP does not seek to
relieve the CA of that role.  Rather, it's an effort to allow the
information to be propagated as quickly as possible.  CRLs are inadequate
for two reasons:  1. They impose delays that are unnecessary and 
unacceptable to relying parties; and 2. Each relying party has its own
idea of what's acceptable.  The advantage of OCSP is that it overcomes
those deficiencies.

Finally, the Notary protocol, as a revocation-checking protocol, is hardly
an improvement over the proposed OCSP spec.  For instance, it makes no
mention of caching or user-interface issues.  Here's it's description of
certificate notarization (i.e. status checking) from the introduction:

   When notarizing a certificate, the NA verifies that the certificate
   included in the request is a valid certificate and determines its 
   revocation status at a specified time.  Again, it checks the full 
   certification path from the certificate signing entity to a trusted 
   point.  The NA may be able to rely on all relevant CRLs and ARLs, or
   the NA may need to supplement this with access to more current status 
   information for the CA.  It includes this information, along with a 
   trusted time, to create a Notary Token.  (See Appendix C.)

Appendix C provides some extra detail, but it doesn't contain anything
that would challenge Tim's analysis.  The Notary protocol may be an
improvement over the OCSP proposal, but it's hardly the functioanlity I'm
looking for.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNIiELFrdFXNdDxPlAQFlSgMAtRD0sSAnC0iyH0ngPkz7cIlGvokao30r
cAMsNwmlph1RpHG37Fl4RDm8Shyu5+/qdYeEKTl3ApHFnZKTeiVaNI/n3b1D5HBa
Kme94Ya01b2azgwU+TeSayRLB0WUIIMb
=I0Ns
-----END PGP SIGNATURE-----




Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 16:40:56 -0700
Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id OAA03772 for <[e-mail]>; Fri, 5 Dec 1997 14:30:58 -0800 (PST)
Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Fri, 05 Dec 1997 11:09:32 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 05 Dec 1997 11:09:00 -0700
From: Bob Jueneman <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: OCSP Considerations
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline

Mike, sorry if I too negative. Sometimes it is difficult to know if someone
agrees with you but hasn't had time to say so, vs. is still thinking, vs.
disagreeing and/or ignoring you.  I appreciate the fact that we all have
other jobs to do as well.

With regard to your strawman proposal, my comments would be the following:

1.  I see no particularly good reason to avoid the use of ASN.1. Despite
some of its complexity, it provides a uniform way of documenting the
specifications that can be validated by use of a compiler (minimizing the
possibility of a misunderstanding). Anyone who is implementing any kind of a
PKI implementation is going to be up to their ears in ASN.1 -- a little more
won't hurt. But I wouldn't go to war on this issue.

2. Regardless of the ASN.1 decision, providing a means of easily extending
the protocol is absolutely vital. In particular, it is highly likely that
billing information will have to be conveyed in both directtions, and
ultimately a transaction value field as well.

3. Both the request and the response need to be signed, at least optionally,
and particularly if there is billing or other information associated.

4. I haven't studied the timestamping proposal, so I have no comment on the
use of an OID in this area.  It is sufficient, I believe, that the CA or
repository which is acting as an agent of the CA include the time, since in
most cases I believe that time per se will not be of critical importance.

5.  I don't see any particular utility in making the nonce field optional in
the request -- if someone is really convinced that they don't need it, they
can just fill in zeroes, without adding the addtiional complexity of
deciding whether or not it was included, and therefore whether it should be
included in the response.

7.  It would be nice, but perhaps not essential, to have something in the
request that specifically identifies the nonce as consisting of a message
digest (SHA-1 by default) of the date/time of the request concatenated with
the digital signature which is being validated by this OCSP request.

Regards,

Bob


>>> <[e-mail]> 12/04 6:23 PM >>>
Bob,

Actually, you are making headway, as have Richard Ankey, Carlisle, Ambarish
and others.  The fact is that when the sudden rush of interest and comment
on OCSP started pouring in--both on-list and off-list--I saw the whole
thing going down a long and slippery slope without due consideration given
to fundamental requirements.

I still firmly believe that simplicity is a fundamental requirement.  That
said, having now had the last few days to go back and digest the recent
input, I'm quite certain a specification of OCSP can be crafted that
strikes an acceptable compromise among the various positions.  For the
benefit of those who may not be able to make it to the IETF next week,
here's a strawman proposal:

1. Re-craft the request & response syntax (still non-ASN.1) to more
effectively enable extensibility without introducing implementation
complexity.  The current syntax is simply too rigid to do extensibility
cleanly.

2. Add an optional policy OID in alignment with the Timestamping proposal.
I would still recommend we go cautiously here.  Matching an OID should be
fairly straightforward for environments with a need; algorithmic models of
policy a la SPKI may never see the light of day.

3. Add an optional nonce for replay detection.  This could be included
within the scope of the extensibility mechanism.  I've never needed
convincing that nonces are good, but we do need to ensure that the final
OCSP solution enables one to make a choice whether or not to take full
advantage of the existing Internet infrastructure.

Regarding SSL, I agree with your observeration.  OCSP is signed content for
exactly the reason you note.  Technically, we should recognize however that
there exists nothing in the OCSP protocol model which inhibits use of SSL
for who wish to do so.

Mike


At 11:21 AM 12/3/97 -0700, you wrote:
>>It seems that the main purpose of having signed responses in OCSP
>>is to authenticate the responder.
>>
>>Would it be useful, and perhaps simplify things, to permit SSL/https
>>to be used in the protocol instead of requiring signed responses over
>>http?
>
>I don't think so.  Although I'm not making much headway in trying to get
>OCSP to be more responsive to the nonrepudiation requirement,
authenticating
>the responder via SSL would not provide any lingering proof of the the
>certificate's status.
>>
>>I am assuming here that the responder is tightly coupled to the CA.
>>If the responder's site certificate is revoked then the responder
>>itself would have to get disabled or updated by the CA.
>>
>>==========================================
>>Dan Laska
>>Frontier Technologies Corp.
>>Email: [e-mail] 
>>==========================================
>
>Bob
>
>

                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                        



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 16:19:25 -0700
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id OAA01976 for <[e-mail]>; Fri, 5 Dec 1997 14:18:44 -0800 (PST)
Received: from localhost (marcnarc@localhost) by crack.x509.com (8.8.7/8.8.7) with SMTP id OAA10308 for <[e-mail]>; Fri, 5 Dec 1997 14:12:19 -0800 (PST)
Date: Fri, 5 Dec 1997 14:12:17 -0800 (PST)
From: Marc Branchaud <[e-mail]>
X-Sender: marcnarc@crack
To: "'[e-mail]'" <[e-mail]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP
In-Reply-To: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
Message-ID: <Pine.SGI.3.96.971205135120.4683B-100000@crack>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----


On Fri, 5 Dec 1997, Arsenault, Al W. wrote:
> 
> Given this, why is an OCSP any less subject to the CA's schedule than a
> CRL strategy? That is:
> 	- the CA receives from some source a request to mark a certificate it
> issued as revoked.  Possibly the request comes from the user himself
> ("My private key has been compromised..."); possibly by the user's
> supervisor ("She no longer works here ..."); possibly from the CA's
> management chain ("He didn't pay his bill; kill his certificate").  
> 	- the CA takes some finite amount of time to decide whether or not to
> actually mark the certificate as revoked.  (Automatically accepting
> revocation requests without some sort of validation on them is an open
> invitation to denial of service attacks.)  A conscientious CA who is
> worried about liability will do this quickly, but it may take a while to
> propagate results out.
> 	- thus, the OCSP solution still leaves a "window of vulnerability"
> wherein the certificate may be bad but this information is not available
> to the user.  Yes, it's the CA who assumes the liability during this
> interval, but that's the same as the CRL case.
> 

CA processing delays certainly exist, but there are two separate issues
here:

1. When is a certificate considered Revoked?  When the CA receives a
notice of revocation, or when the CA marks the certificate as revoked?
That's a matter of semantics, though I would suggest that the latter
definition makes more sense than the former.  The CA is the final arbiteur
of certificate status.

2. Back with OCSP vs. CRL -- Both approaches are subject to the window o'
vulnerability you describe.  However, CRLs impose an additional window,
specifically the time until the next CRL is published.  OCSP avoids this
second window.

There's a difference between making the information available as fast as
possible and making it available on a regular schedule.  The CRL approach
gives the CA an opportunity to say "I've done everything I'm supposed to"
while the relying party is still left in the lurch.  OCSP would eliminate
these situations where a CA knows true revocation status internally, but
that information is hidden from the rest of the world.

> Now, I'm a fan in general of something like an OCSP (as Mike Myers knows
> from one of his previous lives :-), and I recognize the limitations of
> CRLs.  They leave (sometimes very) large windows of vulnerability.  They
> can consume enormous amounts of bandwidth just being transferred across
> the network. They can cause significant workloads on the CA.  
> 
> But let's be honest about this.  OCSP as it currently stands has some
> shortfalls.  As I pointed out above, there's still a window of
> vulnerability that extends until the CA actually agrees to mark the
> certificate as revoked.

Agreed.  But I don't see how that can be avoided.  It takes a finite
amount of time to place a phone call, or flip a bit.  Physics limits us
all...

> The protocol is vulnerable to replay, and denial
> of service related to replay.  
> 

I agree here, too, in that the protocol as proposed is not what I envision
as a useful description of OCSP.  It glosses over too many details and 
leaves too many questions unanswered.

> Also, I think it's important to point out again:  OCSP is only good for
> answering one question:  "Does the CA who issued this certificate still
> stand behind it?"  That's not the same question as "Is this certificate
> valid right now?"  We need to recognize that, and make sure we all agree
> that that's what we want a protocol to do.
> 

This is an interesting, though separate, point.  What does "valid" mean
anyway?  From one perspective, the two questions you list are indeed the
same question, as a CA would revoke any certificate it no longer stands
behind, thus making it invalid.

On the other hand, it gets at the semantic debate I mentioned earlier.
When is a certificate no longer valid?  Is it the moment when the private
key is compromised, or is it when the CA revokes the certificate?
Unfortunately, the former is far more difficult to pin down than the
latter.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNIh8QlrdFXNdDxPlAQFHrAL/QgzkBmM2cdakRzs1yjIc8dvwFp0+vj0y
ITSdSmtfpN2Psl6ag3MTp8q201S39+8DfEgmksvj6kRPJFS6O9JBOpVWik1sM2OQ
3JHA5HP4+5n2lrUoTCdeHjiHB3Rl/hvQ
=upEC
-----END PGP SIGNATURE-----




Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 16:16:37 -0700
Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id OAA00691 for <[e-mail]>; Fri, 5 Dec 1997 14:10:24 -0800 (PST)
Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Fri, 05 Dec 1997 10:42:23 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 05 Dec 1997 10:41:54 -0700
From: Bob Jueneman <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: Critical extensions and Policy OIDs
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline

Dave,

So that we are all on the same page, let me refer you to the Oct 14th draft
of part 1, paragraph 4.2.1.5 Certificate Policies, second paragraph:

"Applications with specific policy requirements are expected to have a list
of those policies which they will accept and to compare the policy OIDs in
the certificate in that list. If this extension is critical, the path
validation software must be able to interpret this extension, or must reject
the certificate."

So far so good, although the text tends to put too much emphasis on
applications deciding on their own what policy requirements they require and
will enforce, whereas I believe that such decisions will more often be made
by the MIS department and conveyed in the root-level certificate (issued by
the MIS department) which cross-certifies particular CAs and imposes any
necessary policy constraints on subsequent certificates.

Where the train jumps the track is in the following sentence of the
paragraph:

"(Applications without specific policy requirements are not required to list
acceptable policies, AND MAY ACCEPT ANY VALID CERTIFICATE REGARDLESS OF
POLICY EVEN IF THE EXTENSION IS MARKED CRITICAL.)"

This takes the issue well beyond that of a rogue application.  It says that
a PKIX standards-conforming application can ignore an attribute bearing a
Critical marking with impunity -- it doesn't have to even notify the user
that it saw something that it doesn't understand.

I believe that this is COMPLETELY UNACCEPTABLE, and I would appreciate your
help in convincing the authors of part-1 (Messrs. Housley, Ford, Polk, and
Solo) to delete this sentence.

I think that we are in agreement that if someone goes out and buys an
application that is non-conforming, we aren't going to sic the Internet
police on him. I'm not trying to prevent anyone from building rogue
applications. However, if someone knowingly uses an application that does
not conform to the standard, or does not implement the Critical attribute
correctly, he has to accept the consequences of his actions, and both the CA
and the subscriber should be relieved of any liability that might result
from the relying party accepting some transaction that they should have
rejected, based on the policy OID and the Critical flag.

But if the standard itself says that such markings can be ignored with
impunity and still be considered as conforming to the standard, then the CA
and/or the subscriber haven't a leg to stand on, for they have no way to
ensure that effective legal notice is provided to any potential relying
party.

This sentence must be removed or clarified considerably before the standard
can be accepted, IMHO, for the concept of a Critical attribute is
fundamental to the entire concept of legal notice which the certificate is
supposed to provide.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[e-mail]

"If you are trying to get to the moon, climbing a tree, 
although a step in the right direction, will not prove 
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."


>>> <[e-mail]> 12/04 2:29 PM >>>
Bob, Mike,
 I agree completely with the importance of obeying critical extensions. But
I 
also believe that there will be "rogue applications" that may or may not
handle 
these extensions properly dependent on the specific application. For
example, 
if I have a certificate whose policy is explicitly for signing user 
certificates, someone may develop an application that allows me to use that 
certificate for applying for a credit card exclusively for CAs. The "relying

party" in this case accepts the risk in using that certificate despite the 
policy under which it was issued. If used improperly by these rogue 
applications, Mike is correct in saying that all CA (or other) liability is 
relieved. Hopefully, the relying party would have a difficult fight in court
if 
they wanted to blame the CA who issued that certificate. The point is that
we 
can only write the specifications, we cannot enforce them.

Cheers,
Dave Oshman

Price Waterhouse LLP
Electronic Commerce/Internet Practice
>Date:    Wed, 3 Dec 1997 08:34:05 -0700
>From:    Mike Smith <[e-mail]>
>Subject: Re: digitalSignature vs. nonRepudiation
>As usual, Bob, I find myself agreeing with your statements.
>
>A certificate is issued under a certain set of authority policies.  If
someone 
wishes >to rely on a certificate issued under those policies, then the
software 
they use must >be able to process all of the critical extensions established

under that policy or >not honor the certificate.
>
>If someone does accept a certificate or signature issued with critical 
extensions >that are ignored or interpreted other than the intent of the 
issuing CA, then, it is >my belief, the reliant party (and, possibly the
entity 
that modified the code to >accept or ignore the critical extensions) has
just 
relieved the CA of any and all >liability regarding that critical extension 
and, quite possibly, the whole >certificate's issued purpose.
>
>Michael
>
>>> Bob Jueneman <[e-mail]> 12/02/97 11:12AM >>>
>Sharon and David,
>
>My tongue in cheek suggestion that we deprecate the keyUsage field was made
>as a result of my confusion and exasperation in trying to sort though all
of
>these different issues.  But if we can't agree on some relatively simple
>meaning, I submit that using the fields will actually be WORSE than
>deprecating them, for one person will think that they mean one thing, and
>another person will interpret them differently.
>
>What good does it do to mark an attribute as critical, if the semantics are
>as undefined or ambiguous as these are?
>
>And to bring up a somewhat different ubject that I mentioned before, but
>never got closure on, I think that it is completely UNACCEPTABLE to say
that
>if some particular application does not have, understand, or chose to
>implement a security policy, it should be free to simply ignore the
critical
>marking on a Policy OID constraint. This simply turns the definition of
>critical on its head.  The critical usage is provided primarily to protect
>the CA and/or the subject of the certificate from unreasonable reliance on
>the certificate, and to provide a means for IT administrators to centrally
>control what kinds of policies are to be enforced.
>
>Bob
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                     



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 16:04:25 -0700
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id NAA28538 for <[e-mail]>; Fri, 5 Dec 1997 13:56:28 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA03198 for <[e-mail]>; Fri, 5 Dec 1997 16:56:27 -0500 (EST)
Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA03194 for <[e-mail]>; Fri, 5 Dec 1997 16:56:27 -0500 (EST)
Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id QAA09311 for <[e-mail]>; Fri, 5 Dec 1997 16:53:18 -0500
Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id QAA06657; Fri, 5 Dec 1997 16:54:37 -0500
Date: Fri, 5 Dec 1997 16:54:37 -0500
From: [e-mail] (David P. Kemp)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Encoding of INTEGER fields in PKIX certs
X-Sun-Charset: US-ASCII

ASN.1 Folks,

I have the following certificate, which is intended for use
in the PKIX Certificate and CRL Profile examples draft.

There are several fields representing cryptographic bignums which
are encoded as INTEGERs: the DSA parameters p, q, and g; the
DSA public key y, and the DSA signature values r and s.

ASN.1 INTEGERS are encoded as two's-complement numbers, which
implies that if a BER-encoded value is decoded into a larger
native storage value, the high bit of the encoded value will be
sign-extended into the excess bits of the native value.
For cryptographic purposes, it is my understanding that bignums
are always the same size as the encoded values, so the issue
of sign extension never arises.  (Additionally, for cryptographic
algorithms using modular arithmetic with a 2^n modulus, any
sign-extended bits larger than the modulus are ignored - chopped
off in the modular reduction.)

With that in mind, is it ever necessary to do sign-bit protection
of BER-encoded INTEGERs (adding an extra 00 whenever the MSB of
the value is 1)?

In the following example, p and q each have MSB=1, and have the extra 00
octet added.  g and s have MSB=0, so no extra octet is needed.
The public key (y) and r both have MSB=1 and no extra octet, thus the
encoding of y and r is inconsistent with the encoding of p and q.

Since a distinguished encoding of these values is required, there MUST
be an encoding convention for whether to do sign padding when MSB=1.
Most of the cert examples I have seen do not do sign padding.

I believe that padding:

 * is always unnecessary,
 * is an added complication,
 * is seen less often than unpadded INTEGERS in existing certs, and
 * is inconsistent with the treatment of parameters encoded
      as BIT STRINGs or OCTET STRINGs, which are never padded

so I would prefer to document the convention that sign padding is not
to be used.

Questions:

 * Does a convention for sign padding of INTEGERs already exist anywhere?
 * Is there ever a need to do sign-extension of encoded INTEGERS
    (in which case padding would be necessary)?
 * Does anyone feel that sign padding is desirable, regardless of whether
    it is necessary?

If not, Part 1 should be amended to specify that compliant CAs SHALL
NOT generate padding 00 bytes for INTEGERs, and that verifiers SHOULD
accept both padded and unpadded INTEGERs.  And I will correct the
examples accordingly.



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

      Version: v3
Serial Number: 256
Signature Alg: id-dsa-with-sha-1 (1.2.840.10040.4.3)
   Parameters: NULL
       Issuer: C=US, O=gov, OU=nist
     Validity: Not Before 970609050000Z
               Not After  980609050000Z
      Subject: C=US, O=gov, OU=nist
SubjectPKInfo: id-dsa (1.2.840.10040.4.1)
   Parameters:
      p:
        00 93 e8 96 5d af d9 df ec fd 00 b4 66 b6 8f 90
        ea 68 af 5d c9 fe d9 15 27 8d 1b 3a 13 74 71 e6
        55 96 c3 7f ed 0c 78 29 ff 8f 83 31 f8 1a 27 00
        43 8e cd cc 09 44 7d c3 97 c6 85 f3 97 29 4f 72
        2b cc 48 4a ed f2 8b ed 25 aa ab 35 d3 5a 65 db
        1f d6 2c 9d 7b a5 58 44 fe b1 f9 40 1e 67 13 40
        93 3e e4 3c 54 e4 dc 45 94 00 d7 ad 61 24 8b 83
        a2 62 48 35 b3 1f ff 2d 95 95 a5 b9 0b 27 6e 44
        f9
      q:
        00 bb 5d fe 42 de 11 5c 00 db 5e f1 b0 38 83 44
        d6 c1 54 85 ad
      g:
        69 27 9f 8e ba b8 0e 8f 24 f0 18 46 21 96 63 6c
        4c 22 54 64 f0 13 3e 0f 2f 21 e7 bb ed 1d 85 3f
        06 eb 94 9a 86 85 0a 30 a9 b5 b2 ce a8 30 ea ad
        00 e7 bd f6 1e bc 81 cc 41 de ba ff 1b 5b fd 9f
        2a a4 b1 13 29 b1 3c 3d c6 95 11 27 fb c8 6b 4d
        35 33 82 3b f9 7a 58 de 2f f1 f9 c9 b3 17 7b a3
        49 4e d5 e0 00 38 3d bd 6a 69 9d 57 89 54 8f ce
        f5 07 36 8e 4b e6 6e eb 0f 08 75 73 8c bc fc c5
   Public Key:
        8b 20 50 88 00 73 c1 35 95 44 c5 5f ef b4 d8 08
        b8 8d 21 ec 91 06 6e 2e 8a a7 a8 92 97 75 2d fa
        87 f3 94 b7 72 3d 21 c8 5d 1e 3a 59 7a 6c c7 62
        5b 2f c5 bc ae ce 68 ad 52 85 6a 83 5c a6 43 7d
        d8 8e bc 7e ea 12 74 89 ec ad 89 fe 7a be fb fb
        2a 0e 2e 28 8d 92 a1 7a 67 3d b2 52 73 39 63 8f
        0f 79 c6 b2 f6 40 46 83 bf 62 6e 1c d2 25 b5 e5
        5a ff d1 ad 4d b3 bc cc 65 bd 08 04 4e 11 32 45
   Issuer UID: none
  Subject UID: none
   Extensions: 2
  Extension 1: Critical basicConstraints (2.5.29.19)
    CA = Yes, Pathlen = unlimited
  Extension 2: Critical keyUsage (2.5.29.15)
    Usage Bits= { keyCertSign cRLSign }
Signature Alg: id-dsa-with-sha-1 (1.2.840.10040.4.3)
   Parameters: NULL
Signature Value:
      r:
        b3 2d dd 5e c9 f6 6d a7 91 c0 3f aa e7 43 77 40
        f3 1f b1 64
      s:
        68 fd 1a 69 da 08 9c 27 9c 34 32 8b 43 23 cb d1
        84 13 32 ca



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 16:04:20 -0700
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id NAA28036 for <[e-mail]>; Fri, 5 Dec 1997 13:52:20 -0800 (PST)
Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Fri, 5 Dec 1997 16:42:46 -0500
Message-ID: <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Marc Branchaud'" <[e-mail]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP
Date: Fri, 5 Dec 1997 16:42:44 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Marc,

>----------
>From: 	Marc Branchaud[SMTP:[e-mail]]
>Sent: 	Friday, December 05, 1997 1:37 PM
>To: 	[e-mail]
>Subject: 	Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>I agree with Phill's comments below, and would like to add what I think is
>a slightly different perspective.
>
>OCSP is an attempt to address some of the flaws of the CRL model.  For the
>most part, the flaw with the most attention has been the untimeliness of
>CRL revocation information.  But there's another CRL flaw that deserves
>equal attention, and which isn't being properly addressed with the current
>OCSP discussion.
>
>The flaw is that the decision of when to release new revocation
>information rests with the CA.  In other words, a relying party who needs
>up-to-date revocation information in a CRL-only environment has to wait
>for the next CRL to be published.  The relier has no power to influence
>the CA into releasing revocation information earlier.
>
>OCSP allows the relier to get the revocation information when it's needed,
>without being subject to the CA's CRL schedule.  Because CRLs can only be
>released periodically, they are at best a compromise solution to the needs
>of relying parties.

Unfortunately, your "slightly different perspective" is no longer
supported in the latest OCSP revision.  The OCSP response message now
contains "produced_at" and "expires_on" fields.  Recall Mike's message
to the list:

I've revised the OCSP draft on the basis of recent comments and debate.
Notice of its availability in all the usual places should be showing up
in
due course.  The revisions include:

- specification of HTTP 1.1 vs. 1.0
- elimination of the prior_to field in the request
- addition of a {produce_at, expires_on} interval in the response
- addition of requirements on the periodicity of pre-production of
responses

With the exception of the first one (which has to do with 1.0 being an
Informational document while 1.1 is Standards Track), the changes
address
the replay issue and scalability factors.

So, it turns out that the CA still controls when new revocation
information is released.  Furthermore,  the functionality you're looking
for is actually supported in the Notary protocol...


--------------------------------------------
Carlisle Adams
Entrust Technologies
[e-mail]
--------------------------------------------



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 15:41:00 -0700
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id MAA20244 for <[e-mail]>; Fri, 5 Dec 1997 12:54:29 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA01984 for <[e-mail]>; Fri, 5 Dec 1997 15:54:27 -0500 (EST)
Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA01980 for <[e-mail]>; Fri, 5 Dec 1997 15:54:27 -0500 (EST)
Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id PAA08768 for <[e-mail]>; Fri, 5 Dec 1997 15:51:18 -0500
Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id PAA06629; Fri, 5 Dec 1997 15:52:36 -0500
Date: Fri, 5 Dec 1997 15:52:36 -0500
From: [e-mail] (David P. Kemp)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP
X-Sun-Charset: US-ASCII

> From: Marc Branchaud <[e-mail]>
> 
> OCSP is an attempt to address some of the flaws of the CRL model.  For the
> most part, the flaw with the most attention has been the untimeliness of
> CRL revocation information.  But there's another CRL flaw that deserves
> equal attention, and which isn't being properly addressed with the current
> OCSP discussion.
> 
> The flaw is that the decision of when to release new revocation
> information rests with the CA.  In other words, a relying party who needs
> up-to-date revocation information in a CRL-only environment has to wait
> for the next CRL to be published.  The relier has no power to influence
> the CA into releasing revocation information earlier.

I don't see how OCSP with caching allows the relying party any more control
over the timeliness of revocation information than does CRL with caching.

Of course, if a particular CA publishes CRLs once per month, many RPs will
not find it sufficient.  But in the limit, there is no reason for CRLs
to be published more frequently than on an event-driven basis - a new
CRL issued every time the status of any covered certificate changes, or
whenever the nextUpdate field kicks in if there have been no intervening
status changes.

The CA (or CRL publisher) is the only entity authoritative for
revocation events, so it makes more sense for the CA to push updates
than for caching OCSP servers to decide to refresh based on some
necessarily arbitrary criteria.  In the case of all but leaf
certificates, it seems obvious that status-change events will occur
*far* less frequently than status queries, so the CRL push model is
more appropriate.

For leaf certs, I agree with you and Phill that simulations should be
run over many parameter variations.  But my gut feeling is that if the
RP needs status information that is accurate to within some fixed
limit, that pushing CRLs out to caches based on status events or
refreshing the caches based on some acceptably fine nextUpdate
resolution, partitioned by name and/or reason, will again prove to be
more bandwidth and processor efficient than OCSP over a wide range of
parameters.



> On Fri, 5 Dec 1997, Phillip M Hallam-Baker wrote:
> > 
> > OCSP supports a function call end clients make routinely: 'Is this
> > certificate valid'.

I thought we had already established that this was NOT the goal of
OCSP.  OCSP was presented as merely answering the question "Has this
certificate been revoked?", the example given being the need to cut off
people who demonstrate the danger of relying on MS Authenticode as an
applet privilege management mechanism.  (Silencing the messengers,
rather than fixing the problem, as it were.)

The question of certificate validity is far more complex.  It might be
somewhat useful to have a locally-administered validity server within a
small group of mutually-trusting machines, but it doesn't make much
(any?) sense to export that function outside of a single administrative
domain.



> From: Carlisle Adams <[e-mail]>
> 
> >To gain perspective on scaling issues I believe we should look at a billion
> >certificates or more rather than Tim's million. At least two applications
> >will involve this number of certificates:
> >
> >    * Credit card processing
> >    * Certificate based equities
> >
> >Both these scenarios are much smaller than systems I have previously helped
> >design, ZEUS and the Web. Simulation is the only way to prove viability of
> >such systems. I see OCSP as a usefull tool in meeting such challenges which
> >require a 'full toolbox'.
> 
> This is an interesting approach.  We have a proposal that may not scale
> to a million under reasonable assumptions.  Let's do some simulation to
> see whether it can scale to a billion...

As B&B would say:  "Heh heh heh heh ..."



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 14:39:14 -0700
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id MAA13576 for <[e-mail]>; Fri, 5 Dec 1997 12:03:57 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA01086 for <[e-mail]>; Fri, 5 Dec 1997 15:03:48 -0500 (EST)
Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA01077 for <[e-mail]>; Fri, 5 Dec 1997 15:03:47 -0500 (EST)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id PAA08454 for <[e-mail]>; Fri, 5 Dec 1997 15:00:38 -0500
Received: from avenger.missi.ncsc.mil (unverified [144.51.58.206]) by mimesweeper.missi.ncsc.mil (Integralis SMTPRS 2.02) with SMTP id <[e-mail]>; Fri, 05 Dec 1997 15:04:29 -0500
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <[e-mail]>; Fri, 5 Dec 1997 15:03:49 -0500
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Arsenault, Al W." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Marc Branchaud'" <[e-mail]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP
Date: Fri, 5 Dec 1997 15:03:48 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

One question on Marc Branchaud's posting:

You wrote:
>
>The flaw is that the decision of when to release new revocation
>information rests with the CA.  In other words, a relying party who needs
>up-to-date revocation information in a CRL-only environment has to wait
>for the next CRL to be published.  The relier has no power to influence
>the CA into releasing revocation information earlier.
>
>OCSP allows the relier to get the revocation information when it's needed,
>without being subject to the CA's CRL schedule.  Because CRLs can only be
>released periodically, they are at best a compromise solution to the needs
>of relying parties.

In most models/products with which I am familiar, the only entity which
can mark a certificate as revoked is the CA who signed it in the first
place.

Given this, why is an OCSP any less subject to the CA's schedule than a
CRL strategy? That is:
	- the CA receives from some source a request to mark a certificate it
issued as revoked.  Possibly the request comes from the user himself
("My private key has been compromised..."); possibly by the user's
supervisor ("She no longer works here ..."); possibly from the CA's
management chain ("He didn't pay his bill; kill his certificate").  
	- the CA takes some finite amount of time to decide whether or not to
actually mark the certificate as revoked.  (Automatically accepting
revocation requests without some sort of validation on them is an open
invitation to denial of service attacks.)  A conscientious CA who is
worried about liability will do this quickly, but it may take a while to
propagate results out.
	- thus, the OCSP solution still leaves a "window of vulnerability"
wherein the certificate may be bad but this information is not available
to the user.  Yes, it's the CA who assumes the liability during this
interval, but that's the same as the CRL case.

Now, I'm a fan in general of something like an OCSP (as Mike Myers knows
from one of his previous lives :-), and I recognize the limitations of
CRLs.  They leave (sometimes very) large windows of vulnerability.  They
can consume enormous amounts of bandwidth just being transferred across
the network. They can cause significant workloads on the CA.  

But let's be honest about this.  OCSP as it currently stands has some
shortfalls.  As I pointed out above, there's still a window of
vulnerability that extends until the CA actually agrees to mark the
certificate as revoked. The protocol is vulnerable to replay, and denial
of service related to replay.  

Also, I think it's important to point out again:  OCSP is only good for
answering one question:  "Does the CA who issued this certificate still
stand behind it?"  That's not the same question as "Is this certificate
valid right now?"  We need to recognize that, and make sure we all agree
that that's what we want a protocol to do.

			Al Arsenault
	- I speak only for myself.  My opinions do not necessarily reflect
those of my employer.
>
>



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 13:35:24 -0700
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id LAA06076 for <[e-mail]>; Fri, 5 Dec 1997 11:19:27 -0800 (PST)
Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Fri, 5 Dec 1997 14:09:11 -0500
Message-ID: <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>
Subject: RE: [IETF-PKIX] OCSP v CRLs over HTTP
Date: Fri, 5 Dec 1997 14:09:09 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Phill,

>----------
>From: 	Phillip M Hallam-Baker[SMTP:[e-mail]]
>Sent: 	Friday, December 05, 1997 11:28 AM
>To: 	[e-mail]
>Subject: 	Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>Re Tim Moses <[e-mail]> comments concerning the alledged 'non
>scalability of OCSP'.
>
>I have been reviewing Tim's comments concerning the 'scalability of OCSP'.
>First I note that Tim does not address scalability but the relative
>performance of OCSP and the Entrust approach under his chosen set of
>assumptions.

You seem to be misunderstanding something here.  "CRLs over HTTP" is not
the "Entrust approach"; it is a part of what was previously called
PKIX-2, as is OCSP.  The FTP/HTTP spec. was not authored by Entrust and
we had no contribution to it whatsoever.  Tim was simply comparing two
IETF PKIX drafts.

>Scalability is about  whether an architecture limits the size of the problem
>that can be handled. e.g. resource requirements scale O(n^2)or worse or it
>assumes a big enough mainframe can be purchased.
>
>OCSP supports a function call end clients make routinely: 'Is this
>certificate valid'. It allows the function 'check every certificate in my
>address book' to be supported cleanly. Unless you want to either handle CRLs
>in the client or route all traffic through a central bottleneck OCSP is the
>obvious approach.

OCSP may seem like the obvious approach if it is viewed only from the
client end.  However, Tim's message pointed out that the CA supporting
this functionality appears to need a HUGE pipe to deliver this service.
I fully agree with your observation above:  scalability *is* about
whether an architecture limits the size of the problem that can be
handled.  In the case of OCSP, the architecture appears to do just that.

Note too, though, that scalability is not the only point of discussion.
The thrust of Tim's message is that CRLs (using distribution points)
over HTTP is the general solution, of which OCSP is one specific
instance.  Maybe it makes sense to standardize a general solution that
can be engineered to provide OCSP-like functionality if desired, or can
be engineered in any other desired way for other
requirements/environments.  Doesn't this sound like a reasonable thing
for an *Internet* PKI WG to do?

>To gain perspective on scaling issues I believe we should look at a billion
>certificates or more rather than Tim's million. At least two applications
>will involve this number of certificates:
>
>    * Credit card processing
>    * Certificate based equities
>
>Both these scenarios are much smaller than systems I have previously helped
>design, ZEUS and the Web. Simulation is the only way to prove viability of
>such systems. I see OCSP as a usefull tool in meeting such challenges which
>require a 'full toolbox'.

This is an interesting approach.  We have a proposal that may not scale
to a million under reasonable assumptions.  Let's do some simulation to
see whether it can scale to a billion...


--------------------------------------------
Carlisle Adams
Entrust Technologies
[e-mail]
--------------------------------------------





Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 13:21:33 -0700
Received: from ns.ietf.org (ietf.org [132.151.1.19]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA02128 for <[e-mail]>; Fri, 5 Dec 1997 10:57:43 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20545; Fri, 5 Dec 1997 13:57:35 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ocsp-01.txt
Date: Fri, 05 Dec 1997 13:57:34 -0500
Sender: [e-mail]

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 Public Key Infrastructure Online 
                          Certificate Status Protocol - OCSP
	Author(s)	: M. Myers
	Filename	: draft-ietf-pkix-ocsp-01.txt
	Pages		: 7
	Date		: 04-Dec-97
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure
(PKI).  This document specifies an HTTP-based application protocol use-
ful in determining the current status of a digital certificate without
the use of CRLs.  Additional mechanisms addressing PKIX operational re-
quirements are specified in separate documents.
 
Please send comments on this document to the [e-mail] mail
list.

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

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ocsp-01.txt".
	
NOTE:	The mail server at ds.internic.net 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]>

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Ishmael:Get I-D ACTION-draft-ietf-pkix- (EuSn/CSOm) (00004EA5)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocsp-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Ishmael:Get draft-ietf-pkix-ocsp-01.txt (AURL/Arch) (00004EA6)
Content-Type: text/plain
Content-ID:	<[e-mail]>




Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 13:07:24 -0700
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA29579 for <[e-mail]>; Fri, 5 Dec 1997 10:43:47 -0800 (PST)
Received: from localhost (marcnarc@localhost) by crack.x509.com (8.8.7/8.8.7) with SMTP id KAA04207 for <[e-mail]>; Fri, 5 Dec 1997 10:37:22 -0800 (PST)
Date: Fri, 5 Dec 1997 10:37:20 -0800 (PST)
From: Marc Branchaud <[e-mail]>
X-Sender: marcnarc@crack
To: [e-mail]
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP
In-Reply-To: <01bd019a$e3e26ba0$[e-mail]>
Message-ID: <Pine.SGI.3.96.971205094229.1118D-100000@crack>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----


I agree with Phill's comments below, and would like to add what I think is
a slightly different perspective.

OCSP is an attempt to address some of the flaws of the CRL model.  For the
most part, the flaw with the most attention has been the untimeliness of
CRL revocation information.  But there's another CRL flaw that deserves
equal attention, and which isn't being properly addressed with the current
OCSP discussion.

The flaw is that the decision of when to release new revocation
information rests with the CA.  In other words, a relying party who needs
up-to-date revocation information in a CRL-only environment has to wait
for the next CRL to be published.  The relier has no power to influence
the CA into releasing revocation information earlier.

OCSP allows the relier to get the revocation information when it's needed,
without being subject to the CA's CRL schedule.  Because CRLs can only be
released periodically, they are at best a compromise solution to the needs
of relying parties.

Of course, OCSP can't be used in all situations.  A caching mechanism is
needed to relieve bandwidth pressures.  But CRLs are poor candidates for
a caching mechanism, because they still dictate to relying parties when
their caches can be refreshed.

It is crucial that relying parties get the revocation information they
need when they need it.  To accomplish that, CRLs need to be avoided
entirely.  Instead, relying parties should cache OCSP responses, and
decide for themselves when to refresh their caches.

Luckily, it's easy to charge for an OCSP query.  So we have the makings of
a self-regulating system.  Parties who need real-time revocation
information can pay for it.  On the other hand, once I find the validity
of my buddy's email signature certificate it's unlikely that I'll feel a
desperate need to refresh that validity information every time I read one
of his messages.  Especially if I have to pay $x every time I do so.

The point is that in order to allow CAs to serve the widest community of
users, they need to be flexible enough to properly serve those users'
needs.  CRLs simply do not provide the required flexibility.

The OCSP proposal, as it stands, is also inadequate.  Along with the OCSP
specification, we need a description of the caching mechanism, which can
be simple, but is definiately required.  We also need to define user
interface behavior, because real people are ultimately the relying
parties in most of the situations we want to support.  By this I mean that
we need to explain that the users must be shown the ages of the satuses
(stati?) of the certificates they're about to rely on, and they must be
given the opportunity to refresh that status if they desire.

OCSP only becomes viable with proper caching and user interaction. 
Otherwise, it's a tool without an instruction manual.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1



On Fri, 5 Dec 1997, Phillip M Hallam-Baker wrote:
> 
> Re Tim Moses <[e-mail]> comments concerning the alledged 'non
> scalability of OCSP'.
> 
> I have been reviewing Tim's comments concerning the 'scalability of OCSP'.
> First I note that Tim does not address scalability but the relative
> performance of OCSP and the Entrust approach under his chosen set of
> assumptions.
> 
> Scalability is about  whether an architecture limits the size of the problem
> that can be handled. e.g. resource requirements scale O(n^2)or worse or it
> assumes a big enough mainframe can be purchased.
> 
> OCSP supports a function call end clients make routinely: 'Is this
> certificate valid'. It allows the function 'check every certificate in my
> address book' to be supported cleanly. Unless you want to either handle CRLs
> in the client or route all traffic through a central bottleneck OCSP is the
> obvious approach.
> 
> To gain perspective on scaling issues I believe we should look at a billion
> certificates or more rather than Tim's million. At least two applications
> will involve this number of certificates:
> 
>     * Credit card processing
>     * Certificate based equities
> 
> Both these scenarios are much smaller than systems I have previously helped
> design, ZEUS and the Web. Simulation is the only way to prove viability of
> such systems. I see OCSP as a usefull tool in meeting such challenges which
> require a 'full toolbox'.
> 
>         Phill

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNIhJ4lrdFXNdDxPlAQEsFwL9GyGA7p9xeIBBiMYfkeVvqCfEGFHD71Ga
FdIDELmR42ksY7bjVlpuh0O7BuqvXBeV+Atx8EIV8TlrHFaWuZzxPSbyp93RoCr3
0FHsGlcoyRQsjaUZAMMi1g5LwWOkdrWX
=Sp+F
-----END PGP SIGNATURE-----




Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 11:48:12 -0700
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id JAA18156 for <[e-mail]>; Fri, 5 Dec 1997 09:39:30 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA28143 for <[e-mail]>; Fri, 5 Dec 1997 12:39:29 -0500 (EST)
Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA28139 for <[e-mail]>; Fri, 5 Dec 1997 12:39:29 -0500 (EST)
Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id MAA07636 for <[e-mail]>; Fri, 5 Dec 1997 12:36:20 -0500
Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id MAA06378; Fri, 5 Dec 1997 12:37:40 -0500
Date: Fri, 5 Dec 1997 12:37:40 -0500
From: [e-mail] (David P. Kemp)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: draft-ietf-smime-crs-00.txt
X-Sun-Charset: US-ASCII

Mike,
   With respect, I've admitted to you and others privately that I find
the *document describing* CMP which is now in Last Call to be overly
complex.  But I fail to understand why you refuse to make your proposal
compatible with the CMP protocol itself, which in it's minimal form,
is not that complex.


> There is a serious disconnect here which no amount of artful optional
> syntax will repair and we might as well admit it.

There is a disconnect in someone's understanding, perhaps mine.  But
IMHO the "artful optional syntax" is not an attempt to repair anything,
it is the fundamental design principle which enables one to start small
and add on later.  Stripped of everything optional, CMP can be
described in just a few lines:


    PKIMessage ::= SEQUENCE {
        header    PKIHeader,
        body      PKIBody  }

    PKIHeader ::= SEQUENCE {
        pvno      INTEGER,
        sender    GeneralName,
        recipient GeneralName }

    PKIBody ::= SEQUENCE {
        p10cr     [4] CertificationRequest }  -- PKCS#10 certification request*


Are you claiming that adding one integer, two names, and a couple of
nested SEQUENCEs to PKCS #10 is so much of a burden that S/MIME
developers, toolkit vendors, and CAs will be unable to accomplish it
within the next release cycle?

As Blake said, if there is something wrong with this tiny bit of
required CMP syntax, then suggest that it be fixed.  Otherwise, just
get about the business of writing your draft describing a minimal cert
request syntax in a manner that is compatible with CMP, instead of
insisting on a non-extensible alternative with no future growth path.


> The issues and forces are readily apparent.  If x% of the PKI-using
> community does something other than CMP for their own internal reasons,
> then at some value of x we must perform a reality check.  I would claim the
> current value of x far exceeds this threshold.

Reality check: 100% of browser vendors do not support TLS in their
current products.  Yet I don't see that being used as an argument claiming
that the IETF must write a Standards Track protocol that enshrines
SSL v3.0 as a permanent parallel alternative to TLS 1.0.  One Standard
is enough - implementations are always free to support as many additional
non-standard or de-facto standard options as business needs dictate.


-------------
* as an aside, I'll express my opinion that using the CMP "cr" message
  and eliminating the redundant "p10cr" message would also not be a
  major burden for developers, and would have the benefit of simplifying
  the codebase.  But in the spirit of compromise, I won't
  argue for that here. 



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 10:37:40 -0700
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id IAA04651 for <[e-mail]>; Fri, 5 Dec 1997 08:19:07 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id IAA16743; Fri, 5 Dec 1997 08:18:33 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA00912; Fri, 5 Dec 1997 08:18:32 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: <[e-mail]>
Subject: Re: [IETF-PKIX] OCSP v CRLs over HTTP
Date: Fri, 5 Dec 1997 11:28:59 -0500
Message-ID: <01bd019a$e3e26ba0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3

Re Tim Moses <[e-mail]> comments concerning the alledged 'non
scalability of OCSP'.

I have been reviewing Tim's comments concerning the 'scalability of OCSP'.
First I note that Tim does not address scalability but the relative
performance of OCSP and the Entrust approach under his chosen set of
assumptions.

Scalability is about  whether an architecture limits the size of the problem
that can be handled. e.g. resource requirements scale O(n^2)or worse or it
assumes a big enough mainframe can be purchased.

OCSP supports a function call end clients make routinely: 'Is this
certificate valid'. It allows the function 'check every certificate in my
address book' to be supported cleanly. Unless you want to either handle CRLs
in the client or route all traffic through a central bottleneck OCSP is the
obvious approach.

To gain perspective on scaling issues I believe we should look at a billion
certificates or more rather than Tim's million. At least two applications
will involve this number of certificates:

    * Credit card processing
    * Certificate based equities

Both these scenarios are much smaller than systems I have previously helped
design, ZEUS and the Web. Simulation is the only way to prove viability of
such systems. I see OCSP as a usefull tool in meeting such challenges which
require a 'full toolbox'.

        Phill








Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 10:06:49 -0700
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id HAA28797 for <[e-mail]>; Fri, 5 Dec 1997 07:30:28 -0800 (PST)
Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Fri, 5 Dec 1997 10:22:27 -0500
Message-ID: <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: LDAP v3 authentication
Date: Fri, 5 Dec 1997 10:22:23 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD0167.AF9308B0"

Let's make sure PKIX requirements (assuming we have some) are input to
this effort.
------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[e-mail]       Tel: [phone] 
http://www.entrust.com          Fax: [phone] 
         Orchestrating Enterprise Security


>----------
>From: 	[e-mail][SMTP:[e-mail]]
>Sent: 	December 5, 1997 9:23 AM
>To: 	[e-mail]
>Subject: 	LDAP is approved!
>
> 
>After a long discussion, the IESG has decided to approve LDAPv3.
>That's good news - BUT:
>
>The IESG also requested (as you can see) that the spec be supplemented
>as soon as possible with a Proposed Standard for mandatory-to-implement
>authentication in LDAPv3, so that one could approach the prospect
>of an Internet-accessible read-write directory with a joyous heart
>rather than with trepidation and noninteroperability.
>
>Congratulations - and let's start working!
>
>               Harald A
>
>

From: The IESG <[e-mail]>
To: Unknown User <Unknown User>
Cc: RFC Editor <[e-mail]>, Internet Architecture Board
	 <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Protocol Action: Lightweight Directory Access Protocol (v3) to Proposed Standard
Date: Fri, 5 Dec 1997 08:14:50 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit



The IESG has approved the following Internet-Drafts as Proposed
Standards:

 o Lightweight Directory Access Protocol (v3)
	 <draft-ietf-asid-ldapv3-protocol-09.txt>

 o Lightweight Directory Access Protocol (v3):  Attribute Syntax
   Definitions
	<draft-ietf-asid-ldapv3-attributes-08.txt>

 o Lightweight Directory Access Protocol (v3): UTF-8 String
   Representation of Distinguished Names
	<draft-ietf-asid-ldapv3-dn-04.txt>

 o The String Representation of LDAP Search Filters 
	<draft-ietf-asid-ldapv3-filter-03.txt> 

 o The LDAP URL Format <draft-ietf-asid-ldapv3-url-04.txt> 

 o A Summary of the X.500(96) User Schema for use with LDAPv3 
	<draft-ietf-asid-ldapv3schema-x500-04.txt> 

 These documents are the product of the Access, Searching and Indexing
 of Directories Working Group.  The IESG contact person(s) are Harald 
 Alvestrand & Keith Moore.


Technical Summary
 
   The protocol described in this document is designed to provide access
   to directories supporting the X.500 models, while not incurring the
   resource requirements of the X.500 Directory Access Protocol (DAP).

   It is an improvement over the earlier LDAP version 2 that includes
   consistent character set handling, cleaner security, the possibility
   of handing back referrals to other servers, and extensibility.


Working Group Summary

   The ASID WG had rough consensus on this set of documents, the
   roughness being mostly in the area of what functionality to include
   in or exclude from the core protocol.
   There was consensus on the selection presented here.

Protocol Quality

   The protocol has been reviewed for the IESG by Chris Weider and
   Harald Alvestrand. Multiple implementations exist of both clients
   and servers.


Note To RFC Editor:

The IESG requests the following note be included:

IESG NOTE: This document describes a directory access protocol that
provides both read and update access.  Update access requires secure
authentication, but this document does not mandate implementation
of any satisfactory authentication mechanisms.

In accordance with RFC 2026, section 4.4.1, this specification is
being approved by IESG as a Proposed Standard despite this limitation,
for the following reasons:

a. to encourage implementation and interoperability testing of
   these protocols (with or without update access) before they
   are deployed, and

b. to encourage deployment and use of these protocols in read-only
   applications.  (e.g. applications where LDAPv3 is used as
   a query language for directories which are updated by some
   secure mechanism other than LDAP), and

c. to avoid delaying the advancement and deployment of other Internet
   standards-track protocols which require the ability to query, but
   not update, LDAPv3 directory servers.

Readers are hereby warned that until mandatory authentication
mechanisms are standardized, clients and servers written according
to this specification which make use of update functionality are
UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.

Implementors are hereby discouraged from deploying LDAPv3 clients
or servers which implement the update functionality, until a
Proposed Standard for mandatory authentication in LDAPv3 has been
approved and published as an RFC.






Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 09:02:09 -0700
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id GAA25093 for <[e-mail]>; Fri, 5 Dec 1997 06:54:13 -0800 (PST)
Received: tid JAA09177; Fri, 5 Dec 1997 09:51:14 -0500
Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Fri, 5 Dec 1997 09:48:06 -0500
Message-ID: <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
From: Peter Whittaker <[e-mail]>
To: "'IETF PKIX'" <[e-mail]>
Cc: "'Bancroft Scott'" <[e-mail]>, "'Harald T Alvestrand'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>, Sharon Boeyen <[e-mail]>, Carlisle Adams <[e-mail]>, Tim Moses <[e-mail]>
Cc: "'Phillip H. Griffin'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Hoyt Kesterson'" <[e-mail]>
Subject: Character sets in PKIX and X.509 (RE: [IETF-PKIX] Objections to IPKI3CMP charset handling)
Date: Fri, 5 Dec 1997 09:48:04 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On November 21, Harald Alvestrand posted to this listed comments on
character set handling in PKIX.  His objections centered around the
definition of PKIFreeText as a CHOICE between IA5String and BMPString:
this was seen as problematic for the following reasons:

1) It is not compatible with current thinking on charset policy, as
specified in draft-alvestrand-charset-policy-02.txt, currently in Last
Call for BCP.

2) The BMPString encoding of 10646 is a particularly bad choice, since
ISO has stated intent of adding characters to 10646 outside the BMP
range, which cannot be represented there. (BMPString is not the same
thing as UTF-16, another ISO proposal)

3) The use of CHOICE for this important construct makes "shorthand
implementation" handling only one branch of the CHOICE all too likely.

Another area of concern was the rules currently in the PKIX I-Ds
concerning how to decide what character set to use (use Printable if the
character fits, if it doesn't, use BMP if it fits, if it doesn't use
Universal;  they're longer than this, but you get the idea).  One major
concern here was why a CA should be constrained to follow those rules
when its operating environment requires the use of BMP or Universal,
with strings encodable in Printable being but a minority.

Harald's post lead to a debate and exchange of information, mostly
off-line, that came to involve Bancroft Scott, the ISO ASN.1 Rapporteur
(chair of the ASN.1 WG), Hoyt Kesterson, the ISO X.500 Rapporteur,
Harald, Phillip Griffin, Carlisle Adams, and others.

>After some debate and sharing of information, it was pointed out that
>UTF8String is now a recognized ISO character set.  It was suggested that this
>character set be used within PKIX when defining string data and that it be
>added to the DirectoryString choice in X.500.  The X.500 Rapporteur agreed to
>do so.  This means that we now have an efficient character set - efficient in
>terms of encoding - capable of reprensenting every human language, and
>possibly a few extra-terrestrial ones (to use the example provided by the
>ASN.1 Rapporteur).

The implication of this is that in the near future, though not
immediately, UTF8String will be a valid member of the DirectoryString
choice.  This should simplify the lives of implementors as they need
only deal with a single character set, UTF8String.

Harald then made the following suggestions:

>I distrust solutions which change other people's specifications.
>
>In the ideal world, ISO/ITU-T would add UTF8String to DirectoryString,
declare all other variants to be "for backwards compatibility only", and
we would halt all work with certificates until the world implemented
>that :-)
>
>In this imperfect world, with people overeager to push products "whether it
>works or not", it seems to me that the best thing to do is:

>- Declare that PKIX sees the future as UTF8String
>- Declare that PKIX will use UTF8String and only UTF8String wherever possible
>(there's no reason for either PrintableString or IA5String when you have
>UTF8String; the only difference is limits on the charset, which can also be
>expressed as a constraint on the UTF8String)
- Refer to X.509 as an external specification, and state that you expect
>to see UTF8String here in the next version, once ISO/ITU gets its work done.
>- Encourage use of BMPString as long as UTF8String is illegal (it's the type
>that gives the least problems with conversions <-> UTF8String)
>
>Seems reasonable?
>
>                     Harald A
>
>PS: The reason not to just modify X.509 is that occasionally, a PKIX
>certificate will be handed to an X.509-only device. Ouch....

>Further to Harald's suggestions, I would add the following:  that PKIX
>applications MUST be prepared to receive UTF8String, even in X.500-defined
>data, and that PKIX applications MAY use UTF8String in X.500-defined data,
>though they MUST be able to support BMPString as an alternative in order to
>interoperate with non-PKIX X.509 applications (presuming that this is
>important).

These allow us to redefine PKIFreeText as UTF8String and only as
UTF8String.  Furthermore, with appropriate language, we can specify the
use of UTF8String everywhere, with a fall-back to BMPString when
interoperability with non-IPKI applications is required, simplifying the
character set choice rules.

>If so desired, I can supply all of the relevant mail messages (though not in
>a nice digest format or anything like that, my mail system does not provide
>that service :-<).

One issue that has been raised about the use of UTF8String is the
question of what level of ASN.1 support it requires ('88, '94, '9x with
x > 4, '2x?), and how it affects current ASN.1 compilers.   UTF8String
may be the right thing to do, but may pose challenges in this area
(compounding the problem of widespread use of ASN.1 1988 throughout IETF
work, despite the superiority and clarity of ASN.1 1994).

Thoughts, comments, objections?

>pww
>



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 5 Dec 1997 00:59:39 -0700
Received: from ivy.tc.pw.com (ivy.tc.pw.com [131.209.1.4]) by Tandem.com (8.8.8/2.0.1) with ESMTP id WAA18578 for <[e-mail]>; Thu, 4 Dec 1997 22:59:30 -0800 (PST)
From: [e-mail]
Received: by ivy.tc.pw.com; id WAA03923; Thu, 4 Dec 1997 22:57:35 -0800 (PST)
Received: from cactus.tc.pw.com(131.209.7.48) by ivy.tc.pw.com via smap (3.2) id xma029481; Thu, 4 Dec 97 22:49:08 -0800
Received: (from notes@localhost) by cactus.tc.pw.com (8.8.4/8.7.3) id XAA19702 for [e-mail]; Thu, 4 Dec 1997 23:00:46 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail]
Date: Thu, 4 Dec 97 16:29:24 EST
Subject: Re: digitalSignature vs. nonRepudiation

Bob, Mike,
 I agree completely with the importance of obeying critical extensions. But I 
also believe that there will be "rogue applications" that may or may not handle 
these extensions properly dependent on the specific application. For example, 
if I have a certificate whose policy is explicitly for signing user 
certificates, someone may develop an application that allows me to use that 
certificate for applying for a credit card exclusively for CAs. The "relying 
party" in this case accepts the risk in using that certificate despite the 
policy under which it was issued. If used improperly by these rogue 
applications, Mike is correct in saying that all CA (or other) liability is 
relieved. Hopefully, the relying party would have a difficult fight in court if 
they wanted to blame the CA who issued that certificate. The point is that we 
can only write the specifications, we cannot enforce them.

Cheers,
Dave Oshman

Price Waterhouse LLP
Electronic Commerce/Internet Practice
>Date:    Wed, 3 Dec 1997 08:34:05 -0700
>From:    Mike Smith <[e-mail]>
>Subject: Re: digitalSignature vs. nonRepudiation
>As usual, Bob, I find myself agreeing with your statements.
>
>A certificate is issued under a certain set of authority policies.  If someone 
wishes >to rely on a certificate issued under those policies, then the software 
they use must >be able to process all of the critical extensions established 
under that policy or >not honor the certificate.
>
>If someone does accept a certificate or signature issued with critical 
extensions >that are ignored or interpreted other than the intent of the 
issuing CA, then, it is >my belief, the reliant party (and, possibly the entity 
that modified the code to >accept or ignore the critical extensions) has just 
relieved the CA of any and all >liability regarding that critical extension 
and, quite possibly, the whole >certificate's issued purpose.
>
>Michael
>
>>> Bob Jueneman <[e-mail]> 12/02/97 11:12AM >>>
>Sharon and David,
>
>My tongue in cheek suggestion that we deprecate the keyUsage field was made
>as a result of my confusion and exasperation in trying to sort though all of
>these different issues.  But if we can't agree on some relatively simple
>meaning, I submit that using the fields will actually be WORSE than
>deprecating them, for one person will think that they mean one thing, and
>another person will interpret them differently.
>
>What good does it do to mark an attribute as critical, if the semantics are
>as undefined or ambiguous as these are?
>
>And to bring up a somewhat different ubject that I mentioned before, but
>never got closure on, I think that it is completely UNACCEPTABLE to say that
>if some particular application does not have, understand, or chose to
>implement a security policy, it should be free to simply ignore the critical
>marking on a Policy OID constraint. This simply turns the definition of
>critical on its head.  The critical usage is provided primarily to protect
>the CA and/or the subject of the certificate from unreasonable reliance on
>the certificate, and to provide a means for IT administrators to centrally
>control what kinds of policies are to be enforced.
>
>Bob



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 4 Dec 1997 21:22:43 -0700
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id TAA23274 for <[e-mail]>; Thu, 4 Dec 1997 19:24:57 -0800 (PST)
From: [e-mail]
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id TAA04572; Thu, 4 Dec 1997 19:24:25 -0800 (PST)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id TAA08537; Thu, 4 Dec 1997 19:24:21 -0800 (PST)
Message-Id: <3.0.32.19971204192423.009524a0@mail>
X-Sender: mmyers@mail
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 04 Dec 1997 19:24:25 -0700
To: [e-mail], [e-mail]
Subject: RE: draft-ietf-smime-crs-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Blake,

At 02:53 PM 12/4/97 -0800, you wrote:
>>On Tuesday, December 02, 1997 7:07 AM, [e-mail]
>>[SMTP:[e-mail]] wrote:
>>> 
>>> If this working group takes on this task, (I think it would be more
>>> appropriate within the PKIX WG, but like Mike, don't have any strong
>>> objection to pursuing it here - many of the participants are members
>>> of both groups), then it MUST ensure that the result is compatible
>>> with PKIX, not an independent and incompatible protocol based on
>>> straight unmodified PKCS#10.
>>
>>I agree.  This whole thing has caught me kind of off guard as a behind
>>the scenes effort.  I am still trying to sort out the spec and figure
>>out what exactly can't be accomplished with existing protocols
>>(specifically CMP) by constraining those protocols to fit in our
>>profile, and/or modifying them to fix any shortcomings that make them
>>unsuitable for our profile (non-persistent connections, etc.)

Well, the draft *was* available for public review and comment since August.
 Following Munich, those who were interested in seeing the initiative move
forward provided input.  I would have preferred to develop a broader
consensus during this summer's workshops, but there quite obviously wasn't
time given the more fundamental questions facing the SMIME developer
community.


>>
>>> Note the key last sentence - "an interpretation of PKIX-3 messages over
>>> PKCS7".  This means that any usage of PKCS#10 certificate requests MUST
>>> be in the form of PKIX-3 "p10cr" messages, in order to allow implementors
>>> to quickly develop "Basic functionality" certificate request messages
>>> based on existing technology, while remaining compatible with, and
allowing
>>> smooth migration to, the "Full functionality" (and more difficult to
>>> implement) CMP.
>>
>>I agree, and this option was discussed in an earlier thread also I
>>believe.
>>
>>> If this WG adds a certificate request work item to it's charter, it
>>> should be clearly stated that the result must be compatible with
>>> PKIX CMP, not an independent, non-interoperable syntax based on raw
>>> PKCS#10.
>>
>>If there are problems with CMP then we should fix them.  Coming up with
>>a new protocol is fun, but I think it fragments the effort.


I wouldn't necessarily call this fun.  I'm not fond of waving the reality
flag but it's something that needs to be done.  There is a serious
disconnect here which no amount of artful optional syntax will repair and
we might as well admit it.


>>I will read
>>the CRS spec more closely to find out what the differences are, but I
>>think that CMP can be fixed to satisfy our needs.
>>From my understanding, CMP is in last call, but I really think we should
fix it
>>right, and I think that "right" means fixing CMP if it is broken and
>>can't be used for S/MIME.

I proposed in Munich, with Tim Polk's support, a restructuring of CMP that
was vectored towards accomodating the consensus of all PKIX members.  It
was felt however that further delay of CMP towards Last Call would not
speak well of the WG.  Fine, that's the consensus and consensus rules.
However, a successful Last Call does not eliminate the market, partner and
customer needs I and others face daily.  It merely ratifies the content of
a document.

At this point I'm much more concerned about whether that document gets
reduced to practice in a scale equivalent to the SMIME and SSL efforts.  As
an early reader of Part 3, I was hopeful that would be the case.  Given my
current perspective, I am not at all confident this will occur in any way
close to the scale we thought it would.

>>There may certainly be issues and forces at work here that I don't
>>understand, and someone should feel free to correct me if I am too
>>unenlightened to see the value in having a separate incompatible
>>specification instead of a profile constraint on (potentially modified)
>>PKIX CMP.

The issues and forces are readily apparent.  If x% of the PKI-using
community does something other than CMP for their own internal reasons,
then at some value of x we must perform a reality check.  I would claim the
current value of x far exceeds this threshold.

The fact is version N+1 of a software products contains incremental
improvments over version N; this includes PKI clients.  No one has managed
to convince me this fundamental rule of product development will be ignored
simply to accomodate CMP where alternative solutions are provably working
and interoperating.  Despite CMP's Last Call, I'm compelled to inform the
working group that it fails to address the needs of a large percentage of
the PKI-development community.  I and a few others have a suggestion on how
to deal with this issue.

With respect,
Mike





Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 4 Dec 1997 20:25:31 -0700
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id SAA16996 for <[e-mail]>; Thu, 4 Dec 1997 18:24:07 -0800 (PST)
From: [e-mail]
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id SAA03596; Thu, 4 Dec 1997 18:23:35 -0800 (PST)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id SAA06474; Thu, 4 Dec 1997 18:23:33 -0800 (PST)
Message-Id: <3.0.32.19971204182335.009135a0@mail>
X-Sender: mmyers@mail
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 04 Dec 1997 18:23:35 -0700
To: [e-mail]
Subject: OCSP Considerations
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Bob,

Actually, you are making headway, as have Richard Ankey, Carlisle, Ambarish
and others.  The fact is that when the sudden rush of interest and comment
on OCSP started pouring in--both on-list and off-list--I saw the whole
thing going down a long and slippery slope without due consideration given
to fundamental requirements.

I still firmly believe that simplicity is a fundamental requirement.  That
said, having now had the last few days to go back and digest the recent
input, I'm quite certain a specification of OCSP can be crafted that
strikes an acceptable compromise among the various positions.  For the
benefit of those who may not be able to make it to the IETF next week,
here's a strawman proposal:

1. Re-craft the request & response syntax (still non-ASN.1) to more
effectively enable extensibility without introducing implementation
complexity.  The current syntax is simply too rigid to do extensibility
cleanly.

2. Add an optional policy OID in alignment with the Timestamping proposal.
I would still recommend we go cautiously here.  Matching an OID should be
fairly straightforward for environments with a need; algorithmic models of
policy a la SPKI may never see the light of day.

3. Add an optional nonce for replay detection.  This could be included
within the scope of the extensibility mechanism.  I've never needed
convincing that nonces are good, but we do need to ensure that the final
OCSP solution enables one to make a choice whether or not to take full
advantage of the existing Internet infrastructure.

Regarding SSL, I agree with your observeration.  OCSP is signed content for
exactly the reason you note.  Technically, we should recognize however that
there exists nothing in the OCSP protocol model which inhibits use of SSL
for who wish to do so.

Mike


At 11:21 AM 12/3/97 -0700, you wrote:
>>It seems that the main purpose of having signed responses in OCSP
>>is to authenticate the responder.
>>
>>Would it be useful, and perhaps simplify things, to permit SSL/https
>>to be used in the protocol instead of requiring signed responses over
>>http?
>
>I don't think so.  Although I'm not making much headway in trying to get
>OCSP to be more responsive to the nonrepudiation requirement, authenticating
>the responder via SSL would not provide any lingering proof of the the
>certificate's status.
>>
>>I am assuming here that the responder is tightly coupled to the CA.
>>If the responder's site certificate is revoked then the responder
>>itself would have to get disabled or updated by the CA.
>>
>>==========================================
>>Dan Laska
>>Frontier Technologies Corp.
>>Email: [e-mail]
>>==========================================
>
>Bob
>
>




Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 4 Dec 1997 17:37:23 -0700
Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id PAA19030 for <[e-mail]>; Thu, 4 Dec 1997 15:06:58 -0800 (PST)
Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Thu, 04 Dec 1997 12:00:50 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 04 Dec 1997 12:00:22 -0700
From: Bob Jueneman <[e-mail]>
To: [e-mail], [e-mail]
Subject: PKIX naming conventions and schema
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline

Michael, X.500 per se does not define ANY schema for DNs. That is one of the
things we were trying to do in the late lamented NADF.

X.520 does provide some oxymoronic "useful" definitions, that most people
(including the NADF) found were not in fact very useful, but nothing in
X.500, X.509, or so far in PKIX would either restrict or require the use of
any particular attribute, either public or proprietary, as an RDN component
of a DN.

As I recently commented on the spki list, there is nothing in any of these
standards that would prevent me from including a 1 gigabit MPEG movie of me
playing with my cat as one of the RDN components of the DN in my
certificate. The fact that doing that would be rather brain-dead, would
probably blow up the CA software that is issuing the certificate, and would
severely limit interoperability with browsers and other certificate-aware
software, not to mention LDAP and the search and browse efficiency of
various directory implementations, is sufficient reason why we should
attempt to profile a set of acceptable RDN attributes.

I am somewhat less concerned about profiling subjectAltname attribute
schemas, just because they were provided as a form of escape clause, and we
don't yet know which ones will be useful. It isn't that it won't eventually
be needed, just that it is premature at present. In particular, it isn't yet
apparent whether subjectAltnames will be browsed for in conventional
directories where schema issues are particularly important.

In checking the definition of the DN is part01, I was interested to find in
4.1.2.6 the statement, "Where it is non-null, the subject name field shall
contain an X.500 distinguished name (DN). the DN must be unique for each
subject entity certified by the one CA as defined by the issuer name field.
(A CA may issue more than one certificate wioth the same DN to the same
subject entity.)"

I interpret that to mean that if you really want to have a globally
unambiguous DN, for example to include in your global X.500 directory, it
may be necessary to invent a DN that is a composite of the issuer name and
the subject name, and insert that name rather then the DN in the certificate
in the directory.  That of course would be rather awkward -- it would be
preferable if that kind of name subordination were included in the
certificate DN originally.

I understand the difficuty of coordinating between CAs to ensure globally
unique names, but allowing names to be local to a CA without specifically
indicating that would seem to have to have some serious consequences..

I question whether this is really what we want.  If it is not possible to
use a DN that is inherently unique, then either name subordination or some
other technique should be used to specifically include the CA in the scope
of the name. Alternatively, some unique CA OID can be used in combination
with a subjectUniqueID and included as a component of a DN to make the DN
globally unambiguous.

This one sentence in 4.1.2.6 threatens to have serious implications with
respect to both existing and proposed legislation (which generally assumes
that a DN in a certificate is globally unambiguous), as well as potentially
hindering interoperability with various directory implementations, including
LDAP.

I think we ought to revisit this issue as part of the schema discussions
forthcoming  at the Washington meeting.  I wish I could be there.

Bob


>>> Mike Smith <[e-mail]> 12/03 8:36 AM >>>
Maybe I'm missing something with the X.500 compatibility issue and X.509
certifcates.  I thought that, with version 3, X.500 is just one schema tht
the X.509v3 certificate processing systems should be "backward compatible"
with.

Michael

                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
            



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 4 Dec 1997 17:43:52 -0700
Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id PAA20839 for <[e-mail]>; Thu, 4 Dec 1997 15:18:12 -0800 (PST)
Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Thu, 04 Dec 1997 12:18:07 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 04 Dec 1997 12:17:41 -0700
From: Bob Jueneman <[e-mail]>
To: [e-mail], [e-mail]
Subject: Moot issues
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline

Carlisle,
>
>My thesaurus entry for "moot" says that the following are synonyms:
>controversial, contestable, debatable, arguable, disputable,
>questionable, dubious, disputed, doubtful.

You need a better thesaurus.

The most common usage of the word is as given in the American Heritage
Dictionary:

2 a. (Law) Without legal significance, through having been previously
decided or settled. 

b. Of no practical importance.

Bob
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                   



Received: from Tandem.com (192.216.221.8) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 4 Dec 1997 16:25:04 -0700
Received: from coastek.com (mail.coastek.com [209.1.44.155]) by Tandem.com (8.8.8/2.0.1) with SMTP id NAA08184 for <[e-mail]>; Thu, 4 Dec 1997 13:59:32 -0800 (PST)
Received: from Coastek.COM by coastek.com (SMI-8.6/SMI-SVR4) id NAA16704; Thu, 4 Dec 1997 13:54:08 -0800
Message-ID: <[e-mail]>
Date: Thu, 04 Dec 1997 14:01:36 -0800
From: Todd Glassey <[e-mail]>
Organization: Coastek Infosys, Inc.
X-Mailer: Mozilla 4.03 [en] (WinNT; I)
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>, [e-mail], [e-mail], [e-mail]
CC: IETF PKIX <[e-mail]>, Roger Romano <[e-mail]>
Subject: Re: [IETF-PKIX] Adding Certified NTP as a possible standard forportable trust innetworking systems
References: <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
Content-Type: multipart/mixed; boundary="------------95B5F9915901895501C2E5EE"

Robert,
thanks for replying so promptly and pardon my long winded reply but this is a
technology I am passionate about.

The intent behind the appliance style NTP based timestamp/concept is that it creates a
politically correct or neutral mechanism to have certified time available. What I mean
is available for all timestamping use models within the vertical WG's... Sort of a
horizontal enablement for the vertical WG's.

The reasoning is that it is not only PKIX and SPKI WG's that need certifiable
timestamping, but also CAT, AFT, and RoamOps as well will make use of reliable
timestamps. They can use these for their policy and service standards as well as
connection management and event signaling. In addition, certified time has value in
Telecom for backbone synchronization and other networking operations functions. In
electronic Commerce as a whole it is invaluable.

Now, we in the PKIX-WG are clear on the need for Certified Timestamping in transaction
processing and especially nonrepudiated event logging, hence the PKIX #7 timestamping
extensions. For us these technologies are the basis of a way to convey portable-trust
and proofing services. These services by the way, [IMHO] are the gating items to
getting the business-to-business folks and the Fed's to accept our solutions!. There is
also another reason for settling on a NTP style stamping infrastructure. This is
because it is useful to all. This means that we won't need twenty different solutions
for sources of certified time to answer requirements from the varied use models that
are emerging all throughout the IETF. Our reasoning and intent for this is to pre-empt
the multitude of independent standards that will rise from each WG doing it's own
certified time source and timestamp infrastructure...

So many times we have created methods so particular to one use model that when a new
requirement emerged we redesigned the wheel from scratch thus complicating the process
ad infinitum. Certified NTP Timestamping is an attempt to do the right thing. To create
a public resource specific to all of us in the PKI arena that also enables our brethren
in the other WG to leverage our creativity.

Thanks for letting me soapbox and see you in DC.

Todd

Robert Zuccherato wrote:

> Hi Todd;
>
> Some of us in the PKIX working group have been working on a time stamp
> protocol for a few months now.  Our revised draft is available at:
> ftp://ds.internic.net/internet-drafts/draft-adams-time-stamp-00.txt
> The working group will be deciding (hopefully) at the upcoming meeting
> whether or not this work belongs within PKIX.
>
> Robert Zuccherato
> Entrust Technologies
>
> >----------
> >From:  Todd Glassey[SMTP:[e-mail]]
> >Sent:  Thursday, December 04, 1997 12:40 PM
> >To:    [e-mail]
> >Subject:       [IETF-PKIX] Adding Certified NTP as a possible standard forportable
> >trust innetworking systems
> >
> ><<File: vcard.vcf>>
> >Hi all,
> >I want to propose the consideration of
> >using a certified NTP timestamp as the
> >basis of a portable trust model and
> >nonreputiead network timing. We and many
> >others in the associated IETF WG's have
> >long known the value of digital
> >timestamps for fixing a point of
> >reference to an event. Consider the
> >value if the source of the timestamp and
> >it's facility can be verified and
> >proffered as a certified network entity.
> >This is the birth of truly nonrepudiated
> >events and their logging.
> >
> >This capability brings a whole new light
> >to the world of certificates and
> >networking policy. Imagine email with
> >built-in timestamping and nonrepudiated
> >logging. Especially if combined with the
> >automated reply services now proposed
> >for SMTP. This timestamping technology
> >goes a tremendous way to enabling the
> >collapsing of human commerce models into
> >the digital domain.
> >
> >The use models of the NTP supplied
> >timestamps will fit in all groups
> >standards efforts, but especially are of
> >interest to the PKIX WG. These
> >timestamping extensions without any real
> >sweat enable the PKIX #7 Time Extensions
> >directly. Thus the settling on certified
> >NTP as the basis of the timestamp source
> >creates a horizontal technology that is
> >directly applicable to a number of IETF
> >and other Standards Working Groups
> >including those of ANSI, The ABA, and
> >the SEC. All in all it makes sense for
> >everyone in our mind.
> >
> >To this end, Coastek [Glassey and
> >McNeil] and David Mills have
> >collaborated on an extended NTP Spec and
> >an Interoperability Spec for Coastek's
> >variant of SNTP (since most financial
> >systems will mandate stratum-1 sources
> >for security reasons). This first draft
> >is on-file with the IETF as and
> >Individual Contributor at the following
> >URL:
> >ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-00.txt
> >
> >The Coastek specific use models draft
> >and a third draft on portable-trust and
> >logging systems will follow in the next
> >two weeks. We apologize for the lateness
> >of these drafts as we intended to have
> >them available pre-meeting but you know
> >how the last minute crunch is.
> >
> >
> >Todd Glassey
> >
> >



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

Attachment converted: Lutefisk:vcard.vcf 2 (TEXT/R*ch) (0001DB89)



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 4 Dec 1997 10:51:19 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA14734; Thu, 4 Dec 1997 09:49:01 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 4689 for [e-mail]; Thu, 4 Dec 1997 09:48:14 -0800
Received: from coastek.com (mail.coastek.com [209.1.44.155]) by Tandem.com (8.8.8/2.0.1) with SMTP id JAA23899 for <[e-mail]>; Thu, 4 Dec 1997 09:38:11 -0800 (PST)
Received: from Coastek.COM by coastek.com (SMI-8.6/SMI-SVR4) id JAA14098; Thu, 4 Dec 1997 09:32:45 -0800
X-Mailer: Mozilla 4.03 [en] (WinNT; I)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------9735E8D8977AA4CCD8A6913A"
Message-ID:  <[e-mail]>
Date:         Thu, 4 Dec 1997 09:40:13 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Todd Glassey <[e-mail]>
Organization: Coastek Infosys, Inc.
Subject:      [IETF-PKIX] Adding Certified NTP as a possible standard for portable trust in networking systems
Comments: To: [e-mail], [e-mail], [e-mail]
Comments: cc: [e-mail], [e-mail], [e-mail], Dave Mills <[e-mail]>
To: [e-mail]

Hi all,
I want to propose the consideration of
using a certified NTP timestamp as the
basis of a portable trust model and
nonreputiead network timing. We and many
others in the associated IETF WG's have
long known the value of digital
timestamps for fixing a point of
reference to an event. Consider the
value if the source of the timestamp and
it's facility can be verified and
proffered as a certified network entity.
This is the birth of truly nonrepudiated
events and their logging.

This capability brings a whole new light
to the world of certificates and
networking policy. Imagine email with
built-in timestamping and nonrepudiated
logging. Especially if combined with the
automated reply services now proposed
for SMTP. This timestamping technology
goes a tremendous way to enabling the
collapsing of human commerce models into
the digital domain.

The use models of the NTP supplied
timestamps will fit in all groups
standards efforts, but especially are of
interest to the PKIX WG. These
timestamping extensions without any real
sweat enable the PKIX #7 Time Extensions
directly. Thus the settling on certified
NTP as the basis of the timestamp source
creates a horizontal technology that is
directly applicable to a number of IETF
and other Standards Working Groups
including those of ANSI, The ABA, and
the SEC. All in all it makes sense for
everyone in our mind.

To this end, Coastek [Glassey and
McNeil] and David Mills have
collaborated on an extended NTP Spec and
an Interoperability Spec for Coastek's
variant of SNTP (since most financial
systems will mandate stratum-1 sources
for security reasons). This first draft
is on-file with the IETF as and
Individual Contributor at the following
URL:
ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-00.txt

The Coastek specific use models draft
and a third draft on portable-trust and
logging systems will follow in the next
two weeks. We apologize for the lateness
of these drafts as we intended to have
them available pre-meeting but you know
how the last minute crunch is.


Todd Glassey

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

Attachment converted: Lutefisk:vcard.vcf (TEXT/R*ch) (0001DB80)



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 4 Dec 1997 10:10:53 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA09857; Thu, 4 Dec 1997 09:05:10 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 4628 for [e-mail]; Thu, 4 Dec 1997 09:04:36 -0800
Received: from ns.ietf.org (ietf.org [132.151.1.19]) by Tandem.com (8.8.8/2.0.1) with ESMTP id IAA14844 for <[e-mail]>; Thu, 4 Dec 1997 08:54:34 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA20488; Thu, 4 Dec 1997 11:54:29 -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <[e-mail]>
Date:         Thu, 4 Dec 1997 11:54:29 -0500
Reply-To: [e-mail]
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: [e-mail]
Subject:      [IETF-PKIX] I-D ACTION:draft-ietf-pkix-ipki-ecdsa-00.txt
Comments: To: [e-mail]
To: [e-mail]

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

        Title           : Internet X.509 Public Key Infrastructure
                          Representation of Elliptic Curve
                          Digital Signature Algorithm
                          (ECDSA) Keys and Signatures in
                          Internet X.509 Public Key
                          Infrastructure Certificates
        Author(s)       : D. Johnson, L. Bassham, W. Polk
        Filename        : draft-ietf-pkix-ipki-ecdsa-00.txt
        Pages           : 9
        Date            : 03-Dec-97

   This is the first draft of a profile for specification of Elliptic
   Curve Digital Signature Algorithm (ECDSA) keys in Internet Public Key
   Infrastructure X.509 certificates. Please send comments on this
   document to the [e-mail] mail list.


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

Internet-Drafts directories are located at:

        Africa: ftp.is.co.za

        Europe: ftp.nordu.net
                ftp.nis.garr.it

        Pacific Rim: munnari.oz.au

        US East Coast: ds.internic.net

        US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:      [e-mail].  In the body type:
        "FILE /internet-drafts/draft-ietf-pkix-ipki-ecdsa-00.txt".

NOTE:   The mail server at ds.internic.net 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]>

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get [IETF-PKIX] I-D ACTION-draf (EuSn/CSOm) (0001DB6F)
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ipki-ecdsa-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki-ecdsa- (AURL/Arch) (0001DB70)
Content-Type: text/plain
Content-ID:     <[e-mail]>




Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 4 Dec 1997 00:59:09 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id XAA07127; Wed, 3 Dec 1997 23:56:22 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 4498 for [e-mail]; Wed, 3 Dec 1997 23:55:41 -0800
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id XAA18259 for <[e-mail]>; Wed, 3 Dec 1997 23:45:39 -0800 (PST)
Received: from xcert.com (localhost [127.0.0.1]) by crack.x509.com (8.8.7/8.8.7) with ESMTP id XAA10848 for <[e-mail]>; Wed, 3 Dec 1997 23:39:05 -0800 (PST)
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
References: <01bd0003$d48304a0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 23:16:08 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: "Patrick C. Richard" <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [e-mail]

Dan Laska wrote:
>
> It seems that the main purpose of having signed responses in OCSP
> is to authenticate the responder.

I disagree. IMHO, the main purpose is to have a non-repudiable receipt
of status provision, that can be used to attest to an attempt to
reasonably check the status of a certificate.


>
> Would it be useful, and perhaps simplify things, to permit SSL/https
> to be used in the protocol instead of requiring signed responses over
> http?

This would not acheive the above.

>
> I am assuming here that the responder is tightly coupled to the CA.
> If the responder's site certificate is revoked then the responder
> itself would have to get disabled or updated by the CA.

This doesn't take into account multiple responder scenarios...

nor the instance where the OCSP provider has multiple certificates


>
> ==========================================
> Dan Laska
> Frontier Technologies Corp.
> Email: [e-mail]
> ==========================================

-Pat
--
Patrick C. Richard - [e-mail]
Public Key Available via LDAP

"All informational objects are candidates for PKI-based ACLs."
       - yhe



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 14:46:00 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id NAA22035; Wed, 3 Dec 1997 13:38:33 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 3814 for [e-mail]; Wed, 3 Dec 1997 13:38:04 -0800
Received: from mailhub.nc.com ([e-mail] [207.88.25.3]) by Tandem.com (8.8.8/2.0.1) with SMTP id NAA24520 for <[e-mail]>; Wed, 3 Dec 1997 13:28:02 -0800 (PST)
Received: (from proxy@localhost) by mailhub.nc.com (8.6.12/8.6.9) id NAA26664 for <[e-mail]>; Wed, 3 Dec 1997 13:28:02 -0800
Received: from pm3a-7.nc.com(172.20.129.7) by mailhub.nc.com via smap (V2.0) id xma026652; Wed, 3 Dec 97 13:27:43 -0800
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 13:25:11 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Luis Valente <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [e-mail]
In-Reply-To:  <01bd0028$1fd0a060$[e-mail]>

At 03:14 PM 12/3/97 -0500, you wrote:
>>I'm having trouble figuring out what exactly you mean by your last
>>sentence above.  Are you suggesting that if the sender and receiver are
>>under the same CA then non-repudiation cannot really be achieved?  Any
>>clarification would be helpful...
>
>
>I said 'authority', not 'certificate authority' and used it in the context
>of 'controlled by'. If I own and operate two machines at different locations
>and believe the machines to be equally trustworthy the value of ensuring
>that a communication is non repudiable is pretty questionable. What is the
>value of preventing repudiation by me of messages I am sending to myself?
>
>The question is whether the advantages of allowing this mode of use are
>worth the cost of supporting it. I doubt this is the case but if I turn out
>to be wrong for some reason I would prefer folk to use 'unsignd OCSP' than
>inventing a new protocol whose only real difference was avoiding signing.

Phil,

I have an application that operates under the scenario you described above,
i.e., a set of client machines that fully trust a secure server for the
purpose of online checking of a certificate's status. Thus, if OCSP forces
me to sign every response, I will have to invent the "unsigned OCSP"
protocol, as you surmised.

>
>Proposal:
>
>I suggest that unless there is an immediate need for this mode of operation
>it is left out of the current draft except possibly to note it as an option
>if people feel there is a major demand.

Personally, I support Dan Laska's suggestion of mentioning SSL (or other
external mechanism) as an alternative authentication mechanism for OCSP
(with all the caveats about non-repudiation that will let folks here sleep
at night).

>
>
>            Phill
>
>

/Luis
--------------------------------------------------
Luis F. Valente             Phone: [phone]
Network Computer, Inc.      Fax:   [phone]
www:  http://www.nc.com     Email: [e-mail]



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 14:26:14 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id NAA19876; Wed, 3 Dec 1997 13:19:00 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 3732 for [e-mail]; Wed, 3 Dec 1997 13:18:23 -0800
Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id NAA22225 for <[e-mail]>; Wed, 3 Dec 1997 13:18:21 -0800 (PST)
Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Wed, 03 Dec 1997 11:22:23 -0700
X-Mailer: Novell GroupWise 4.1
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 11:21:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Bob Jueneman <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [e-mail]

>It seems that the main purpose of having signed responses in OCSP
>is to authenticate the responder.
>
>Would it be useful, and perhaps simplify things, to permit SSL/https
>to be used in the protocol instead of requiring signed responses over
>http?

I don't think so.  Although I'm not making much headway in trying to get
OCSP to be more responsive to the nonrepudiation requirement, authenticating
the responder via SSL would not provide any lingering proof of the the
certificate's status.
>
>I am assuming here that the responder is tightly coupled to the CA.
>If the responder's site certificate is revoked then the responder
>itself would have to get disabled or updated by the CA.
>
>==========================================
>Dan Laska
>Frontier Technologies Corp.
>Email: [e-mail]
>==========================================

Bob



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 14:11:15 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id NAA18639; Wed, 3 Dec 1997 13:06:42 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 3650 for [e-mail]; Wed, 3 Dec 1997 13:06:09 -0800
Received: from arctic.valicert.com ([206.217.81.5]) by Tandem.com (8.8.8/2.0.1) with SMTP id MAA17921 for <[e-mail]>; Wed, 3 Dec 1997 12:55:34 -0800 (PST)
Received: from crater (crater.valicert.com [206.217.81.67]) by arctic.valicert.com (8.6.12/8.6.9) with ESMTP id MAA09726 for <[e-mail]>; Wed, 3 Dec 1997 12:49:14 -0800
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
MIME-Version: 1.0
X-Priority: 3 (Normal)
References: <01bd0022$c04cf940$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 12:55:50 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [e-mail]

Hi Dan,
    Going back to the 80,000 foot level, whether you use SSL or
direct signing of the response, both would involve a private key
operation at the OCSP server site. Given the expense of signing
operations, this is likely to limit the number of clients an OCSP
server can server at any given time (I would suspect SSL is quite
a bit more expensive than straight signing for a single connection,
but might get cheaper if a particular client makes multiple
connections to a server and session caching is used).

Also, with either of the two methods - SSL/Signing, the OCSP server
needs to have its private key available for responding to the
request - it needs to be "somewhat" online. So, if an OCSP server
has more clients than it can handle, it would either need to
duplicate its private key and make it available at multiple sites,
or have its clients trust a different private key.

I am writing up a draft on another method of handling certificate
status checking online, that would scale much better.

For early information, check out information about Certificate
Revocation Trees at:
http://www.valicert.com/company/crt.html

Cheers,
Ambarish

Dan Laska wrote:
>
> -----Original Message-----
> From: Phillip M Hallam-Baker <[e-mail]>
> To: [e-mail] <[e-mail]>
> Date: Wednesday, December 03, 1997 11:10 AM
> Subject: Re: [IETF-PKIX] OCSP using SSL/https
>
> >>It seems that the main purpose of having signed responses in OCSP
> >>is to authenticate the responder.
> >>
> >>Would it be useful, and perhaps simplify things, to permit SSL/https
> >>to be used in the protocol instead of requiring signed responses over
> >>http?
> >
> >
> >Are we talking 'instead of' or 'optionally'?
>
> Sorry. By "permit" I meant "optionally". Maybe "...instead of" made that
> ambiguous.
>
> >
> >Since we don't have a spec proposed for such a transport
> >I think that all we need at most doat this stage is put in some
> >wording to allow the possibility of relying on some other
> >proof of authenticity by prior agreement of both parties in
> >which case only the raw data need be sent.
> >
> >            Phill
> >
>
> I agree that SSL and/or other external means should be mentioned as
> alternative means of authentication in OCSP. I had noticed that the
> language in PKIX-3 was more along these lines (more flexible) rather
> than requiring any of the messages to be signed. It would be nice to
> have the other PKIX specs such as OCSP be consistent.
>
> ==========================================
> Dan Laska
> Frontier Technologies Corp.
> Email: [e-mail]
> ==========================================

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              [phone]
ValiCert, Inc.                                  [e-mail]
333 W. El Camino Real, Suite 270              http://www.valicert.com
Sunnyvale, CA 94087



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 14:07:26 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id NAA18367; Wed, 3 Dec 1997 13:03:45 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 3667 for [e-mail]; Wed, 3 Dec 1997 13:03:15 -0800
Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id NAA19533 for <[e-mail]>; Wed, 3 Dec 1997 13:03:12 -0800 (PST)
Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Wed, 03 Dec 1997 11:18:13 -0700
X-Mailer: Novell GroupWise 4.1
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 11:17:27 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Bob Jueneman <[e-mail]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
Comments: To: [e-mail]
To: [e-mail]

So that my comments aren't misunderstood, I wasn't arguing for restricting
these attributes to be non-critical. On the contrary, as Bill Burr pointed
out, making use of critical extensions which differentiate between
encryption vs. other uses (plus applications or operating systems which
actually enforce such usages) will significantly ease export problems.

I was merely lamenting the fact that we don't seem to be able to clearly
articulate was digital signature vs. non-repudiation means.

Bob

>>> Simonetti David <[e-mail]> 12/03 7:09 AM >>>
In both the financial and defense communities, this is an important
distinction to make.  Making the extension non-critical means that I can
ignore this distinction, and that is not desirable.

Dave S.

Sharon Boeyen wrote:
>
> There are some pretty simple uses of the keyUsage extension such as the
> difference between an encryption and digital signature key and we make
> heavy use of this today. I'd have no problem making the extension
> non-critical if that's more appropriate.
>
> ------------------
> Sharon Boeyen
> Entrust Technologies



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 13:35:24 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA14972; Wed, 3 Dec 1997 12:29:29 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 3534 for [e-mail]; Wed, 3 Dec 1997 12:29:02 -0800
Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id MAA12666 for <[e-mail]>; Wed, 3 Dec 1997 12:29:00 -0800 (PST)
Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Wed, 03 Dec 1997 11:11:00 -0700
X-Mailer: Novell GroupWise 4.1
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 11:10:24 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Bob Jueneman <[e-mail]>
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
Comments: To: [e-mail]
To: [e-mail]

Sharon,

>>>> Sharon Boeyen <[e-mail]> 12/03 6:01 AM >>>
>Bob
>
>Shades of NADF all over again - isn't it!

Deja vu..  You can pay me now, or you can pay me later, but these problems
are going to have to be solved.

>
>At the Washington PKIX meeting, one of the topics which will be
>discussed is whether or not the PKIX WG should define the minimum
>requirements of a schema for support in the directory environment. If
>that work does progress, I personally do not expect it to be a full
>directory schema definition (primarily because in many environments the
>PKI schema components need to fit into a larger schema which addresses
>multiple applications), however I believe there is utility in defining
>the minimum requirements for PKI purposes. I haven't given a lot of
>thought yet to what requirements of names there might be but  we'd be
>defining this schema with directory deployment so that probably would
>dictate a general direction for that piece of work.
>>
>Several people have indicated over the past 6 months or so that they
>think
>some schema work for PKIX would be useful and help move us forward in
>the area of interoperability, so I personally suspect this work item
>will progress (of course there's always the question of whether it
>belongs in the PKIX WG or elsewhere in the IETF). My opinion is that it
>should be tackled in the PKIX WG because that's where the understanding
>of the requirements is.

I'm not going to be able to make the December meeting, but I would certainly
put in my vote to make this a work item -- I think it will be necessary for
interoperability.

Of course the best of all worlds would be dynamic attribute definitions
distributed via the directory, but what good would that do without a
definition of the semantics?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[e-mail]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 13:12:42 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA12634; Wed, 3 Dec 1997 12:05:31 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 3431 for [e-mail]; Wed, 3 Dec 1997 12:05:06 -0800
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id MAA08445 for <[e-mail]>; Wed, 3 Dec 1997 12:05:04 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id MAA11174; Wed, 3 Dec 1997 12:04:31 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA05249; Wed, 3 Dec 1997 12:04:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Message-ID:  <01bd0028$1fd0a060$[e-mail]>
Date:         Wed, 3 Dec 1997 15:14:56 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Phillip M Hallam-Baker <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [e-mail]

>I'm having trouble figuring out what exactly you mean by your last
>sentence above.  Are you suggesting that if the sender and receiver are
>under the same CA then non-repudiation cannot really be achieved?  Any
>clarification would be helpful...


I said 'authority', not 'certificate authority' and used it in the context
of 'controlled by'. If I own and operate two machines at different locations
and believe the machines to be equally trustworthy the value of ensuring
that a communication is non repudiable is pretty questionable. What is the
value of preventing repudiation by me of messages I am sending to myself?

The question is whether the advantages of allowing this mode of use are
worth the cost of supporting it. I doubt this is the case but if I turn out
to be wrong for some reason I would prefer folk to use 'unsignd OCSP' than
inventing a new protocol whose only real difference was avoiding signing.

Proposal:

I suggest that unless there is an immediate need for this mode of operation
it is left out of the current draft except possibly to note it as an option
if people feel there is a major demand.


            Phill



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 12:55:09 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id LAA11008; Wed, 3 Dec 1997 11:49:28 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 3288 for [e-mail]; Wed, 3 Dec 1997 11:48:55 -0800
Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by Tandem.com (8.8.8/2.0.1) with ESMTP id LAA03007 for <[e-mail]>; Wed, 3 Dec 1997 11:38:09 -0800 (PST)
Received: from zionsbank.com by relay6.UU.NET with SMTP (peer crosschecked as: mail.zionsbank.com [207.14.144.36]) id QQdsiz15872; Wed, 3 Dec 1997 13:24:50 -0500 (EST)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Wed, 03 Dec 1997 11:23:57 -0700
X-Mailer: Novell GroupWise 4.1
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 11:23:47 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Mike Smith <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
Comments: To: [e-mail]
To: [e-mail]

Thanks for the speedy response.  Yes, I agree, if the requester, sender, responder are all under the same CA, then doubt as to who is doing stuff is reduced.  In cases where the reliant party is requesting status for a sender's cert that is outside their CA hierarchy, then the case is more significant to know "who" is responding and under what authority.

Michael

>>> Phillip M Hallam-Baker <[e-mail]> 12/03/97 11:14AM >>>
>In your response, SSL is said "would avoid the need to sign each HTTP/1.1
>reply in along sequence of requests.".
>
>If each object is not signed, or each data stream signed after the stream
is created (thus becoming one signed object), then SSL by itself does not
provide any evidence of what was sent by whom unless both parties retain
complete records of all the activity within the SSL session from time of
mutual authentication through the end of the session.


What you appear to be saying is that SSL does not provide non-repudiation.
This is of course a major problem. It is not necessarily a critical one
(e.g. both sender and reciever under same authority hence non-repudiation
moot).

This is why I don't like SSL for this application, I certainly don't see it
as being viable as the sole means of providing authentication. It MAY be
sufficiently useful in certain situations to make it an option along with
other external means of establishing authenticity.

        Phill
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 12:40:04 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id LAA09474; Wed, 3 Dec 1997 11:36:16 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 3240 for [e-mail]; Wed, 3 Dec 1997 11:35:45 -0800
Received: from mail.frontiertech.com (mail.frontiertech.com [192.104.32.4]) by Tandem.com (8.8.8/2.0.1) with ESMTP id LAA02534 for <[e-mail]>; Wed, 3 Dec 1997 11:35:39 -0800 (PST)
Received: from danl.frontiertech.com (madison4.frontiertech.com [207.250.95.4]) by mail.frontiertech.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-41702U200L100S0) with SMTP id AAA98 for <[e-mail]>; Wed, 3 Dec 1997 13:37:13 -0600
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Message-ID:  <01bd0022$c04cf940$[e-mail]>
Date:         Wed, 3 Dec 1997 13:36:29 -0600
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Dan Laska <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [e-mail]

-----Original Message-----
From: Phillip M Hallam-Baker <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Wednesday, December 03, 1997 11:10 AM
Subject: Re: [IETF-PKIX] OCSP using SSL/https


>>It seems that the main purpose of having signed responses in OCSP
>>is to authenticate the responder.
>>
>>Would it be useful, and perhaps simplify things, to permit SSL/https
>>to be used in the protocol instead of requiring signed responses over
>>http?
>
>
>Are we talking 'instead of' or 'optionally'?

Sorry. By "permit" I meant "optionally". Maybe "...instead of" made that
ambiguous.


>
>Since we don't have a spec proposed for such a transport
>I think that all we need at most doat this stage is put in some
>wording to allow the possibility of relying on some other
>proof of authenticity by prior agreement of both parties in
>which case only the raw data need be sent.
>
>            Phill
>

I agree that SSL and/or other external means should be mentioned as
alternative means of authentication in OCSP. I had noticed that the
language in PKIX-3 was more along these lines (more flexible) rather
than requiring any of the messages to be signed. It would be nice to
have the other PKIX specs such as OCSP be consistent.

==========================================
Dan Laska
Frontier Technologies Corp.
Email: [e-mail]
==========================================



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 12:20:42 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id LAA06999; Wed, 3 Dec 1997 11:15:13 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 3076 for [e-mail]; Wed, 3 Dec 1997 11:14:43 -0800
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id LAA28091 for <[e-mail]>; Wed, 3 Dec 1997 11:12:05 -0800 (PST)
Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Wed, 3 Dec 1997 14:00:51 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
Date:         Wed, 3 Dec 1997 14:00:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Carlisle Adams <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [e-mail]

Hi Phill,

>----------
>From:  Phillip M Hallam-Baker[SMTP:[e-mail]]
>Sent:  Wednesday, December 03, 1997 1:14 PM
>To:    [e-mail]
>Subject:       Re: [IETF-PKIX] OCSP using SSL/https
>
>>In your response, SSL is said "would avoid the need to sign each HTTP/1.1
>>reply in along sequence of requests.".
>>
>>If each object is not signed, or each data stream signed after the stream
>is created (thus becoming one signed object), then SSL by itself does not
>provide any evidence of what was sent by whom unless both parties retain
>complete records of all the activity within the SSL session from time of
>mutual authentication through the end of the session.
>
>
>What you appear to be saying is that SSL does not provide non-repudiation.
>This is of course a major problem. It is not necessarily a critical one
>(e.g. both sender and reciever under same authority hence non-repudiation
>moot).

My thesaurus entry for "moot" says that the following are synonyms:
controversial, contestable, debatable, arguable, disputable,
questionable, dubious, disputed, doubtful.

I'm having trouble figuring out what exactly you mean by your last
sentence above.  Are you suggesting that if the sender and receiver are
under the same CA then non-repudiation cannot really be achieved?  Any
clarification would be helpful...


--------------------------------------------
Carlisle Adams
Entrust Technologies
[e-mail]
--------------------------------------------



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 12:16:26 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id LAA06766; Wed, 3 Dec 1997 11:12:32 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 3064 for [e-mail]; Wed, 3 Dec 1997 11:12:05 -0800
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id LAA28078 for <[e-mail]>; Wed, 3 Dec 1997 11:12:02 -0800 (PST)
Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Wed, 3 Dec 1997 14:04:07 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
Date:         Wed, 3 Dec 1997 14:04:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Carlisle Adams <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [e-mail]

Hi Phill,

>----------
>From:  Phillip M Hallam-Baker[SMTP:[e-mail]]
>Sent:  Wednesday, December 03, 1997 11:55 AM
>To:    [e-mail]
>Subject:       Re: [IETF-PKIX] OCSP using SSL/https
>
>Since we don't have a spec proposed for such a transport
>I think that all we need at most doat this stage is put in some
>wording to allow the possibility of relying on some other
>proof of authenticity by prior agreement of both parties in
>which case only the raw data need be sent.

This sounds a bit dangerous to me.  It may be too easy for developers to
use this as an excuse for skipping the authentication step most of the
time...


--------------------------------------------
Carlisle Adams
Entrust Technologies
[e-mail]
--------------------------------------------



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 11:09:43 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA29684; Wed, 3 Dec 1997 10:04:58 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 2834 for [e-mail]; Wed, 3 Dec 1997 10:04:20 -0800
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA28972 for <[e-mail]>; Wed, 3 Dec 1997 10:04:18 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id KAA08706; Wed, 3 Dec 1997 10:03:45 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA29005; Wed, 3 Dec 1997 10:03:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Message-ID:  <01bd0017$416dbac0$[e-mail]>
Date:         Wed, 3 Dec 1997 13:14:11 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Phillip M Hallam-Baker <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
Comments: To: Mike Smith <[e-mail]>
To: [e-mail]

>In your response, SSL is said "would avoid the need to sign each HTTP/1.1
>reply in along sequence of requests.".
>
>If each object is not signed, or each data stream signed after the stream
is created (thus becoming one signed object), then SSL by itself does not
provide any evidence of what was sent by whom unless both parties retain
complete records of all the activity within the SSL session from time of
mutual authentication through the end of the session.


What you appear to be saying is that SSL does not provide non-repudiation.
This is of course a major problem. It is not necessarily a critical one
(e.g. both sender and reciever under same authority hence non-repudiation
moot).

This is why I don't like SSL for this application, I certainly don't see it
as being viable as the sole means of providing authentication. It MAY be
sufficiently useful in certain situations to make it an option along with
other external means of establishing authenticity.

        Phill



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 10:37:37 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA24992; Wed, 3 Dec 1997 09:29:44 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 2390 for [e-mail]; Wed, 3 Dec 1997 09:29:12 -0800
Received: from usr.com (mailgate.usr.com [149.112.20.2]) by Tandem.com (8.8.8/2.0.1) with ESMTP id JAA17678 for <[e-mail]>; Wed, 3 Dec 1997 09:19:10 -0800 (PST)
Received: from robogate2.usr.com by usr.com (8.8.5/3.1.090690-US Robotics) id LAA28803; Wed, 3 Dec 1997 11:04:02 -0600 (CST)
Received: from ccMail by robogate2.usr.com (IMA Internet Exchange 2.02 Enterprise) id 485A5010; Wed, 3 Dec 97 12:29:21 -0600
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="IMA.Boundary.167371188"
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 11:10:57 -0600
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: [e-mail]
Subject:      [IETF-PKIX] X.509 certificates and RADIUS
To: [e-mail]

Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     All,

        Just a heads up that I submitted a draft to the RADIUS WG a few
     weeks back which describes a mechanism to carry X.509 certificates
     within a RADIUS message. Although it was sent to the secretariat well
     over a week prior to the deadline, it is still not in the archives.

        I am sending the draft within this message (I do appologize for
     readers who do not have mime capability).

        I, unfortunately, cannot discuss this draft in DC since the PKIX
     meetings conflict with a WG that I chair and another that I have 3
     drafts pending :(

        Comments would be appreciated,

        PatC
Content-Type: text/basic; name="radx509.txt"
Content-Transfer-Encoding: 7bit
Content-Description: MS-DOS text file
Content-Disposition: attachment; filename="radx509.txt"

Attachment converted: Lutefisk:radx509.txt (TEXT/R*ch) (0001D378)



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 10:26:45 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA24194; Wed, 3 Dec 1997 09:22:57 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 2374 for [e-mail]; Wed, 3 Dec 1997 09:22:32 -0800
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by Tandem.com (8.8.8/2.0.1) with SMTP id JAA16330 for <[e-mail]>; Wed, 3 Dec 1997 09:12:29 -0800 (PST)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Wed, 03 Dec 1997 10:11:05 -0700
X-Mailer: Novell GroupWise 4.1
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 10:10:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Mike Smith <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP v CRLs over HTTP
Comments: To: [e-mail]
To: [e-mail]

In the case where a central repository services multiple CA's for OCSP, then that repository should sign (timestamp?) the response.  I'm not sure whether this will be a "tightly couple" relationship as some have suggested.  The CRL's used by the repository should, of course be signed by the original issuing CA.  The repository may even archive all of these CRL's issued and their signatures.


Michael
>>> Tim Moses <[e-mail]> 12/03/97 09:03AM >>>
Russ - By "the alternative" I take you to mean OCSP.  The OCSP response
is signed by the CA's signature key.  This provides authentication of
the responder's identity.  Best regards.  Tim.

>----------
>From:  Russ Housley[SMTP:[e-mail]]
>Sent:  Tuesday, December 02, 1997 11:43 AM
>To:    [e-mail]
>Subject:       Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>Tim:
>
>the digital signature on the CRL returned by HTTP or FTP provides teh
>authentication.  How is comperable authentication provided in the
>alternative?
>
>Russ
>


--------------------------------------------------------------
Tim Moses, Entrust Technologies,
Tel: [phone],
email: [e-mail].



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 10:37:20 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA25169; Wed, 3 Dec 1997 09:31:04 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 2391 for [e-mail]; Wed, 3 Dec 1997 09:30:39 -0800
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by Tandem.com (8.8.8/2.0.1) with SMTP id JAA17732 for <[e-mail]>; Wed, 3 Dec 1997 09:19:29 -0800 (PST)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Wed, 03 Dec 1997 10:18:21 -0700
X-Mailer: Novell GroupWise 4.1
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 10:17:57 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Mike Smith <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
Comments: To: [e-mail]
To: [e-mail]

In your response, SSL is said "would avoid the need to sign each HTTP/1.1
reply in along sequence of requests.".

If each object is not signed, or each data stream signed after the stream is created (thus becoming one signed object), then SSL by itself does not provide any evidence of what was sent by whom unless both parties retain complete records of all the activity within the SSL session from time of mutual authentication through the end of the session.

It seems that retaining object signing for each request or each batch of requests then lets each signed object stand by itself or either party.

Michael
>>> Phillip M Hallam-Baker <[e-mail]> 12/03/97 09:55AM >>>
>It seems that the main purpose of having signed responses in OCSP
>is to authenticate the responder.
>
>Would it be useful, and perhaps simplify things, to permit SSL/https
>to be used in the protocol instead of requiring signed responses over
>http?


Are we talking 'instead of' or 'optionally'?

The problem with using SSL is that the cache facility of HTTP
would be lost. Making the caching work really requires transaction
layer and not transport layer security.

I don't see a lot of value in pushing the public key work into
SSL except that it would avoid the need to sign each HTTP/1.1
reply in along sequence of requests. A more likely scenario
would be to want to use private key between two closely
coupled hosts.

Since we don't have a spec proposed for such a transport
I think that all we need at most doat this stage is put in some
wording to allow the possibility of relying on some other
proof of authenticity by prior agreement of both parties in
which case only the raw data need be sent.

            Phill



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 10:00:01 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id IAA21337; Wed, 3 Dec 1997 08:55:45 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 2259 for [e-mail]; Wed, 3 Dec 1997 08:55:19 -0800
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id IAA10883 for <[e-mail]>; Wed, 3 Dec 1997 08:45:17 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id IAA07102; Wed, 3 Dec 1997 08:44:45 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA25055; Wed, 3 Dec 1997 08:44:39 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Message-ID:  <01bd000c$3872d820$[e-mail]>
Date:         Wed, 3 Dec 1997 11:55:12 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Phillip M Hallam-Baker <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP using SSL/https
To: [e-mail]

>It seems that the main purpose of having signed responses in OCSP
>is to authenticate the responder.
>
>Would it be useful, and perhaps simplify things, to permit SSL/https
>to be used in the protocol instead of requiring signed responses over
>http?


Are we talking 'instead of' or 'optionally'?

The problem with using SSL is that the cache facility of HTTP
would be lost. Making the caching work really requires transaction
layer and not transport layer security.

I don't see a lot of value in pushing the public key work into
SSL except that it would avoid the need to sign each HTTP/1.1
reply in along sequence of requests. A more likely scenario
would be to want to use private key between two closely
coupled hosts.

Since we don't have a spec proposed for such a transport
I think that all we need at most doat this stage is put in some
wording to allow the possibility of relying on some other
proof of authenticity by prior agreement of both parties in
which case only the raw data need be sent.

            Phill



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 09:23:56 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id IAA17336; Wed, 3 Dec 1997 08:19:59 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 2007 for [e-mail]; Wed, 3 Dec 1997 08:19:34 -0800
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id IAA04008 for <[e-mail]>; Wed, 3 Dec 1997 08:09:32 -0800 (PST)
Received: tid LAA28685; Wed, 3 Dec 1997 11:06:41 -0500
Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Wed, 3 Dec 1997 11:03:35 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
Date:         Wed, 3 Dec 1997 11:03:34 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Tim Moses <[e-mail]>
Subject:      Re: [IETF-PKIX] OCSP v CRLs over HTTP
To: [e-mail]

Russ - By "the alternative" I take you to mean OCSP.  The OCSP response
is signed by the CA's signature key.  This provides authentication of
the responder's identity.  Best regards.  Tim.

>----------
>From:  Russ Housley[SMTP:[e-mail]]
>Sent:  Tuesday, December 02, 1997 11:43 AM
>To:    [e-mail]
>Subject:       Re: [IETF-PKIX] OCSP v CRLs over HTTP
>
>Tim:
>
>the digital signature on the CRL returned by HTTP or FTP provides teh
>authentication.  How is comperable authentication provided in the
>alternative?
>
>Russ
>


--------------------------------------------------------------
Tim Moses, Entrust Technologies,
Tel: [phone],
email: [e-mail].



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 09:11:43 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id IAA15732; Wed, 3 Dec 1997 08:04:42 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 1927 for [e-mail]; Wed, 3 Dec 1997 08:04:16 -0800
Received: from mail.frontiertech.com (mail.frontiertech.com [192.104.32.4]) by Tandem.com (8.8.8/2.0.1) with ESMTP id HAA01433 for <[e-mail]>; Wed, 3 Dec 1997 07:54:13 -0800 (PST)
Received: from danl.frontiertech.com (madison4.frontiertech.com [207.250.95.4]) by mail.frontiertech.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-41702U200L100S0) with SMTP id AAA149 for <[e-mail]>; Wed, 3 Dec 1997 09:55:49 -0600
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Message-ID:  <01bd0003$d48304a0$[e-mail]>
Date:         Wed, 3 Dec 1997 09:55:08 -0600
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Dan Laska <[e-mail]>
Subject:      [IETF-PKIX] OCSP using SSL/https
To: [e-mail]

It seems that the main purpose of having signed responses in OCSP
is to authenticate the responder.

Would it be useful, and perhaps simplify things, to permit SSL/https
to be used in the protocol instead of requiring signed responses over
http?

I am assuming here that the responder is tightly coupled to the CA.
If the responder's site certificate is revoked then the responder
itself would have to get disabled or updated by the CA.

==========================================
Dan Laska
Frontier Technologies Corp.
Email: [e-mail]
==========================================



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 08:50:32 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id HAA13931; Wed, 3 Dec 1997 07:46:16 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 1863 for [e-mail]; Wed, 3 Dec 1997 07:45:45 -0800
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by Tandem.com (8.8.8/2.0.1) with SMTP id HAA28859 for <[e-mail]>; Wed, 3 Dec 1997 07:35:43 -0800 (PST)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Wed, 03 Dec 1997 08:34:26 -0700
X-Mailer: Novell GroupWise 4.1
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 08:34:05 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Mike Smith <[e-mail]>
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
Comments: To: [e-mail]
Comments: cc: [e-mail], [e-mail], [e-mail], [e-mail]
To: [e-mail]

As usual, Bob, I find myself agreeing with your statements.

A certificate is issued under a certain set of authority policies.  If someone wishes to rely on a certificate issued under those policies, then the software they use must be able to process all of the critical extensions established under that policy or not honor the certificate.

If someone does accept a certificate or signature issued with critical extensions that are ignored or interpreted other than the intent of the issuing CA, then, it is my belief, the reliant party (and, possibly the entity that modified the code to accept or ignore the critical extensions) has just relieved the CA of any and all liability regarding that critical extension and, quite possibly, the whole certificate's issued purpose.

Michael

>>> Bob Jueneman <[e-mail]> 12/02/97 11:12AM >>>
Sharon and David,

My tongue in cheek suggestion that we deprecate the keyUsage field was made
as a result of my confusion and exasperation in trying to sort though all of
these different issues.  But if we can't agree on some relatively simple
meaning, I submit that using the fields will actually be WORSE than
deprecating them, for one person will think that they mean one thing, and
another person will interpret them differently.

What good does it do to mark an attribute as critical, if the semantics are
as undefined or ambiguous as these are?

And to bring up a somewhat different ubject that I mentioned before, but
never got closure on, I think that it is completely UNACCEPTABLE to say that
if some particular application does not have, understand, or chose to
implement a security policy, it should be free to simply ignore the critical
marking on a Policy OID constraint. This simply turns the definition of
critical on its head.  The critical usage is provided primarily to protect
the CA and/or the subject of the certificate from unreasonable reliance on
the certificate, and to provide a means for IT administrators to centrally
control what kinds of policies are to be enforced.

Bob

>Bob,
>
>First let me say that I highly respect all of the opinions that I've
>received.
>
>The key usage flags do play a useful role.  As a single example, they
>allow me to restrict use of my RSA key to either digital signature or
>key encipherment, but never both.  There is enough importance in this
>single role to warrant the extension be made "critical" when used.
>
>If this thread has proved anything, it's at least shown that there is no
>universal interpretation of non-repudiation or how to best implement
>it.  I think we should leave it up to individual communities of users to
>determine how to best implement this in their situation because there is
>not one right answer.  Certificate policies are going to play a mighty
>important role.
>
>Dave Simonetti
>
>Bob Jueneman wrote:
>>
>> >I, in turn, propose that digitalSignature is the mechanism.  If
>> >nonRepudiation is turned on, then the non-repudiation service is
>> >provided; if nonRepudiation is turned off, then non-repuditiation is not
>> >provided.  Why can't it be this simple?
>> >
>> >Dave Simonetti
>> >
>> >
>> I'd like to think that those who have ventured an opinion in this area
are
>> reasonably knowledgable about the subject.
>>
>> But if we cannot agree as what these bits mean, it is not likely that
either
>> CAs or client software will understand or correctly implement the
semantics,
>> no matter what the bottom line is.
>>
>> Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
>> they seem to be doing more harm than good.
>>
>> Can someone make a case for why we should bother with them, if there is
this
>> much confusion about their meaning?
>>
>> Bob



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 08:52:32 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id HAA14092; Wed, 3 Dec 1997 07:48:20 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 1868 for [e-mail]; Wed, 3 Dec 1997 07:47:54 -0800
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by Tandem.com (8.8.8/2.0.1) with SMTP id HAA29151 for <[e-mail]>; Wed, 3 Dec 1997 07:37:52 -0800 (PST)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Wed, 03 Dec 1997 08:36:27 -0700
X-Mailer: Novell GroupWise 4.1
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 08:36:06 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Mike Smith <[e-mail]>
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
Comments: To: [e-mail]
Comments: cc: [e-mail], [e-mail], [e-mail], [e-mail]
To: [e-mail]

Maybe I'm missing something with the X.500 compatibility issue and X.509 certifcates.  I thought that, with version 3, X.500 is just one schema tht the X.509v3 certificate processing systems should be "backward compatible" with.

Michael

>>> Andreas Berger <[e-mail]> 12/03/97 04:24AM >>>
Bob Jueneman wrote:
>
> >Phil,
> >
> >I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
> >require "Distinguished Names" to be "Directory Names"?

To my opinion, the X.509 certificates were intended to authenticate
users for access of the X.500 directory system. Certificates must
contain an acceptable name for the application in question. Therefore,
distinguished names for the X.500 are the appropriate namespace for this
application. For other applications there may well be other namespaces
acceptable.

> 1.  Does the DN in a certificate have to be globally unambiguous, so that no
> two people with the same common name could possibly be confused?
>
> Answering that question "yes" will force name subordination to be applied
> everywhere, even in cases where the obvious ways of doing it (geopolitical
> name qualification, down to the street address level) are either
> unacceptable (e.g., due to privacy concerns), or not workable (because the
> state or locality entities have not bought into the system, or because the
> natural domain of a CA (e.g., an ISP) is not confined by regional
> boundaries. This in turn tends to force the use of multiple RDNs as the leaf
> component, in order to avoid changing someone's common name while still
> maintaining global unambiguity.
>
> Answering the question "no" seems (at least on the surface) to significantly
> weaken the legal status of a digital signature for purposes of commerce,
> unless some other name mechanism (e.g., a unique account number) is included
> somewhere else, e.g, in an alternateSubjectName.  In the past, the legal
> system was somewhat cavalier about the assignment of names -- in fact it
> doesn't matter if you sign your checks as "Santa Claus" -- it is still your
> mark, whether unique or not.  But more recently, the issue of who owns
> domain names has become increasingly contentious. Whereas at one time Apple
> the computer company and Apple the music company had little to do with each
> other, today the separation is much less clean cut.  Even today, if there
> exists a David Kemp or a Robert Jueneman in Uganda somewhere, no significant
> legal confusion is likely to result. But who can say what will happen
> tomorrow? On the Internet, no one knows you live in Uganda (at least if you
> have an e-mail account with CompuServe. or some other domestic ISP).

We don't need a global unique name for users in a certificate in the way
you described it. We have to be very careful not to mix the attributes
of a person (Name, Address...) with the requirement of the technical
"name". That is a problem that X.500 created with typed RDNs.

For electronic commerce applications (or legally binding transactions)
we need a name that is acceptable to the other party. This acceptance
depends largely on the trustworthiness of the issuer of the certificate
and defined measures to get hold of the physical person in case a
dispute arises. Therefore, it should be enough to identify an end entity
relativly unique to the issuer. And this identification may well be made
by a number or some other means. People may have several identities in
this respect - and nobody will care unless the resolution of these
pseudonymity is required.

> 2. Does the use of X.509 envision at least the possibility of a globally
> interconnected directory to be used for certificate retrieval and perhaps
> CRL retrieval?  If so, doesn't require the assumption that the DN in the
> certificate is one to one with respect to the DIT?  If we don't start out
> deploying certificates with that assumption in mind, will it not prove to be
> impossible to migrate to such a scheme later on?

If an application accepts simple DNs (such as CN=High Speed Modem) it
has to have some knowledge on how to retrieve such names from a
directory (if a directory is employed at all). I would not want to make
very piece of equiment in a corporate network "worldwide unique". And
yes, this certificate would have no meaning outside the corporate
network, but is this really necessary?

For the (relativly simple) operations needed for retrieving security
attribute from directories (i.e. find a certificate for a person,
retrieve a CRL and so on) we could as well use URLs (LDAP, HTTP, FTP,
FINGER or something similar). We do not need a very complex "directory
service" for these operations.

But I agree that we should develop some guidelines for creating DNs. Or
at least write down what is already there (see the NT4 LDAP server,
verisign certificates, X.400 mailaddresses an so on). Perhaps we can
converge on an accepted practice. We should stress the point that these
DNs are automatically resolvable to machine/service names (on the
internet or other) so that applications (e.g. eMail clients or payment
systems) can access a direcory service to retrieve additional
information desired.

> 3.  And speaking of schemes, what schema is to be assumed for acceptable
> components of a DN in a certificate, if we are to ever move toward a common
> directory?  At present, I am not aware of any definition of what constitutes
> allowable, deprecated, or not allowable attribute types within a PKIX DN,
> yet if we ever expect that the current islands of LDAP usage will ever merge
> into archipelagoes, and finally continents, some agreement on acceptable
> schemas will have to be enforced.  Should we just leave it up to the public
> CAs like VeriSign to say what kinds of DN attributes they will support, and
> let all of the directory providers eat dirt?  Or vice versa?
I doubt that we will get a common directory for each and every entity on
the planet. Companies will severly restrict access to corporate
directories and even I personally would not want to publish a massive
amount of information globally.

> I believe that the working consensus is still the same that it was in the
> PEM days -- that we should strive to be interoperable with X.500
> directories, but should not presume their existence to be either necessary
> or sufficient.
Agreed. But what I would like to see is the seperation of the DN as a
name for an entry from identity information needed in certificates. The
DN for an entry is just a name (like an URL or bettern URN) that - in my
opionion - may be changed as often. What matters is the content of the
entry. If a CA wants to certify attributes of a person THAT ARE RELEVANT
to the application, it should put these into the certificate as well -
but not as part of the DN.

Andreas



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 07:45:36 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id GAA08466; Wed, 3 Dec 1997 06:38:11 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 1685 for [e-mail]; Wed, 3 Dec 1997 06:37:41 -0800
Received: from c3po.kc-inc.net ([e-mail] [207.156.32.6]) by Tandem.com (8.8.8/2.0.1) with ESMTP id GAA19916 for <[e-mail]>; Wed, 3 Dec 1997 06:27:38 -0800 (PST)
Received: from localhost (judiemul@localhost) by c3po.kc-inc.net (8.8.5/8.8.4) with SMTP id JAA07735 for <[e-mail]>; Wed, 3 Dec 1997 09:27:37 -0500
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 09:27:37 -0500
Reply-To: Judie Mulholland <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Judie Mulholland <[e-mail]>
Subject:      [IETF-PKIX] ITU recommendations v. IETF drafts
To: [e-mail]
In-Reply-To:  <[e-mail]>

i'd like to know if anyone on this list has seen/read the following
document:

[X.509] Recommendation X.509 (11/93) - Information technology - Open
Systems Interconnection - The directory: Authentication framework
Posted: 1996-01-29

http://www.itu.int/itudoc/itu-t/rec/x/x500up/x509_27505.html

in order to get access this paper, the reader must pay 20 swiss francs
(i.e., pay first, read later) and before doing so, i'd like to know the
following:

1) if someone could explain to me what the differences are between the
docs that are being published by the ITU and the ones that are being
produced under the auspices of the IETF.

2) judging by the publication date, it seems that the material must be
grossly out of date? am i correct in this assumption? if yes, where and
what should i be looking at? if not, is it worth paying for?

tia

/judie

ps

oops, i forgot to mention that i am doing my disseration in the area of
e-commerce and rights management. in particular, i am focusing on the
implementation of certificate authorities and digital signatures in the
state of florida.


Ph.D. Candidate                         Voice: [phone]
School of Information Studies           Fax:   [phone]
Florida State University                Email: [e-mail]
Tallahassee, FL 32306                   [e-mail]



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 07:14:11 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id GAA06328; Wed, 3 Dec 1997 06:10:47 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 1579 for [e-mail]; Wed, 3 Dec 1997 06:10:14 -0800
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by Tandem.com (8.8.8/2.0.1) with ESMTP id GAA17896 for <[e-mail]>; Wed, 3 Dec 1997 06:10:13 -0800 (PST)
Received: from bah.com ([156.80.128.197]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.01)  with ESMTP id AAA12671 for <[e-mail]>; Wed, 3 Dec 1997 09:11:51 -0500
X-Mailer: Mozilla 4.03 [en] (Win95; U)
MIME-Version: 1.0
References: <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <[e-mail]>
Date:         Wed, 3 Dec 1997 09:09:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Simonetti David <[e-mail]>
Organization: BAH
Subject:      Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
To: [e-mail]

In both the financial and defense communities, this is an important
distinction to make.  Making the extension non-critical means that I can
ignore this distinction, and that is not desirable.

Dave S.

Sharon Boeyen wrote:
>
> There are some pretty simple uses of the keyUsage extension such as the
> difference between an encryption and digital signature key and we make
> heavy use of this today. I'd have no problem making the extension
> non-critical if that's more appropriate.
>
> ------------------
> Sharon Boeyen
> Entrust Technologies
>
> mailto:[e-mail]       Tel: [phone]
> http://www.entrust.com          Fax: [phone]
>          Orchestrating Enterprise Security
>
> >----------
> >From:  Bob Jueneman[SMTP:[e-mail]]
> >Sent:  December 2, 1997 1:12 PM
> >To:    [e-mail]
> >Subject:       Re: [IETF-PKIX] digitalSignature vs. nonRepudiation
> >
> >Sharon and David,
> >
> >My tongue in cheek suggestion that we deprecate the keyUsage field was made
> >as a result of my confusion and exasperation in trying to sort though all of
> >these different issues.  But if we can't agree on some relatively simple
> >meaning, I submit that using the fields will actually be WORSE than
> >deprecating them, for one person will think that they mean one thing, and
> >another person will interpret them differently.
> >
> >What good does it do to mark an attribute as critical, if the semantics are
> >as undefined or ambiguous as these are?
> >
> >And to bring up a somewhat different ubject that I mentioned before, but
> >never got closure on, I think that it is completely UNACCEPTABLE to say that
> >if some particular application does not have, understand, or chose to
> >implement a security policy, it should be free to simply ignore the critical
> >marking on a Policy OID constraint. This simply turns the definition of
> >critical on its head.  The critical usage is provided primarily to protect
> >the CA and/or the subject of the certificate from unreasonable reliance on
> >the certificate, and to provide a means for IT administrators to centrally
> >control what kinds of policies are to be enforced.
> >
> >Bob
> >
> >>Bob,
> >>
> >>First let me say that I highly respect all of the opinions that I've
> >>received.
> >>
> >>The key usage flags do play a useful role.  As a single example, they
> >>allow me to restrict use of my RSA key to either digital signature or
> >>key encipherment, but never both.  There is enough importance in this
> >>single role to warrant the extension be made "critical" when used.
> >>
> >>If this thread has proved anything, it's at least shown that there is no
> >>universal interpretation of non-repudiation or how to best implement
> >>it.  I think we should leave it up to individual communities of users to
> >>determine how to best implement this in their situation because there is
> >>not one right answer.  Certificate policies are going to play a mighty
> >>important role.
> >>
> >>Dave Simonetti
> >>
> >>Bob Jueneman wrote:
> >>>
> >>> >I, in turn, propose that digitalSignature is the mechanism.  If
> >>> >nonRepudiation is turned on, then the non-repudiation service is
> >>> >provided; if nonRepudiation is turned off, then non-repuditiation is not
> >>> >provided.  Why can't it be this simple?
> >>> >
> >>> >Dave Simonetti
> >>> >
> >>> >
> >>> I'd like to think that those who have ventured an opinion in this area
> >are
> >>> reasonably knowledgable about the subject.
> >>>
> >>> But if we cannot agree as what these bits mean, it is not likely that
> >either
> >>> CAs or client software will understand or correctly implement the
> >semantics,
> >>> no matter what the bottom line is.
> >>>
> >>> Maybe we should just deprecate the whole X.509 keyUsage flags entirely --
> >>> they seem to be doing more harm than good.
> >>>
> >>> Can someone make a case for why we should bother with them, if there is
> >this
> >>> much confusion about their meaning?
> >>>
> >>> Bob
> >



Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 3 Dec 1997 06:50:42 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id FAA04259; Wed, 3 Dec 1997 05:41:54 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 1297 for [e-mail]; Wed, 3 Dec 1997 05:41:28 -0800
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id FAA13878 for <[e-mail]>; Wed, 3 Dec 1997 05:31:26 -0800 (PST)
Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Wed, 3 Dec 1997 08:23:57 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
Date:         Wed, 3 Dec 1997 08:23:55 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[e-mail]>
From: Sharon Boeyen <[e-mail]>
Subject:      Re: [IETF-PKIX] Question about SubjectAltNames
To: [e-mail]

Andreas,

I think your proposal of guidelines and best practices is a good one and
probably about as far as we could go in this area. There are 2 different
sets of requirements, both of which need to be accommodated. In one case
we want the names to be simple and easily retreivable and in the other
case we need to address both PKI-specific repositories and repositories
that are shared directories with other applications.

There are some guidelines that clearly fit into both environments, such
as recommending that only "standard" attribute types be used in names
and possibly recommending which ones (increasing the likelihood that
they can be retrieved), use of numeric values to disambiguate (although
3-4 years ago people would have thrown up their arms in opposition to
that I think that has changed along with the realization that these
don't normally get displayed to end-users anyway) ... just a few early
thoughts.

Sharon

------------------
Sharon Boeyen
Entrust Technologies

mailto:[e-mail]       Tel: [phone]
http://www.entrust.com          Fax: [phone]
         Orchestrating Enterprise Security


>----------
>From:  Andreas Berger[SMTP:[e-mail]]
>Sent:  December 3, 1997 6:24 AM
>To:    [e-mail]
>Subject:       Re: [IETF-PKIX] Question about SubjectAltNames
>
>Bob Jueneman wrote:
>>
>> >Phil,
>> >
>> >I believe Jim's question, which I share, is:  does X.509 (and/or PKIX)
>> >require "Distinguished Names" to be "Directory Names"?
>
>To my opinion, the X.509 certificates were intended to authenticate
>users for access of the X.500 directory system. Certificates must
>contain an acceptable name for the application in question. Therefore,
>distinguished names for the X.500 are the appropriate namespace for this
>application. For other applications there may well be other namespaces
>acceptable.
>
>> 1.  Does the DN in a certificate have to be globally unambiguous, so that
>>no
>> two people with the same common name could possibly be confused?
>>
>> Answering that question "yes" will force name subordination to be applied
>> everywhere, even in cases where the obvious ways of doing it (geopolitical
>> name qualification, down to the street address level) are either
>> unacceptable (e.g., due to privacy concerns), or not workable (because the
>> state or locality entities have not bought into the system, or because the
>> natural domain of a CA (e.g., an ISP) is not confined by regional
>> boundaries. This in turn tends to force the use of multiple RDNs as the
>>leaf
>> component, in order to avoid changing someone's common name while still
>> maintaining global unambiguity.
>>
>> Answering the question "no" seems (at least on the surface) to
>>significantly
>> weaken the legal status of a digital signature for purposes of commerce,
>> unless some other name mechanism (e.g., a unique account number) is
>>included
>> somewhere else, e.g, in an alternateSubjectName.  In the past, the legal
>> system was somewhat cavalier about the assignment of names -- in fact it
>> doesn't matter if you sign your checks as "Santa Claus" -- it is still your
>> mark, whether unique or not.  But more recently, the issue of who owns
>> domain names has become increasingly contentious. Whereas at one time Apple
>> the computer company and Apple the music company had little to do with each
>> other, today the separation is much less clean cut.  Even today, if there
>> exists a David Kemp or a Robert Jueneman in Uganda somewhere, no
>>significant
>> legal confusion is likely to result. But who can say what will happen
>> tomorrow? On the Internet, no one knows you live in Uganda (at least if you
>> have an e-mail account with CompuServe. or some other domestic ISP).
>
>We don't need a global unique name for users in a certificate in the way
>you described it. We have to be very careful not to mix the attributes
>of a person (Name, Address...) with the requirement of the technical
>"name". That is a problem that X.500 created with typed RDNs.
>
>For electronic commerce applications (or legally binding transactions)
>we need a name that is acceptable to the other party. This acceptance
>depends largely on the trustworthiness of the issuer of the certificate
>and defined measures to get hold of the physical person in case a
>dispute arises. Therefore, it should be enough to identify an end entity
>relativly unique to the issuer. And this identification may well be made
>by a number or some other means. People may have several identities in
>this respect - and nobody will care unless the resolution of these
>pseudonymity is required.
>
>> 2. Does the use of X.509 envision at least the possibility of a globally
>> interconnected directory to be used for certificate retrieval and perhaps
>> CRL retrieval?  If so, doesn't require the assumption that the DN in the
>> certificate is one to one with respect to the DIT?  If we don't start out
>> deploying certificates with that assumption in mind, will it not prove to
>>be
>> impossible to migrate to such a scheme later on?
>
>If an application accepts simple DNs (such as CN=High Speed Modem) it
>has to have some knowledge on how to retrieve such names from a
>directory (if a directory is employed at all). I would not want to make
>very piece of equiment in a corporate network "worldwide unique". And
>yes, this certificate would have no meaning outside the corporate
>network, but is this really necessary?
>
>For the (relativly simple) operations needed for retrieving security
>attribute from directories (i.e. find a certificate for a person,
>retrieve a CRL and so on) we could as well use URLs (LDAP, HTTP, FTP,
>FINGER or something similar). We do not need a very complex "directory
>service" for these operations.
>
>But I agree that we should develop some guidelines for creating DNs. Or
>at least write down what is already there (see the NT4 LDAP server,
>verisign certificates, X.400 mailaddresses an so on). Perhaps we can
>converge on an accepted practice. We should stress the point that these
>DNs are automatically resolvable to machine/service names (on the
>internet or other) so that applications (e.g. eMail clients or payment
>systems) can access a direcory service to retrieve additional
>information desired.
>
>> 3.  And speaking of schemes, what schema is to be assumed for acceptable
>> components of a DN in a certificate, if we are to ever move toward a common
>> directory?  At present, I am not aware of any definition of what
>>constitutes
>> allowable, deprecated, or not allowable attribute types within a PKIX DN,
>> yet if we ever expect that the current islands of LDAP usage will ever
>>merge
>> into archipelagoes, and finally continents, some agreement on acceptable
>> schemas will have to be enforced.  Should we just leave it up to the public
>> CAs like VeriSign to say what kinds of DN attributes they will support, and
>> let all of the directory providers eat dirt?  Or vice versa?
>I doubt that we will get a common directory for each and every entity on
>the planet. Companies will severly restrict access to corporate
>directories and even I personally would not want to publish a massive
>amount of information globally.
>
>> I believe that the working consensus is still the same that it was in the
>> PEM days -- that we should strive to be interoperable with X.500
>> directories, but should not presume their existence to be either necessary
>> or sufficient.
>Agreed. But what I would like to see is the seperation of the DN as a
>name for an entry from identity information needed in certificates. The
>DN for an entry is just a name (like an URL or bettern URN) that - in my
>opionion - may be changed as often. What matters is the content of the
>entry. If a CA wants to certify attributes of a person THAT ARE RELEVANT
>to the application, it should put these into the certificate as well -
>but not as part of the DN.
>
>Andreas
>--
> Andreas Berger, GMD - German National         eMail:
>[e-mail]
> Research Center for Information Technology,
> Institute for Telecooperation Technology      Tel:   [phone]
> Dolivostrasse 15, D-64293 Darmstadt, GERMANY  Fax:   [phone]
>