Re: lifetime versus NR, Re: Comments on the PKIX Roadmap

[Ed Gerck <[e-mail]>]

Alfred Arsenault wrote:

> Ed,
>
>         What was the "consensus" of this WG on the meaning of
> "non-repudiation"?

Wading through the messages in the archives it is possible to see that this
WG reached clear consensus on several NR items. For example, that NR is
not simply the setting of a bit -- in fact, this WG's  *unanimity* (!!) on NR was
that setting the NR-bit is neither necessary nor sufficient to define the
provision of NR services.

Based on this 100% consensual understanding,  this WG considered various
possibilities for defining the provision of NR services in a technical protocol,
and several clearly distinct modes of NR emerged -- I counted four main modes
(see archives).  Some of these NR modes were detailed in an effort by Tom Gindin
....that  is not even  *cited* in the roadmap .... with a proposed RFC... but which
was nonetheless extensively discussed in this WG and is archived at the IETF.
Can we NR that RFC? ;-))

Thus, reading the roadmap I felt a warp effect --  how could the roadmap ignore
these points of consensus and actions including a proposed RFC and, instead,
come up with an equivalence between NR and lifetime which was not discussed
at all? And, which is 100% redundant with the notion of lifetime itself -- after all,
if we want to signal a short lifetime there is a very well defined field for this in
PKIX that has nothing to do with NR.  Besides, the roadmap confused
"authenticated connection" (which authentication is ephemeral by definition and
lasts as long as the connection itself) with "signed object" (a certificate) which
can last much longer than even its signature lifetime (when providing support
for signature verification as in... NR ).

There are other problems with the new roadmap (see my previous msgs) and problems
which I did not address either --- and which IMO seriously undermine its usefulness
to reflect what this WG discussed and what the protocols are for.  Two of its key
purposes -- and that is why I suggested it should be recalled and redone.  It may be
that the new PKIX roadmap  "captured the WG's feelings from around mid '98
timeframe" as Sean Turner has mentioned today in this list -- but, aren't we
around end '99 timeframe?

Cheers,

Ed Gerck





Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA16790 for <[e-mail]>; Sun, 31 Oct 1999 00:57:51 -0700 (PDT)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FKGJM900.N6M for <[e-mail]>; Sun, 31 Oct 1999 08:01:21 +0000 
Received: from nma.com ([209.21.28.73]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FKGJLS00.U44; Sun, 31 Oct 1999 08:01:04 +0000 
Message-ID: <[e-mail]>
Date: Sun, 31 Oct 1999 00:59:24 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alfred Arsenault <[e-mail]>
CC: IETF-PXIX <[e-mail]>, Sean Turner <[e-mail]>
Subject: Re: lifetime versus NR, Re: Comments on the PKIX Roadmap
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alfred Arsenault wrote:

> Ed,
>
>         What was the "consensus" of this WG on the meaning of
> "non-repudiation"?

Wading through the messages in the archives it is possible to see that this
WG reached clear consensus on several NR items. For example, that NR is
not simply the setting of a bit -- in fact, this WG's  *unanimity* (!!) on NR was
that setting the NR-bit is neither necessary nor sufficient to define the
provision of NR services.

Based on this 100% consensual understanding,  this WG considered various
possibilities for defining the provision of NR services in a technical protocol,
and several clearly distinct modes of NR emerged -- I counted four main modes
(see archives).  Some of these NR modes were detailed in an effort by Tom Gindin
....that  is not even  *cited* in the roadmap .... with a proposed RFC... but which
was nonetheless extensively discussed in this WG and is archived at the IETF.
Can we NR that RFC? ;-))

Thus, reading the roadmap I felt a warp effect --  how could the roadmap ignore
these points of consensus and actions including a proposed RFC and, instead,
come up with an equivalence between NR and lifetime which was not discussed
at all? And, which is 100% redundant with the notion of lifetime itself -- after all,
if we want to signal a short lifetime there is a very well defined field for this in
PKIX that has nothing to do with NR.  Besides, the roadmap confused
"authenticated connection" (which authentication is ephemeral by definition and
lasts as long as the connection itself) with "signed object" (a certificate) which
can last much longer than even its signature lifetime (when providing support
for signature verification as in... NR ).

There are other problems with the new roadmap (see my previous msgs) and problems
which I did not address either --- and which IMO seriously undermine its usefulness
to reflect what this WG discussed and what the protocols are for.  Two of its key
purposes -- and that is why I suggested it should be recalled and redone.  It may be
that the new PKIX roadmap  "captured the WG's feelings from around mid '98
timeframe" as Sean Turner has mentioned today in this list -- but, aren't we
around end '99 timeframe?

Cheers,

Ed Gerck




Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00872 for <[e-mail]>; Sat, 30 Oct 1999 13:20:48 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id QAA02533; Sat, 30 Oct 1999 16:22:17 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sat, 30 Oct 1999 15:00:52 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Stephen Farrell (Baltimore)" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: LAAP performance issues
References: <01c601bf21e5$f9c09b00$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The model in the draft doesn't explicitly restrict the model to be for
the
"never revoke" method in draft-ietf-pkix-ac509prof-01.txt.  Should we
add a new
request and response to support revocation or was it intended to use
OCSP to get
revocation information?

Cheers,

spt

Andy Dowling wrote:

> Hi Stephen, David
>
> some suggestions on LAAP performance:
>
> 1. Batch LAAP requests. Perhaps the LAAPRequestMessage could be replaced
> with
>     a SEQUENCE of LAAPRequestMessage, so that a LRQ could request multiple
> ACs
>     with a single LAAP request? (The LRP would evaluate each
> LAAPRequestMessage
>     in the SEQUENCE individually). This could result in a saving of network
> bandwidth in
>     cases where a large volume of ACs is to be pulled over LAAP.
>
> 2.  Support for a "keep-alive" TCP connection between LRQ and LRP.
>      One problem with this is that, at the socket layer, some LRP
> implementations may
>      timeout the socket after a couple of minutes of inactivity. Perhaps the
> use of a "null"
>      LAAP request could be used in order for the LRQ to force the connection
> to stay
>      alive at the socket layer. This seems like a strange idea, 'cos if the
> LRP supports
>      keep-alives then the LRP will set the to infinite lifetime anyway.
> Nonetheless, comments
>      on this would be appreciated....
>
> Thanks,
>
> Andy
>
> -----
> Andy Dowling
> SSE (A Siemens Company)
> Fitzwilliam Court, Leeson Close,
> Dublin 2, Ireland
>
> E-Mail:  [e-mail]
> Web: http://www.sse.ie
> Phone: [phone]
> Fax:   [phone]




Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00818 for <[e-mail]>; Sat, 30 Oct 1999 13:20:32 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id QAA29209 for <[e-mail]>; Sat, 30 Oct 1999 16:29:16 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sat, 30 Oct 1999 16:17:11 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: Comments on draft-ietf-pkix-ac509prof-01.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Just a few comments/questions:

1. Can we add the text AA CA to the terminology section?  It is used in
section 5 and I think is pretty import.  Some suggested text (feel free
to modify it as you see fit): "AA CA  A CA that issues a PKC to an AA
indicating that it is allowed to issue ACs."

2. Clause 4.3.8 (issuerUniqueId) says: "This field MUST NOT be used."
shouldn't it be changed to say: "This field MUST be populated if the
AA's PKC includes the issuerUniqueId field.  Otherwise, this field MUST
NOT be used."  RFC2459 recommends that they not be included, but it
doesn't prohibit them.  In the case issuerUniqueIdentifier is present in
the AA's PKC, AC validation should check that they are present and both
match.

3. I think the first bullet in 5 (Attribute Certificate Validation)
should be changed to say: "The AC signature must be cryptographically
correct and the AC issuer's entire certification path (including the AC
issuer's PKC) MUST be verified in accordance with [RFC2459]."  On first
reading I wasn't sure that you only had to check the signature on the
issuer's PKC or the entire certificate path.  I think it's better to be
explicit.

4. Should we add a new "MUST satisfy" bullet in 5 that says: "The AC
issuer's distinguished name in issuerName.GeneralNames must match the
name in the AC issuer's PKC issuer field."  Or do you implicitly get
that check from checking the signature on the AC?

5. Right be the additional certification path checks in clause 5 there's
a parenthetical that should refer to (3) vice (2).

6.  Where is the format for the AC revocation list?  Are the revoked ACs
going to be put on the CRL or in some AC specific revocation list?

Thanks,

spt




Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00802 for <[e-mail]>; Sat, 30 Oct 1999 13:20:30 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id QAA02529 for <[e-mail]>; Sat, 30 Oct 1999 16:22:16 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sat, 30 Oct 1999 14:51:32 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: Comments on draft-ietf-pkix-ldap-v3-01.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

After thinking about the draft a bit I'd like to suggest a few
modifications (mostly organizational).

The draft includes both the protocol and schema issues to deal with
LDAPv3 servers.  I think we should split the two topics as the draft is
called "operational protocols".  I think the draft should just talk
about the protocol issues and not the schema.  My suggestion is to
update RFC 2587 (Internet X.509 Public Key Infrastructure LDAPv2 Schema)
to include the attribute and object classes required to support
attribute certificate users.  Then the LDAPv2 schema could support
storing the attribute certificate related information.  Another draft
should be spawned to include specific LDAPv3 schema issues such support
for matching rules, etc.

There is support for the pmiUser but where are the attribute authority's
certificates stored?  Should we define an pmiAA (name to be determined)
object class to support storing of the attribute certificate for the AA?

Also, which revocation list includes the revoked attribute
certificates?  I assumed it would be stored in a separate attribute
certificate revocation list, but the draft is silent on the issue (so is
draft-ietf-pkix-ac509prof-01.txt).

Thanks,

spt





Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00304 for <[e-mail]>; Sat, 30 Oct 1999 12:01:40 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id OAA01552; Sat, 30 Oct 1999 14:07:40 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sat, 30 Oct 1999 14:02:39 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: GMT <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: TYPO in Roadmap-04 re BERT
References: <[e-mail]> <017f01bf2024$6af1b480$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Todd,

I'm working on another version.  I will wait to send in the next version of the
roadmap after you've submitted the new bert draft so I can get it right.  Sorry
for the confusion.

spt

GMT wrote:

> FYI  All - BERT is not dead. The concluding statement in the PKI Roadmap is
> incorrect here.
>
> The BERT Token Specification is undergoing a redesign to allow it to support
> virtually any kind of event representation. It also will have a predefined
> set of event types including a Notarial Subtoken complete with a
> ceremony-service marker. The token structure will represent a digital
> harness with an encoded and protected manifest. This will allow the modular
> plugging in of a number of optional token components to create an
> interoperable policy centric token. - the ultimate timestamp so to speak -
>
> Anyway, the new token structure will also have an applications and Network
> transparent API to address the marking, validating, and verifying of
> virtually all events in time and space. We feel this is the start of "agency
> control" and conveyance models and that they will operate  by demonstrating
> the intent of the user. These token data structures and the API for managing
> them are very important to eCommerce and will be of more important to PKIX
> as the evolution of the Internet and Global ECommerce continues.
>
> The currently underway draft will not make this meeting but will be filed
> shortly afterward and will be available for comment as such prior to the
> next meeting.
>
> If I can answer any questions in the mean time please feel free to contact
> me or Michael directly
>
> [e-mail]
> [e-mail]
>
> Todd Glassey
>
> > Todd:
> >
> > Here's the BERT excerpt from the roadmap, published Oct 22...note the
> > status at the end.
> >
> >    DOCUMENT TITLE: Basic Event Representation Token <draft-ietf-pkix-
> >    bert1-01.txt>
> >
> >    DESCRIPTION: This document defines a finite method of representing a
> >    discrete instant in time as a referable event. The Basic Event
> >    Representation Token (BERT) is a light-weight binary token designed
> >    for use in large numbers over short periods of time. The tokens
> >    contain only a single instance of an event stamp and the trust
> >    process is referenced against an external reference.
> >
> >    STATUS: Work has been discontinued.
> >
> >



Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00304 for <[e-mail]>; Sat, 30 Oct 1999 12:01:40 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id OAA01552; Sat, 30 Oct 1999 14:07:40 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sat, 30 Oct 1999 14:02:39 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: GMT <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: TYPO in Roadmap-04 re BERT
References: <[e-mail]> <017f01bf2024$6af1b480$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Todd,

I'm working on another version.  I will wait to send in the next version of the
roadmap after you've submitted the new bert draft so I can get it right.  Sorry
for the confusion.

spt

GMT wrote:

> FYI  All - BERT is not dead. The concluding statement in the PKI Roadmap is
> incorrect here.
>
> The BERT Token Specification is undergoing a redesign to allow it to support
> virtually any kind of event representation. It also will have a predefined
> set of event types including a Notarial Subtoken complete with a
> ceremony-service marker. The token structure will represent a digital
> harness with an encoded and protected manifest. This will allow the modular
> plugging in of a number of optional token components to create an
> interoperable policy centric token. - the ultimate timestamp so to speak -
>
> Anyway, the new token structure will also have an applications and Network
> transparent API to address the marking, validating, and verifying of
> virtually all events in time and space. We feel this is the start of "agency
> control" and conveyance models and that they will operate  by demonstrating
> the intent of the user. These token data structures and the API for managing
> them are very important to eCommerce and will be of more important to PKIX
> as the evolution of the Internet and Global ECommerce continues.
>
> The currently underway draft will not make this meeting but will be filed
> shortly afterward and will be available for comment as such prior to the
> next meeting.
>
> If I can answer any questions in the mean time please feel free to contact
> me or Michael directly
>
> [e-mail]
> [e-mail]
>
> Todd Glassey
>
> > Todd:
> >
> > Here's the BERT excerpt from the roadmap, published Oct 22...note the
> > status at the end.
> >
> >    DOCUMENT TITLE: Basic Event Representation Token <draft-ietf-pkix-
> >    bert1-01.txt>
> >
> >    DESCRIPTION: This document defines a finite method of representing a
> >    discrete instant in time as a referable event. The Basic Event
> >    Representation Token (BERT) is a light-weight binary token designed
> >    for use in large numbers over short periods of time. The tokens
> >    contain only a single instance of an event stamp and the trust
> >    process is referenced against an external reference.
> >
> >    STATUS: Work has been discontinued.
> >
> >



Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22462 for <[e-mail]>; Sat, 30 Oct 1999 10:56:51 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id NAA27022; Sat, 30 Oct 1999 13:58:14 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sat, 30 Oct 1999 13:53:14 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-roadmap-04.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed,

Thanks for taking the time to review the document and sorry it took me so long to get to this
message.  That section hasn't changed since the first draft (draft-ietf-pkix-roadmap-01.txt).
Clearly there's been more discussion on the list and it needs to be updated.  But, I think it
captured the WG's feelings from around mid '98 timeframe.

spt

Ed Gerck wrote:

> [e-mail] wrote:
>
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> >
> >         Title           : Internet X.509 Public Key Infrastructure PKIX Roadmap
> >         Author(s)       : A. Arsenault, S. Turner
> >         Filename        : draft-ietf-pkix-roadmap-04.txt
> >         Pages           : 40
> >         Date            : 22-Oct-99
>
> >From the above draft:
>
>    According to [SIMONETTI], the intent is that the digitalSignature bit
>    should be set when what is desired is the ability to sign ephemeral
>    transactions; e.g., for a single session authentication. These
>    transactions are "ephemeral" in the sense that they are important
>    only while they are in existence; after the session is terminated,
>    there is no long-term record of the digital signature and its
>    properties kept. When something is intended to be kept for some
>    period of time, the nonRepudiation bit should be set.
>
> The last phrase finds no support on what was discussed in this WG,
> non-repudiation is not a non-ephemeral digital signature.
>
> There are also other instances where the draft finds no support in
> the WG discussions, even when it says it has:
>
>     The discussion on the PKIX mailing list has centered on the
>    digitalSignature bit and the nonRepudiation bit. The question has
>    come down to something like: When support for the service of non-
>    repudiation is desired, should both the digitalSignature and
>    nonRepudiation bits be set, or just the nonRepudiation bit?
>
> because this question was neither substantive nor representative
> of the discussions -- unless "has come down to" means something
> else.
>
> Cheers,
>
> Ed Gerck



Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20603 for <[e-mail]>; Sat, 30 Oct 1999 07:51:07 -0700 (PDT)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Sat, 30 Oct 1999 07:54:31 -0700
Message-ID: <[e-mail]>
Date: Sat, 30 Oct 1999 10:51:32 -0400
From: Alfred Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: lifetime versus NR, Re: Comments on the PKIX Roadmap
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed,

	What was the "consensus" of this WG on the meaning of
"non-repudiation"?  I've looked back yet again at all of the messages,
and I can find no consensus.  I can find only several different groups
of people holding different ideas of what it means, or should mean, or
ought to mean but maybe doesn't, or...

	My interpretation of when the NR discussions stopped is that it wasn't
because the WG reached consensus, it was because a number of the
participants just stopped trying to make the same point/argue against
the same point over and over and over ... 

	I'll ask the working group chairs to bring this up in Washington.  The
Roadmap (and other WG documents, but especially the Roadmap, because of
its purpose) should reflect the consensus of the WG on its major
issues.  It should not be "creative" nor contradictory, nor should it
reflect the views of just its authors unless those are explicitly
identified as such.  

	(Please note:  I'm leaving for the airport in about 30 minutes; I'll
most likely be away from e-mail access for the next nine days.  Please
don't interpret my silence/non-participation in discussions of this
between now and then as agreeing to or disagreeing with any stated
position.)

			Al Arsenault

--- This posting represents the opinions of the author only, and may or
may not reflect the views of his employer or of any other organization
with which he may have a relationship.


Ed Gerck wrote:
> 
> Denis Pinkas wrote:
> 
> > Comments on the PKIX Roadmap <draft-ietf-pkix-roadmap-04.txt>
> 
> Dennis:
> 
> The PKIX roadmap is a very creative document. In fact, there is
> little resemblance between its contents and the past
> messages/consensus in this WG.
> 
> > Page 43. About the discussion, starting with "According to
> > [SIMONETTI], ..." I would propose a global replacement until the end
> > of that topic:
> >
> > " The intent is that the digitalSignature bit should be set when
> > what is desired is the ability to sign ephemeral transactions; e.g.,
> > for a single session authentication. These transactions are
> > "ephemeral" in the sense that they are important only while they are
> > in existence; after the session is terminated, there is no long-term
> > record of the digital signature and its properties kept.
> 
> The ability to sign ephemeral transactions e.g., single session
> authentication has to do with the *authenticated connection*
> not with a *signed object* (the certificate) -- so, it is rather easy
> to distinguish the DS bit in either case.  There is no need to
> yet again redefine non-repudiation as a "non-ephemeral digital
> signature" in order to do so:
> 
> >When something is intended to be kept for some period of time for
> >non repudiation purposes, the nonRepudiation bit shall be set. This
> >implies that an application will digitally sign something that may
> >be used for non repudiation purposes; this bit must be turn on.
> 
> The new confusion introduced by your text (and the roadmap)  is
> that non-repudiation has now nothing to do with "preventing the
> denial of a previous act" (HAC, Menezes) or even with "protecting
> against falsely denying an act" (RFC 2459) but with the *lifetime*
> of a digital signature.  Hmmmm... this was never mentioned
> in this WG and is clearly a redundant definition -- so, why
> have it? To avoid the issue?
> 
> Or, perhaps there are those that now say the WG consensus on
> NR was "wrong"?  Perhaps, but this should be decided in this list,
> not in the roadmap text and not in a redundant definition of
> lifetime.
> 
> I also note for the record that accepting this would mean to negate the
> IETF decision process, which I think is even worse than confusing
> "non-repudiation" with lifetime.  Thus, in the best spirit of the Internet
> of routing around the damage, I ask for a recall of the roadmap as it is
> and for a reinstatement of what was discussed and decided here.
> Otherwise, in the future, someone will say "but, there is precedent for
> this behavior" and we will have no more roads but just slippery
> slopes to map, I am afraid.
> 
> Cheers,
> 
> Ed Gerck


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA19906 for <[e-mail]>; Sat, 30 Oct 1999 06:19:49 -0700 (PDT)
Received: from mega (t1o69p93.telia.com [62.20.144.93]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id PAA47429; Sat, 30 Oct 1999 15:19:58 +0200
Message-ID: <002001bf22e1$db5ffc30$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>, "'SEIS-List'" <[e-mail]>
Cc: "Magnus (RSA)" <[e-mail]>
Subject: QC comparisons are DEADLY serious!
Date: Sat, 30 Oct 1999 15:20:01 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA19907

Stefan, 

I strongly disagree on your conclusions regarding certificate comparisons. 
Rather, I consider the possibility to compare certificates from a certain issuer and CPS 
to be a major "quality" property that deserves a section of its own. 

To give an example. If you have a QC issued by a TTP (ID-certificates that 
will only be used within the issuer's own domain are pretty uninteresting) and 
your bank accepts that certificate in conjunction with its Internet-bank it 
is VERY interesting for BOTH the bank (RP) and for the customer (Subscriber) 
to know what will happen the day you log in with a renewed certificate. 
IN ADVANCE. 

So what you describe as a "minor issue" is for some people a FUNDAMENTAL 
ISSUE that the QC draft IMLHO must address in much more serious way than in V02. 

Anders



-----Original Message-----
From: Stefan Santesson <[e-mail]>
To: Anders Rundgren <[e-mail]>; 'SEIS-List' <[e-mail]>; [e-mail] <[e-mail]>
Date: Friday, October 29, 1999 23:09
Subject: SEIS: Re: QC certificates MAY CERTAINLY be compared!


>--- Message on the SEIS mailing list ([e-mail])
>
>Anders,
>
>Thank you, I have noticed your comment.
>
>The security considerations section contains CONSIDERATIONS for the general
>case and I still believe in the intent behind this sentence, as a good
>general guidance to implementations. 
>
>Setting up implementations with the intent to compare two qualified
>certificates to see if they represent the same person IS generally a bad
>service that shouldn't be performed. Since in the general case, you will
>have clear risk of misleading results.
>
>Well, if you leave the general case and go into speciffic cases such as
>comparing SEIS certificates within a local region (such as Sweden), then
>there will allways be cases where some security considerations does not
>apply (such as this particular one).
>
>I think this is a minor issue within the security consideration section
>which does not affect the implementation of the profile. Shure there are an
>even better way of expressing the original intent behind that sentence. But
>on the other hand,  there will allways be a better way of everything.
>
>I think the present description is good enough. Can you live with it ?
>
>/Stefan
>
>At 17:55 1999-10-25 +0100, Anders Rundgren wrote:
>>Stefan,
>>I have said it before and I say it again.  The following QC-statement is 
>>higly doubtful:
>>
>>"Comparing two qualified certificates to determine if they represent
>> the same physical entity may provide misleading results and should
>> not be performed"
>>
>>As you know our famous (?) SEIS-card does indeed allow certificates to
>>be compared for subject identity.   That is IMO the whole (and only) point 
>>with *real* ID-cards!
>>
>>So this is a statement of the CPS.  Not of the draft.
>>
>>
>>
>>BTW, why no explicit support for "container ID" (card serial) as most QCs 
>>will be
>>put in smart cards?  It was in SEIS already.
>>
>>
>>Anders
>>
>>
>>-----Original Message-----
>>From: Stefan Santesson <[e-mail]>
>>To: [e-mail] <[e-mail]>
>>Date: Monday, October 25, 1999 14:14
>>Subject: New submitted draft for Qualified Certificates
>>
>>
>>>All,
>>>
>>>A new draft for a Qualified Certificates Profile was submitted friday 22.
>>>
>>>The new draft can be obtained from:
>>>http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt
>>>
>>>The QC website has been udated accrodingly:
>>>http://www.accurata.se/QC/
>>>
>>>See also under settled topics to obtain information about major
>>>considerations since the last draft.
>>>
>>>/Stefan
>>>-------------------------------------------------------------------
>>>Stefan Santesson                <[e-mail]>
>>>Accurata AB                     http://www.accurata.se
>>>Slagthuset                      Tel. [phone]              
>>>211 20  Malmö                   Fax. [phone]              
>>>Sweden                        Mobile [phone]
>>>
>>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>>-------------------------------------------------------------------
>>> 
>
>
>----------------- SEIS mailing list ([e-mail])
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: [e-mail]
>
>



Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4-ext.email.verio.net [129.250.36.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA15526 for <[e-mail]>; Sat, 30 Oct 1999 01:40:26 -0700 (PDT)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FKEQX100.K03 for <[e-mail]>; Sat, 30 Oct 1999 08:43:49 +0000 
Received: from nma.com ([209.21.28.64]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FKEQW200.208 for <[e-mail]>; Sat, 30 Oct 1999 08:43:14 +0000 
Message-ID: <[e-mail]>
Date: Sat, 30 Oct 1999 01:42:31 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: IETF-PXIX <[e-mail]>
Subject: lifetime versus NR, Re: Comments on the PKIX Roadmap
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:

> Comments on the PKIX Roadmap <draft-ietf-pkix-roadmap-04.txt>

Dennis:

The PKIX roadmap is a very creative document. In fact, there is
little resemblance between its contents and the past
messages/consensus in this WG.

> Page 43. About the discussion, starting with "According to
> [SIMONETTI], ..." I would propose a global replacement until the end
> of that topic:
>
> " The intent is that the digitalSignature bit should be set when
> what is desired is the ability to sign ephemeral transactions; e.g.,
> for a single session authentication. These transactions are
> "ephemeral" in the sense that they are important only while they are
> in existence; after the session is terminated, there is no long-term
> record of the digital signature and its properties kept.

The ability to sign ephemeral transactions e.g., single session
authentication has to do with the *authenticated connection*
not with a *signed object* (the certificate) -- so, it is rather easy
to distinguish the DS bit in either case.  There is no need to
yet again redefine non-repudiation as a "non-ephemeral digital
signature" in order to do so:

>When something is intended to be kept for some period of time for
>non repudiation purposes, the nonRepudiation bit shall be set. This
>implies that an application will digitally sign something that may
>be used for non repudiation purposes; this bit must be turn on.

The new confusion introduced by your text (and the roadmap)  is
that non-repudiation has now nothing to do with "preventing the
denial of a previous act" (HAC, Menezes) or even with "protecting
against falsely denying an act" (RFC 2459) but with the *lifetime*
of a digital signature.  Hmmmm... this was never mentioned
in this WG and is clearly a redundant definition -- so, why
have it? To avoid the issue?

Or, perhaps there are those that now say the WG consensus on
NR was "wrong"?  Perhaps, but this should be decided in this list,
not in the roadmap text and not in a redundant definition of
lifetime.

I also note for the record that accepting this would mean to negate the
IETF decision process, which I think is even worse than confusing
"non-repudiation" with lifetime.  Thus, in the best spirit of the Internet
of routing around the damage, I ask for a recall of the roadmap as it is
and for a reinstatement of what was discussed and decided here.
Otherwise, in the future, someone will say "but, there is precedent for
this behavior" and we will have no more roads but just slippery
slopes to map, I am afraid.

Cheers,

Ed Gerck




Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23959; Fri, 29 Oct 1999 16:38:04 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
Date: Fri, 29 Oct 1999 16:41:23 -0700
To: Tony Bartoletti <[e-mail]>, [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Y2K, RFC 2459, . . .
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Um, why is any of this relevant in the PKIX WG? I don't see any PKI issues 
here...

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23679 for <[e-mail]>; Fri, 29 Oct 1999 16:28:04 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id QAA04634; Fri, 29 Oct 1999 16:31:24 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 29 Oct 1999 16:31:32 -0700
To: [e-mail], [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: Y2K, RFC 2459, . . .
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

I believe the rules for "leap year" adjustments are as follows:

  A leap-day is added every year divisible by 4,
    EXCEPT if year is divisible by 100 (no leap-day added)
	UNLESS year is divisible by 400 (ordinary leap-day added).

So, the year 2000 is an ordinary leap year, being divisible by 400.

___tony___

At 06:06 PM 10/29/99 EDT, [e-mail] wrote:
>Reading, w/out having kept up to date w/ISO issues . . . 
>I've have been watching for, and not seeing comments addressing the 
>requirement of our calendar to add an extra Leap Day after the year 2000.
>
>As I recall, the calendar we have was designed to best keep accurate with the 
>sun, and requires a leap day every 4 yrs.  This schedule, also, calls for and 
>additional day every 1000 years.  The intent was to add it after the 
>millennium.  As the calendar truly recognizes the year 2000 as the last year 
>in this millennium, it seems that we were to add an additional day during the 
>1st year of the next millennium, 2001.
>
>Where is this issue being addressed?  Or, has this path been abandoned by all 
>parties concerned.  (Initially, the entire Christian world . . . perhaps only 
>the Catholic churches.)
>
>

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from imo-d05.mx.aol.com (imo-d05.mx.aol.com [205.188.157.37]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA22697 for <[e-mail]>; Fri, 29 Oct 1999 15:03:57 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo-d05.mx.aol.com (mail_out_v23.6.) id 7CVYpzgLf_ (3895) for <[e-mail]>; Fri, 29 Oct 1999 18:06:44 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 29 Oct 1999 18:06:43 EDT
Subject: Y2K, RFC 2459, . . .
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 26

Reading, w/out having kept up to date w/ISO issues . . . 
I've have been watching for, and not seeing comments addressing the 
requirement of our calendar to add an extra Leap Day after the year 2000.

As I recall, the calendar we have was designed to best keep accurate with the 
sun, and requires a leap day every 4 yrs.  This schedule, also, calls for and 
additional day every 1000 years.  The intent was to add it after the 
millennium.  As the calendar truly recognizes the year 2000 as the last year 
in this millennium, it seems that we were to add an additional day during the 
1st year of the next millennium, 2001.

Where is this issue being addressed?  Or, has this path been abandoned by all 
parties concerned.  (Initially, the entire Christian world . . . perhaps only 
the Catholic churches.)


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22416 for <[e-mail]>; Fri, 29 Oct 1999 14:56:37 -0700 (PDT)
Received: from foo.telia.se (t3o68p90.telia.com [62.20.139.90]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id XAA18102; Fri, 29 Oct 1999 23:59:50 +0200
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sat, 30 Oct 1999 00:01:27 +0200
To: "Anders Rundgren" <[e-mail]>, "'SEIS-List'" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC certificates MAY CERTAINLY be compared!
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA22417

Anders,

Thank you, I have noticed your comment.

The security considerations section contains CONSIDERATIONS for the general
case and I still believe in the intent behind this sentence, as a good
general guidance to implementations. 

Setting up implementations with the intent to compare two qualified
certificates to see if they represent the same person IS generally a bad
service that shouldn't be performed. Since in the general case, you will
have clear risk of misleading results.

Well, if you leave the general case and go into speciffic cases such as
comparing SEIS certificates within a local region (such as Sweden), then
there will allways be cases where some security considerations does not
apply (such as this particular one).

I think this is a minor issue within the security consideration section
which does not affect the implementation of the profile. Shure there are an
even better way of expressing the original intent behind that sentence. But
on the other hand,  there will allways be a better way of everything.

I think the present description is good enough. Can you live with it ?

/Stefan

At 17:55 1999-10-25 +0100, Anders Rundgren wrote:
>Stefan,
>I have said it before and I say it again.  The following QC-statement is 
>higly doubtful:
>
>"Comparing two qualified certificates to determine if they represent
> the same physical entity may provide misleading results and should
> not be performed"
>
>As you know our famous (?) SEIS-card does indeed allow certificates to
>be compared for subject identity.   That is IMO the whole (and only) point 
>with *real* ID-cards!
>
>So this is a statement of the CPS.  Not of the draft.
>
>
>
>BTW, why no explicit support for "container ID" (card serial) as most QCs 
>will be
>put in smart cards?  It was in SEIS already.
>
>
>Anders
>
>
>-----Original Message-----
>From: Stefan Santesson <[e-mail]>
>To: [e-mail] <[e-mail]>
>Date: Monday, October 25, 1999 14:14
>Subject: New submitted draft for Qualified Certificates
>
>
>>All,
>>
>>A new draft for a Qualified Certificates Profile was submitted friday 22.
>>
>>The new draft can be obtained from:
>>http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt
>>
>>The QC website has been udated accrodingly:
>>http://www.accurata.se/QC/
>>
>>See also under settled topics to obtain information about major
>>considerations since the last draft.
>>
>>/Stefan
>>-------------------------------------------------------------------
>>Stefan Santesson                <[e-mail]>
>>Accurata AB                     http://www.accurata.se
>>Slagthuset                      Tel. [phone]              
>>211 20  Malmö                   Fax. [phone]              
>>Sweden                        Mobile [phone]
>>
>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>-------------------------------------------------------------------
>> 


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA21926 for <[e-mail]>; Fri, 29 Oct 1999 14:15:35 -0700 (PDT)
Received: from foo.telia.se (t2o68p59.telia.com [62.20.138.179]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id XAA17883; Fri, 29 Oct 1999 23:18:48 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 29 Oct 1999 23:20:25 +0200
To: Russ Housley <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: QC certificates and Nationality
Cc: "'SEIS-List'" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <000801bf1f09$c9fbeac0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

You can store as many citizenship countries as you like (in the personal data
field).

3.2.1 states:

   The countryOfCitizenship attribute SHALL, when present, contain the
   identifier of at least one of the subject's claimed country of
   citizenship at the time that the certificate was issued. If the
   subject is a citizen of more than one country, more than one country
   MAY be present. Determination of citizenship is a matter of law and
   is outside the scope of this document.

At 16:40 1999-10-27 -0500, you wrote:
>What goes into the QC when a person is a citizen of more than one country?
>
>Russ



Received: from dylithium.adga.ca ([206.222.76.26]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20813 for <[e-mail]>; Fri, 29 Oct 1999 12:43:34 -0700 (PDT)
Received: from xfile (blackhole.abnet.net [209.112.11.3]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id PAA13095; Fri, 29 Oct 1999 15:44:45 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 29 Oct 1999 15:39:29 -0400
To: [e-mail]
From: Francois Rousseau <[e-mail]>
Subject: Re: draft-ietf-pkix-ipki-ecdsa-02.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA20814

In addition, since the support for ECC based key agreement and key
transport are being profiled under the S/MIME Mail Security Working Group,
should not the specification for these keys also be folded into the updated
RFC 2459?

François 

At 11:44 AM 27/10/99 -0500, you wrote:
>Given that RFC 2459 must be updated, I suggest that these specification be 
>folded into the updated RFC 2459. I do not think that a separate document 
>adds value.
>
>Russ
>
[snip]


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15147 for <[e-mail]>; Fri, 29 Oct 1999 06:14:41 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id PAA14746 for <[e-mail]>; Fri, 29 Oct 1999 15:17:36 +0200
Message-ID: <[e-mail]>
Date: Fri, 29 Oct 1999 15:17:28 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Comments on the PKIX Roadmap
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Comments on the PKIX Roadmap <draft-ietf-pkix-roadmap-04.txt>

Here are some comments and change text proposals followed by some
typos (not all !) to prove that I skimmed through the draft. The
problem was to get the time to read it and comment on it. :-)

I would like to mention upfront that the draft is very valuable in
general, in particular for the sections related to the historical
construction and the naming constraints. However, ...  :-)

Page 9:  The text says: 

   Of course, if
   a true non-repudation service is to be provided additional
services
   that prove the data was actually in the possesion of the subject
   requesting the time stamp. So, the [DVCS] draft was developed to
   provide two mechaisms to prove the subject actually possed the
data.
   In addition, [DVCS] provides two additional services: one to
verify
   all signatures attached to the signed document using all
appropriate
   status information and PKCs and one to verify and assert the
validity
   of one or more PKCs at the specified time. Thoughtfully, [DVCS]
   permits the [TSP] protocol to be used as one of the time stamp
   tokens. 

I would propose instead: 

[DVCS] allows to verify and assert the validity of all signatures
attached to the signed document using all appropriate status
information and PKCs or to verify and assert the validity of one or
more PKCs at the specified time. 

Page 9: The text says:"

   [ETNPT] was developed to use [DCVS] to maintain the trust in a
token
   issued by a non-repudiation Trusted Third Party (NR TTP) after
the
   key initially used to establish trust in the token expires.

I would propose instead: 

[ETNPT]was proposed to maintain the trust in a token  issued by a
non-repudiation Trusted Third Party (NR TTP) after the key initially
used to establish trust in the token expires. However, since TSP
provides that service, its goal needs to be clarified.

Page 28: Section 4.5. Change the title into: "Time Stamp Protocols"

Page 39: Section on POP. It should be noticed that POP is NOT always
needed. For some (old) "poorly designed" protocols, POP is needed
when the SAME key is being used for authentication purposes and non
repudiation purposes. Basically, if the protocol makes sure that the
identifier of the public key certificate is protected by the end
user signature, then POP does not need to be performed by the CA.
For the case of encryption, see the proposed text replacement. Here
is a full text replacement for that topic:


5.2 POP

Proof of Possession, or POP, or also CA POP, means that the CA is
adequately convinced that the entity requesting a PKC containing a
public key Y has access to the private key X corresponding to that
public key.

There has been some debate whether POP was or not needed. 

This question needs to be addressed separately considering the
context of use of the key, in particular whether a key is used for
an authentication or non repudiation service, or in a
confidentiality service. Note that this does not map to the key
usage bit directly, since it is possible to use a confidentiality
key to perform an authentication service, e.g. by asking to decrypt
an encrypted challenge.

5.2.1 POP for Signing Keys

Suppose Alice legitimately has private key X and its corresponding
public key Y. Alice has a PKC from Charlie, a CA, containing Y.
Alice uses X to sign a transaction T. Without POP, Mal could also
get a PKC from Charlie containing the same public key, Y. Now, there
are two possible threats: Mal could claim to have been the real
signer of T; or Alice can falsely deny signing T, claiming that it
was instead Mal. Since no one can reliably prove that Mal did or did
not ever possess X, neither of these claims can be refuted, and thus
the service provided by and the confidence in the PKI has been
defeated. (Of course, if Mal really did possess X, Alice's private
key, then no POP mechanism in the world will help, but that is a
different problem.)

Protection can be gained by having Alice, as the true signer of the
transaction, include in the signed information her PKC or an
identifier of her PKC (e.g., a hash of her PKC). This makes
impossible for Mal to claim authorship because he does not know the
private key from Alice and thus is unable to include his certificate
under the signature.

The adequate protection may be obtained in the general case, by
mandating the inclusion of a reference of the certificate every time
a signature (or non repudiation) key is being used in a protocol.

However, because all the protocols were not doing so, a conservative
measure has been taken by requesting POP to be performed by CAs. It
should thus be understood, that this measure is not strictly
necessary and is only a temporary measure to make old protocols
secure. New protocols or data formats are being developed. If the
key being used is always used in a context where the identifier of
the certificate is included in the protocol, then POP by the CA is
not necessary. The inclusion of the identifier of the certificate in
the protocol or data format may be understood as POP being performed
at the transaction time rather than by the CA, at the registration
time of the user in the PKI.


5.2.2 POP for Key Management Keys

Suppose that Al is a new instructor in the Computer Science
Department of a local University. Al has created a draft final exam
for the Introduction to Networking course he is teaching. He wants
to send a copy of the draft final to Dorothy, the Department Head,
for her review prior to giving the exam. This exam will of course be
encrypted, as several students have access to the computer system.
However, a quick search of the PKC repository (e.g., search the
repository for all records with subjectPublicKey=Dorothy's-value)
turns up the fact that several students have PKCs containing the
same public key management key as Dorothy. At this point, if no POP
has been done by the CA, Al has no way of knowing whether all of the
students have simply created these PKCs without knowing the
corresponding private key (and thus it is safe to send the encrypted
exam to Dorothy), or whether the students have somehow acquired
Dorothy's private key (and thus it is certainly not safe to send the
exam). 

The later case may seem unsafe. However, if the other students have
acquired the key, they do not even need to publish their
certificates and can simply decrypt in parallel.

The end story is that, if the key only known to Dorothy, there is no
problem. Thus POP by the CA is not needed. 

If the key, like a Diffie-Hellman key, is used for an authentication
service the answer depends from the protocol being used. In the
former example, the decryption was done locally and no data was sent
back on the wire. In an authentication protocol, the story is
different because either some encrypted or decrypted data is sent
back. If the data sent back contains the identifier of the
certificate in a way that it cannot be modified without that
modification being detected, then there is no need for POP. On the
contrary, POP by the CA is needed.

As a conservative measure, POP for encryption keys is recommended,
but it should be realized that it is not always needed.

In general it should be noticed that POP at the time of the
transaction is much superior than POP made by the CA, since it is
possible in real time to be sure that everything is correct, rather
than rely on that verification to be done at the time of
registration by the CA. Should the CA fail in that verification,
then there is a security breach. On the contrary, doing POP at the
time of the transaction, eliminates that problem.

CMP requires that POP be provided for all keys, either through on-
line or out-of-band means. There are any number of ways to provide
POP, and the choice of which to use is a local matter. Additionally,
a PKC requester can provide POP to either a CA or to an RA, if the
RA can adequately assure the CA that POP has been performed. Some of
the acceptable ways to provide POP include [the following text has
been kept unchanged]:

 - Out-of-band means:

 - For keys generated by the CA or an RA (e.g., on a token such as
   a smart card or PCMCIA card), possession of the token can
   provide adequate proof of possession of the private key.

 - For user-generated keys, another approach can be used in
   environments where "key recovery" requirements force the
   requester to provide a copy of the private key to the CA or an
   RA. In this case, the CA will not issue the requested PKC until
   such time as the requester has provided the private key. This
   approach is in general not recommended, as it is extremely
   risky (e.g., the system designers need to figure out a way to
   protect the private keys from compromise while they are being
   sent to the CA/RA/other authority, and how to protect them
   there), but it can be used.

 - On-line means:

 - For signature keys that are generated by an EE, the requester
   of a PKC can be required to sign some piece of data (typically,
   the PKC request itself) using the private key. The CA will then
   use the requested public key to verify the signature. If the
   signature verification works, the CA can safely conclude that
   the requester had access to the private key. If the signature
   verification process fails, the CA can conclude that the
   requester did not have access to the correct private key, and
   reject the request.

 - For key management keys that are generated by the requester,
   the CA can send the user the requested public key, along with
   the CA's own private key, to encrypt some piece of data, and
   send it to the requester to be decrypted. For example, the CA
   can generate some random challenge, and require some action to
   be taken after decryption (e.g., "decrypt this encrypted random
   number and send it back to me"). If the requester does not take
   the requested action, the CA concludes that the requester did
   not possess the private key, and the PKC is not issued.

Page 42: Section 5.3.1  on the key usage bits. The story about the
digital signature and NR bit is not correct. Setting the NR bit does
NOT means that the Signature bit must be present. [FORMAT] is clear
on that topic. 4 th line from first paragraph. Remove "and/or
nonRepudiation" then after make "bit" singular (i.e. remove the s).

Page 43. In the note in the middle of the page, delete the sentence:
"However, the nonRepudiation key usage bit is provided as an
indicator that such keys should not be used as a component of a
system providing a non-repudiation service."

Page 43. About the discussion, starting with "According to
[SIMONETTI], ..." I would propose a global replacement until the end
of that topic:

" The intent is that the digitalSignature bit should be set when
what is desired is the ability to sign ephemeral transactions; e.g.,
for a single session authentication. These transactions are
"ephemeral" in the sense that they are important only while they are
in existence; after the session is terminated, there is no long-term
record of the digital signature and its properties kept. 

When something is intended to be kept for some period of time for
non repudiation purposes, the nonRepudiation bit shall be set. This
implies that an application will digitally sign something that may
be used for non repudiation purposes; this bit must be turn on. 

A question came whether it was appropriate to turn on both the
signature bit and the NR bit. It is possible to use the same key for
two different purposes, but there is some danger to do so, if it may
exist cases where the protocol invoking the signature key is not
fully known. In such a case, it could happen, that instead of asking
the signature of a challenge, the protocol could ask a signature
over a hash that represents the hash of some transaction. A signer
could then agree on the terms of that transaction, instead of
opening a door which would be the case if the challenge is correctly
signed. In order to avoid this kind of problem, two different keys
are recommended. However, if, when using the same key for two
different purposes, it can be made sure that such misuse of the key
cannot happen, then this is not a problem. Since in many cases, it
is difficult to make the verification and thus get that assurance, a
good practice is to set only one bit at a time and thus use two
different keys."


Page 44. Section 5.4. Trust model. IMO, the approach that is
described is not appropriate. Trust is not related to an entity CA,
but to the trust placed by the EE in the context of an application.
Also there is not ONE trust point necessarily, but several. The
choice is NOT between a TOP CA (which does not necessarily exist)
and the local CA of the EE. The whole section should be changed to
reflect this.

Proposed change :

" An important design decision is which trust pointS for a
particular application should be used by a particular EE. This
decision depends from the context of use, i.e. from the kind of
application being used. For example, in a SET transaction, the bank
sets a single trust point and the end user has no choice about this.
In a different context the user (or a domain administrator) may
select which trust points to use. 

More text might be needed along these lines. 


A few typos (not all):

Page 5: Sercurity
Page 7: refrnce, posess, complimentary.
Page 8: devloped
Page 9: mecaisms , possesion, possed, repudation,  "can produced" to
be replaced by "can be produced"
Page 13: informtoin
Page 21: In the sentence "[TSP] also defines" replace "defines" by
"defined".
Page 25: "Diffie-Hellman a key" to be replaced by "a Diffie-Hellman
key"


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13947 for <[e-mail]>; Fri, 29 Oct 1999 04:39:45 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18786; Fri, 29 Oct 1999 07:43:02 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-qc-02.txt
Date: Fri, 29 Oct 1999 07:43:02 -0400
Sender: [e-mail]

--NextPart

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

	Title           : Internet X.509 Public Key Infrastructure
			  Qualified Certificates
	Author(s)	: S. Santesson, W. Polk, P. Barzin, M. Nystrom
	Filename	: draft-ietf-pkix-qc-02.txt
	Pages		: 35
	Date		: 27-Oct-99
	
This document forms a certificate profile for Qualified Certificates,
based on RFC 2459, for use in the Internet. The term Qualified
Certificate is used to describe a certificate with a certain
qualified status within applicable governing law. Further, Qualified
Certificates are issued exclusively to physical persons represented
by a registered unmistakable identity.

The goal of this document is to define a general syntax independent
of local legal requirements. The profile is however designed to allow
further profiling in order to meet specific local needs.

It is important to note that the profile does not define any legal
requirements for Qualified Certificates.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-qc-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA08474 for <[e-mail]>; Fri, 29 Oct 1999 01:13:51 -0700 (PDT)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Fri, 29 Oct 1999 09:19:09 +0100
Received: from bowsy (bowsy.sse.ie [193.120.32.196]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id JAA01311; Fri, 29 Oct 1999 09:19:06 +0100 (BST)
Message-ID: <01c601bf21e5$f9c09b00$[e-mail]>
From: "Andy Dowling" <[e-mail]>
To: "Stephen Farrell (Baltimore)" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: LAAP performance issues
Date: Fri, 29 Oct 1999 09:16:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit

Hi Stephen, David

some suggestions on LAAP performance:

1. Batch LAAP requests. Perhaps the LAAPRequestMessage could be replaced
with
    a SEQUENCE of LAAPRequestMessage, so that a LRQ could request multiple
ACs
    with a single LAAP request? (The LRP would evaluate each
LAAPRequestMessage
    in the SEQUENCE individually). This could result in a saving of network
bandwidth in
    cases where a large volume of ACs is to be pulled over LAAP.

2.  Support for a "keep-alive" TCP connection between LRQ and LRP.
     One problem with this is that, at the socket layer, some LRP
implementations may
     timeout the socket after a couple of minutes of inactivity. Perhaps the
use of a "null"
     LAAP request could be used in order for the LRQ to force the connection
to stay
     alive at the socket layer. This seems like a strange idea, 'cos if the
LRP supports
     keep-alives then the LRP will set the to infinite lifetime anyway.
Nonetheless, comments
     on this would be appreciated....

Thanks,

Andy

-----
Andy Dowling
SSE (A Siemens Company)
Fitzwilliam Court, Leeson Close,
Dublin 2, Ireland

E-Mail:  [e-mail]
Web: http://www.sse.ie
Phone: [phone]
Fax:   [phone]



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19594 for <[e-mail]>; Thu, 28 Oct 1999 18:03:59 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id SAA00375; Thu, 28 Oct 1999 18:04:49 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id SAA12708; Thu, 28 Oct 1999 18:06:03 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <VH4XD37X>; Thu, 28 Oct 1999 18:06:27 -0700
Message-ID: <[e-mail]>
From: Alex Deacon <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: DisplayText for Verisign Certificate
Date: Thu, 28 Oct 1999 18:06:18 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

FYI,

It looks like the proposed son-of-rfc2459 draft
(draft-ietf-pkix-new-part1-00.txt) has addressed this issue by adding
IA5String as an additional CHOICE for DisplayText.

Alex

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Saturday, October 16, 1999 1:29 AM
> To: [e-mail]
> Subject: Re: DisplayText for Verisign Certificate
> 
> 
> "Amit Kapoor" <[e-mail]> writes:
> 
> >While working with Bob Jueneman on some S/MIME certificate 
> issues we ran 
> >into the following with a Verisign issued certificate:
> >
> >The portion of ASN.1 dump showing the problem:
> >
> >Verisign is encoding the DisplayText as IA5 whereas 
> according to 2459 it can 
> >be one of Visible, BMP or UTF8 string.
> >
> >Should we add IA5String to the choice list of DisplayText or 
> treat this as a 
> >error and not support the Verisign certificates?
> 
> This was quietly changed between the final draft and the RFC, 
> as a result of 
> this some implementations expect one and some expect the other.  The 
> workaround I've got in my code is:
> 
> /* All draft versions of the PKIX profile had the organization as an
>    IA5String, but the final RFC changed it to a 
> VisibleString, in order
>    to kludge around this for the certs which use an IA5String 
> (which in
>    practice means only Verisign, since noone else uses seems 
> to use policy
>    qualifiers), we allow both types but put the VisibleString option
>    first which means it'll get used preferentially when encoding */
> 
> The code comment explains why it appears to be a Verisign bug 
> (but isn't), 
> noone else seems to use qualifiers so you won't see it 
> anywhere else, and 
> what Verisign were doing was correct at the time they did it. 
>  I should 
> really put this in the style guide.
> 
> Peter.
> 


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16253 for <[e-mail]>; Thu, 28 Oct 1999 14:06:39 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id OAA19949; Thu, 28 Oct 1999 14:07:28 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id OAA02934; Thu, 28 Oct 1999 14:08:44 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <VH4XDMPP>; Thu, 28 Oct 1999 14:09:06 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, [e-mail]
Subject: RE: New draft - NULL Public Key Signatures
Date: Thu, 28 Oct 1999 14:08:57 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Ambarish,

That's what I'd concluded from reading the draft, but I wanted to ask to be
certain.

Mike


> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Thursday, October 28, 1999 11:19 AM
> To: Michael Myers; Ambarish Malpani; [e-mail]
> Subject: RE: New draft - NULL Public Key Signatures
> 
> 
> 
> Hi Mike,
>     Good question.
> 
> Actually, if you read the draft, you actually might be able to
> figure out that it is independent of X.509 or other certificates.
> Just as RSA can work fine with any format of certification.
> 
> But still, a very good question.
> 
> Regards,
> Ambarish
> 
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 
> > -----Original Message-----
> > From: Michael Myers [mailto:[e-mail]]
> > Sent: Thursday, October 28, 1999 9:08 AM
> > To: Ambarish Malpani; [e-mail]
> > Subject: RE: New draft - NULL Public Key Signatures
> > 
> > 
> > Ambarish,
> > 
> > Does this proposal require X.509 certificates?  Or is it the 
> > case that the
> > draft, when finalized, will propose a non-X.509 approach to 
> public key
> > management?
> > 
> > Mike
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Ambarish Malpani [mailto:[e-mail]]
> > > Sent: Tuesday, October 19, 1999 4:16 PM
> > > To: [e-mail]
> > > Subject: New draft - NULL Public Key Signatures
> > > 
> > > 
> > > 
> > > Hi Guys,
> > >     Given the traffic on this list, it sounds like this IETF is
> > > going to be a pretty boring one. :-)
> > > 
> > > I have just submitted an individual draft about NULL Public Key
> > > Signatures, which I hope will be part of this working group soon
> > > (make things at the PKIX meeting more interesting).
> > > 
> > > The main (serious) reason for this draft, is to allow people to
> > > describe data items that may be signed or unsigned more easily
> > > in ASN.1.
> > > 
> > > Also, having a NULL algorithm is asthetically pleasing.
> > > 
> > > So here it is.
> > > 
> > > Please send all your flames/comments to this list.
> > > 
> > > Thanks,
> > > Ambarish
> > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > Ambarish Malpani
> > > Architect                                                
> > 650.567.5457
> > > ValiCert, Inc.                                  
> > [e-mail]
> > > 1215 Terra Bella Ave.                         
> http://www.valicert.com
> > Mountain View, CA 94043-1833
> > 
> > 
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12981 for <[e-mail]>; Thu, 28 Oct 1999 11:18:05 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VN6JP7N7>; Thu, 28 Oct 1999 11:19:15 -0700
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: Michael Myers <[e-mail]>, Ambarish Malpani <[e-mail]>, [e-mail]
Subject: RE: New draft - NULL Public Key Signatures
Date: Thu, 28 Oct 1999 11:19:14 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Mike,
    Good question.

Actually, if you read the draft, you actually might be able to
figure out that it is independent of X.509 or other certificates.
Just as RSA can work fine with any format of certification.

But still, a very good question.

Regards,
Ambarish


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


> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Thursday, October 28, 1999 9:08 AM
> To: Ambarish Malpani; [e-mail]
> Subject: RE: New draft - NULL Public Key Signatures
> 
> 
> Ambarish,
> 
> Does this proposal require X.509 certificates?  Or is it the 
> case that the
> draft, when finalized, will propose a non-X.509 approach to public key
> management?
> 
> Mike
> 
> 
> 
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[e-mail]]
> > Sent: Tuesday, October 19, 1999 4:16 PM
> > To: [e-mail]
> > Subject: New draft - NULL Public Key Signatures
> > 
> > 
> > 
> > Hi Guys,
> >     Given the traffic on this list, it sounds like this IETF is
> > going to be a pretty boring one. :-)
> > 
> > I have just submitted an individual draft about NULL Public Key
> > Signatures, which I hope will be part of this working group soon
> > (make things at the PKIX meeting more interesting).
> > 
> > The main (serious) reason for this draft, is to allow people to
> > describe data items that may be signed or unsigned more easily
> > in ASN.1.
> > 
> > Also, having a NULL algorithm is asthetically pleasing.
> > 
> > So here it is.
> > 
> > Please send all your flames/comments to this list.
> > 
> > Thanks,
> > Ambarish
> > 
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [e-mail]
> > 1215 Terra Bella Ave.                         
http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 


Received: from www.certifeidtime.com. (test.glassey.com [207.126.98.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA11037 for <[e-mail]>; Thu, 28 Oct 1999 09:25:19 -0700 (PDT)
Received: from gw by www.certifeidtime.com. (SMI-8.6/SMI-SVR4) id JAA03094; Thu, 28 Oct 1999 09:29:27 -0700
Message-ID: <008501bf2161$7ad70740$[e-mail]>
From: "Todd Glassey @ GMT" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Another DoS attack. - potantial CMS additon
Date: Thu, 28 Oct 1999 09:28:33 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi all,  the forwarded letter is regarding a denial of service attack mode
in IPsec negotiations. We also have similar issues in commercial transaction
processing with the same attack vector.

----- Original Message -----
From: Tamir Zegman <[e-mail]>
To: ipsec <[e-mail]>; ipsra <[e-mail]>
Sent: Thursday, October 28, 1999 01:40 AM
Subject: Another DoS attack.


> I'm posting this message to both mailing lists as this issue concerns
> them both.
>
> An attacker using either aggressive, main or base mode can send a
> certificate whose RSA public key consists of a long modulus (16384) and
> a non trivial exponent.

This is an interesting reazilzation that I believe may have real-world
consequences in the sucessfull operation of commercial PKI systems. The
issue is Denial of Service by flooding the exponetiation engine's input
queue with massive key structures and thus overloading the local processor.

> The responder will be left to do the exponentiation till hell freezes
> unless of course his implementation limits the length of public key
> signatures it is willing to verify.

In a number of the protocols we are working I would suggest that we should
also on address this by allowing a policy control of the maximum size of
expected key structures... this may be something to add to CMS before it
goes final. Also the TS protocol will need some sort of control to prevent
this abuse model.

> A similar attack can be mounted using DSA.
> This attack can be extended to other online protocols that use
> certificates in which the responder is asked to verify a public key
> signature.

anyone else see the light in this tunnel?

Todd





Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10706 for <[e-mail]>; Thu, 28 Oct 1999 09:05:14 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA03266; Thu, 28 Oct 1999 09:06:02 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA12152; Thu, 28 Oct 1999 09:07:18 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <VH4XDJ1C>; Thu, 28 Oct 1999 09:07:41 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Ambarish Malpani <[e-mail]>, [e-mail]
Subject: RE: New draft - NULL Public Key Signatures
Date: Thu, 28 Oct 1999 09:07:36 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Ambarish,

Does this proposal require X.509 certificates?  Or is it the case that the
draft, when finalized, will propose a non-X.509 approach to public key
management?

Mike



> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Tuesday, October 19, 1999 4:16 PM
> To: [e-mail]
> Subject: New draft - NULL Public Key Signatures
> 
> 
> 
> Hi Guys,
>     Given the traffic on this list, it sounds like this IETF is
> going to be a pretty boring one. :-)
> 
> I have just submitted an individual draft about NULL Public Key
> Signatures, which I hope will be part of this working group soon
> (make things at the PKIX meeting more interesting).
> 
> The main (serious) reason for this draft, is to allow people to
> describe data items that may be signed or unsigned more easily
> in ASN.1.
> 
> Also, having a NULL algorithm is asthetically pleasing.
> 
> So here it is.
> 
> Please send all your flames/comments to this list.
> 
> Thanks,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06993 for <[e-mail]>; Thu, 28 Oct 1999 05:13:41 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id FAA23572; Thu, 28 Oct 1999 05:08:21 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 27 Oct 1999 16:40:55 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: QC certificates and Nationality
Cc: "'SEIS-List'" <[e-mail]>
In-Reply-To: <000801bf1f09$c9fbeac0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

What goes into the QC when a person is a citizen of more than one country?

Russ


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06558 for <[e-mail]>; Thu, 28 Oct 1999 04:51:20 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial07.spyrus.com [207.212.34.127]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id EAA23179 for <[e-mail]>; Thu, 28 Oct 1999 04:46:10 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 27 Oct 1999 11:44:24 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-pkix-ipki-ecdsa-02.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Given that RFC 2459 must be updated, I suggest that these specification be 
folded into the updated RFC 2459. I do not think that a separate document 
adds value.

Russ

==========

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

	Title		: Internet X.509 Public Key Infrastructure
                           Representation of Elliptic Curve Digital 
Signature
                           Algorithm (ECDSA) Keys and Signatures in 
Internet
                           X.509 Public Key Infrastructure Certificates
	Author(s)	: L. Bassham, D. Johnson, W. Polk
	Filename	: draft-ietf-pkix-ipki-ecdsa-02.txt
	Pages		: 15
	Date		: 22-Oct-99
	
This is the third draft of a profile for specification of Elliptic
Curve Digital Signature Algorithm (ECDSA) keys and signatures in
Internet Public Key Infrastructure X.509 certificates and certificate
revocation lists. This specification is an addendum to RFC 2459;
implementations must also conform to RFC 2459.  In addition, this
document references ANSI X9.62 for the specification of the ECDSA
algorithm.  This specification only addresses the format of ECDSA
keys and signatures.  Please send comments on this document to the
[e-mail] mail list.



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06146 for <[e-mail]>; Thu, 28 Oct 1999 04:26:30 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14905; Thu, 28 Oct 1999 07:29:43 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-qc-02.txt
Date: Thu, 28 Oct 1999 07:29:42 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Qualified Certificates
	Author(s)	: S. Santesson, T. Polk, P. Barzin,  M. Nystrom
	Filename	: draft-ietf-pkix-qc-02.txt
	Pages		: 35
	Date		: 27-Oct-99
	
This document forms a certificate profile for Qualified Certificates,
based on RFC 2459, for use in the Internet. The term Qualified
Certificate is used to describe a certificate with a certain
qualified status within applicable governing law. Further, Qualified
Certificates are issued exclusively to physical persons represented
by a registered unmistakable identity.

The goal of this document is to define a general syntax independent
of local legal requirements. The profile is however designed to allow
further profiling in order to meet specific local needs.

It is important to note that the profile does not define any legal
requirements for Qualified Certificates.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-qc-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from Server (dialup-209.245.71.89.LosAngeles1.Level3.net [209.245.71.89]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA24386; Wed, 27 Oct 1999 20:17:37 -0700 (PDT)
From: [e-mail]
Subject: The best long distance International rates
Date: Wed, 27 Oct 1999 16:45:04
Message-Id: <261.280024.57549@Server>

Hi, 

  10-10-629 is your NUMBER to MAKE MONEY while SAVING MONEY!
Just dial 10-10-629 + 1 + Tel. No + Code(212570),
Code on your First Call Only!

  I have exciting new for you! I am an IndependentRepresentative 
for WorldxChange Communications, one of the world's leaders in 
discounted long distance service.  My friends and family are 
enjoying the benefits of WxC's service and I wanted to pass them 
along to you.  How does 5 cents a minute sound?  We also have the 
best International rates.

More information see our website:
                      http://www.worldxchange.com/agent/212570

Please contact me at:[e-mail] as soon as possible so 
you can start taking advantage of these low rates on your next 
call.  There is no set-up fee and no contracts to sign.  Just 
dial the number and use my agent activation number (212570) on 
your first call.  Or, you can pre-subscribe for additional 
options. It's that easy.

Thank for your help, and I look forward to contact you.

Sincerely,

   Ben

Independent Representative
Worldxchange Communications







 
 
 
 
 
 
 
 
 
 
 
 
 


Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14384 for <[e-mail]>; Wed, 27 Oct 1999 14:16:10 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1460.8) id <4MW7VG3L>; Wed, 27 Oct 1999 17:16:01 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E4A9B64@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Peter Williams'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: CRL Distribution Points
Date: Wed, 27 Oct 1999 17:16:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"

I interpret RFC 2459, Section 5  to mean that the relying parties may
encounter ARL, DP CRL, and delta CRL.  Given that, the entire text of Annex
is pertinent to 2459, not just the check for indirect CRL issuer.  This can
be done either by reference or by inclusion.


-----Original Message-----
From: Peter Williams [mailto:[e-mail]]
Sent: Wednesday, October 27, 1999 3:23 PM
To: Santosh Chokhani; 'Russ Housley'; [e-mail]
Subject: RE: CRL Distribution Points


ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.doc

At your suggestion I have reviewed the above-identified
amendment text.

For those who only want the bottom line of this mail, here it is:

	I suggest that a simple statement is added to that which 
	Russ has already 	drafted: it should state that 
	"X.509 processing of the crlIssuer field is REQUIRED, if
	present".


Annex M review, for the purpose or understanding Russ' request
for comment in light of Annex M:

I note, that wherever CA was formally, used,
the more general term "authority" is now substituted.
Authority is defined as CA or AA.

I note that the concepts of CrlDistribution Point
have not changed by amendment from the 
X.509 version used by 2459.

I do note that the whole concept of DPs has
been extended to the PMI, which is not part
of 2459 work. I ignored everything in 13.14
as out of review scope, for now.

Annex M1.1 states the CRL types, and helps
out the new scope idea, which is not part
of this review.

Annex M.2 specifies a logical procedure for
selecting CRL processing, based on CRL reliance
policy, defined in the CP.

Annex M.3 states the rules for selecting a CRL
from the various flavors available, according to 
various  requirements. The annex makes it
clear that 1 or more of the several DPs provided can 
be used when DP processing is appropriate.

The concept of dominance and freshness, nicely allows
the IBM override of VeriSign that I described,
whether or not cRLIssuer processing is used.

M.5.1.4 addresses one interaction of cert-based DP
signals and CRL-hosted DP signals. 

The first bullet points out a alternative matching rule 
covering DPName, or the optional CrlIssuer name. Either match is acceptable.

The last bullet states the crlIssuer rule I stated originally.

Annex M is very nice piece of work, which makes it easier
to do what the market requires.

Annex M is completely consistent with my argument, and
does not change the way X.509 has handled cRLIssuer
and indirect CRL signals.

Russ should ensure that his overloading of semantics
on the cRLissuer field continue require that the
base X.509 rules are followed, as stated in X.509
and even more forcefully stated in Annex M.5.1.4
of the FPDAM.
 
Is that a fair review and conclusion, tuned to the question 
posed?

The review only reinforced my original conclusion. Let
me know if I have made an error in my reasoning, or 
if there are other factors in play.  I just do
not want PKIX to be non-conforming with X.509.

I suggest that a simple statement is added to that which 
Russ has already 	drafted: it should state that 
"X.509 processing of the crlIssuer field is REQUIRED, if
present".

Thanks for insisting we all review Annex M. Persistence
in leadership does pay dividends.

Peter.







that indirect issuance is the same as used in the 






> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Wednesday, October 27, 1999 11:18 AM
> To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> [e-mail]
> Subject: RE: CRL Distribution Points
> 
> 
> Peter:
> 
> You really need to carefully review the Annex M in the draft. 
>  That should
> explain it all.  If you find incompleteness, errors or 
> inconsistencies in
> that Annex, please let me know.  We would be interested in 
> making that Annex
> as complete and accurate as possible.
> 
> 
> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Wednesday, October 27, 1999 2:16 PM
> To: Santosh Chokhani; 'Russ Housley'; [e-mail]
> Subject: RE: CRL Distribution Points
> 
> 
> 
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Wednesday, October 27, 1999 8:16 AM
> > To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> > [e-mail]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Peter:
> > 
> > My interpretation of the statement is that the issuer name in the
> > certificate should match the issuer name in the CRL.
> 
> This interpretation interferes with the X.509 specification which
> enables use of ANY independently-named (validation) authority.  The 
> CrIssuer field signals the identity  and intended use of a given 
> authority  to relying parties, when optionally present. If the
> cRLIssuer value is not present, the default rule you mention 
> above controls. Otherwise "the issuer name in the
> **cRLIssuer** value should match the issuer name in the CRL."
> 
> Let us also note that the name of the CRLDP, when the
> RDN flavour is used, is subordinate to the **CRL issuer**,
> as identififed using the CrlIssuer Rule, if one
> is performing conforming processing. The cRLIssuer
> is identified using the processing summarized above.
> 
> Why cannot we do the simple thing, and just implement
> what X.509 specifies? Its hardly contentious, its
> not hard,  and has already been ratified by the ISO voting 
> process, which included a PKIX voice.
> 
> Lets now advocate the case, with famous-name examples to
> make the case easier to follow:
> 
> Case
> ----
> 
> Folk have quite widely adopted the separation of power idea
> between CAs and VAs (or those who indirectly
> issug CRLs). Enterprises WANT to be able to
> issue a local/extranet CRL, that controls whether a VeriSign
> public certificate is flagged suspended in that
> relying-party domain.
> 
> Taking IBM as the example enterprise customer that chooses
> to quite normally outsource its ceritifcate manufacturing to
> VeriSign, IBM may well wish to have VeriSign indicate
> the users of IBM certificates should use a given , non-VeriSign
> CRL issuer, identified in the CrlIssuer name using
> an DN selected in the IBM corporate DN-name space. 
> 
> Policies for issuing IBM's indirect CRL would meet IBM 
> guidelines, which may be more stringent than the those used by
> VeriSign. Furthermore, for IBM is likely to have 
> a significantly more realtime data at its RAs concerning
> revocation/suspension data than VeriSign has, or has yet 
> accepted for processing under its own CPS rules.  
> 
> Whether IBM or an outsource VA operate the IBM
> CrlIssuer is an operational choice, much like
> any decision to deploy a product server on
> the IBM LAN, or use a service provider.
> 
> 
> Conclusion, to date:
> -------------------
> 
> The model argued above is what the cRLIssuer field
> was designed for; processing must comply for a
> user cert validation result to be conforming with X.509,
> and for the allied process of confirming a certificate chain
> to be similarly conforming.
> 
> I have no particular objection, if it is
> technically appropriate, for PKIX to overload the CrlIssuer
> signal with Russ' meanings
> 
> But one cannot simple replace
> the original processing requirements with an
> interpretative wave of the PKIX magic wand, and 
> still be able to interwork securely with 
> correctly-implemented X.509 certificate-using 
> systems now widespread.
> 
> Peter.
> 
> > 
> > -----Original Message-----
> > From: Peter Williams [mailto:[e-mail]]
> > Sent: Tuesday, October 26, 1999 8:35 PM
> > To: Santosh Chokhani; Peter Williams; 'Russ Housley'; 
> > [e-mail]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > 
> >  
> > > Peter:
> > > 
> > > The issuer of the CRL should be identified from issuer name 
> > > field in the CRL
> > > and not based on what directory entry or what attribute you 
> > > queried.  The
> > > directory is not trusted, the network is not trusted, and 
> > > there is no strong
> > > binding between the attribute value and the object/attribute.
> > 
> > But, from the standard(12.6.2	Certificate extension fields)
> > at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc
> > 
> > "The cRLIssuer component identifies the authority that issues 
> > and signs the
> > CRL. If this component is absent, the CRL issuer name 
> defaults to the
> > certificate issuer name."
> > 
> > I assume we are going to comply with X.509 concerning
> > the rules for identifying the issuer of a CRL, as given
> > above.  If not, the security section of son-of-2459 should
> > identify that PKIX validation processing is non-conforming with
> > the ISO standard.  
> >  
> > Peter.
> > 
> > 
> > > -----Original Message-----
> > > From: Peter Williams [mailto:[e-mail]]
> > > Sent: Tuesday, October 26, 1999 8:02 PM
> > > To: Santosh Chokhani; 'Russ Housley'; [e-mail]
> > > Subject: RE: CRL Distribution Points
> > > 
> > > 
> > > Russ,
> > > 
> > > You need to ensure that an indirect issuer of the
> > > CRL fragment can be identified, so that the signature
> > > can be appropriately verified, as per the X.509 model.
> > > 
> > > How would we do that with your standard today? - whilst
> > > also pointing to the location of the value in 
> > > a directory/uri-resolver?
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > Sent: Tuesday, October 26, 1999 4:39 PM
> > > > To: 'Russ Housley'; [e-mail]
> > > > Subject: RE: CRL Distribution Points
> > > > 
> > > > 
> > > > Russ:
> > > > 
> > > > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > > > idea to include
> > > > Annex M, point to it or borrow the applicable sections in the 
> > > > PKIX RFC.
> > > > 
> > > > -----Original Message-----
> > > > From: Russ Housley [mailto:[e-mail]]
> > > > Sent: Tuesday, October 26, 1999 12:58 PM
> > > > To: [e-mail]
> > > > Subject: CRL Distribution Points
> > > > 
> > > > 
> > > > In reviewing the document that Tim recently posted, I 
> > > > realized that we were 
> > > > not really clear about the semantics of a DistributionPoint 
> > > > with an absent 
> > > > distributionPoint, a present reasons, and a present 
> > > > cRLIssuer.  The ASN.1 
> > > > is repeated below for those who have not memorized it.
> > > > 
> > > > If the cRLDistributionPoints extension does not contain a 
> > > > DistributionPointName, but does contain a cRLIssuer, then 
> > following 
> > > > semantics MUST be assumed:
> > > > 
> > > > 1) If the cRLIssuer is of type directoryName, then the 
> > > > certificateRevocationList attribute in the Directory entry of 
> > > > the cRLIssuer 
> > > > contains the current CRL for the associated reasons.
> > > > 
> > > > 2) If the cRLIssuer is of type URI, then the URI is a 
> > > pointer to the 
> > > > current CRL for the associated reasons.  The expected values 
> > > > for the URI 
> > > > are those defined in 4.2.1.7.
> > > > 
> > > > 3) Processing rules for other values are not defined by this 
> > > > specification.
> > > > 
> > > > Does this seem right?
> > > > 
> > > > Russ
> > > > 
> > > > = = = = = = = = = =
> > > > 
> > > >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > > > DistributionPoint
> > > > 
> > > >     DistributionPoint ::= SEQUENCE {
> > > >          distributionPoint       [0]     
> > > > DistributionPointName OPTIONAL,
> > > >          reasons                 [1]     ReasonFlags OPTIONAL,
> > > >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > > > 
> > > >     DistributionPointName ::= CHOICE {
> > > >          fullName                [0]     GeneralNames,
> > > >          nameRelativeToCRLIssuer [1]     
> > RelativeDistinguishedName }
> > > > 
> > > >     ReasonFlags ::= BIT STRING {
> > > >          unused                  (0),
> > > >          keyCompromise           (1),
> > > >          cACompromise            (2),
> > > >          affiliationChanged      (3),
> > > >          superseded              (4),
> > > >          cessationOfOperation    (5),
> > > >          certificateHold         (6) }
> > > > 
> > > 
> > 
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12903 for <[e-mail]>; Wed, 27 Oct 1999 12:21:37 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VN6JP58Z>; Wed, 27 Oct 1999 12:22:49 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: CRL Distribution Points
Date: Wed, 27 Oct 1999 12:22:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.doc

At your suggestion I have reviewed the above-identified
amendment text.

For those who only want the bottom line of this mail, here it is:

	I suggest that a simple statement is added to that which 
	Russ has already 	drafted: it should state that 
	"X.509 processing of the crlIssuer field is REQUIRED, if
	present".


Annex M review, for the purpose or understanding Russ' request
for comment in light of Annex M:

I note, that wherever CA was formally, used,
the more general term "authority" is now substituted.
Authority is defined as CA or AA.

I note that the concepts of CrlDistribution Point
have not changed by amendment from the 
X.509 version used by 2459.

I do note that the whole concept of DPs has
been extended to the PMI, which is not part
of 2459 work. I ignored everything in 13.14
as out of review scope, for now.

Annex M1.1 states the CRL types, and helps
out the new scope idea, which is not part
of this review.

Annex M.2 specifies a logical procedure for
selecting CRL processing, based on CRL reliance
policy, defined in the CP.

Annex M.3 states the rules for selecting a CRL
from the various flavors available, according to 
various  requirements. The annex makes it
clear that 1 or more of the several DPs provided can 
be used when DP processing is appropriate.

The concept of dominance and freshness, nicely allows
the IBM override of VeriSign that I described,
whether or not cRLIssuer processing is used.

M.5.1.4 addresses one interaction of cert-based DP
signals and CRL-hosted DP signals. 

The first bullet points out a alternative matching rule 
covering DPName, or the optional CrlIssuer name. Either match is acceptable.

The last bullet states the crlIssuer rule I stated originally.

Annex M is very nice piece of work, which makes it easier
to do what the market requires.

Annex M is completely consistent with my argument, and
does not change the way X.509 has handled cRLIssuer
and indirect CRL signals.

Russ should ensure that his overloading of semantics
on the cRLissuer field continue require that the
base X.509 rules are followed, as stated in X.509
and even more forcefully stated in Annex M.5.1.4
of the FPDAM.
 
Is that a fair review and conclusion, tuned to the question 
posed?

The review only reinforced my original conclusion. Let
me know if I have made an error in my reasoning, or 
if there are other factors in play.  I just do
not want PKIX to be non-conforming with X.509.

I suggest that a simple statement is added to that which 
Russ has already 	drafted: it should state that 
"X.509 processing of the crlIssuer field is REQUIRED, if
present".

Thanks for insisting we all review Annex M. Persistence
in leadership does pay dividends.

Peter.







that indirect issuance is the same as used in the 






> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Wednesday, October 27, 1999 11:18 AM
> To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> [e-mail]
> Subject: RE: CRL Distribution Points
> 
> 
> Peter:
> 
> You really need to carefully review the Annex M in the draft. 
>  That should
> explain it all.  If you find incompleteness, errors or 
> inconsistencies in
> that Annex, please let me know.  We would be interested in 
> making that Annex
> as complete and accurate as possible.
> 
> 
> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Wednesday, October 27, 1999 2:16 PM
> To: Santosh Chokhani; 'Russ Housley'; [e-mail]
> Subject: RE: CRL Distribution Points
> 
> 
> 
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Wednesday, October 27, 1999 8:16 AM
> > To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> > [e-mail]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Peter:
> > 
> > My interpretation of the statement is that the issuer name in the
> > certificate should match the issuer name in the CRL.
> 
> This interpretation interferes with the X.509 specification which
> enables use of ANY independently-named (validation) authority.  The 
> CrIssuer field signals the identity  and intended use of a given 
> authority  to relying parties, when optionally present. If the
> cRLIssuer value is not present, the default rule you mention 
> above controls. Otherwise "the issuer name in the
> **cRLIssuer** value should match the issuer name in the CRL."
> 
> Let us also note that the name of the CRLDP, when the
> RDN flavour is used, is subordinate to the **CRL issuer**,
> as identififed using the CrlIssuer Rule, if one
> is performing conforming processing. The cRLIssuer
> is identified using the processing summarized above.
> 
> Why cannot we do the simple thing, and just implement
> what X.509 specifies? Its hardly contentious, its
> not hard,  and has already been ratified by the ISO voting 
> process, which included a PKIX voice.
> 
> Lets now advocate the case, with famous-name examples to
> make the case easier to follow:
> 
> Case
> ----
> 
> Folk have quite widely adopted the separation of power idea
> between CAs and VAs (or those who indirectly
> issug CRLs). Enterprises WANT to be able to
> issue a local/extranet CRL, that controls whether a VeriSign
> public certificate is flagged suspended in that
> relying-party domain.
> 
> Taking IBM as the example enterprise customer that chooses
> to quite normally outsource its ceritifcate manufacturing to
> VeriSign, IBM may well wish to have VeriSign indicate
> the users of IBM certificates should use a given , non-VeriSign
> CRL issuer, identified in the CrlIssuer name using
> an DN selected in the IBM corporate DN-name space. 
> 
> Policies for issuing IBM's indirect CRL would meet IBM 
> guidelines, which may be more stringent than the those used by
> VeriSign. Furthermore, for IBM is likely to have 
> a significantly more realtime data at its RAs concerning
> revocation/suspension data than VeriSign has, or has yet 
> accepted for processing under its own CPS rules.  
> 
> Whether IBM or an outsource VA operate the IBM
> CrlIssuer is an operational choice, much like
> any decision to deploy a product server on
> the IBM LAN, or use a service provider.
> 
> 
> Conclusion, to date:
> -------------------
> 
> The model argued above is what the cRLIssuer field
> was designed for; processing must comply for a
> user cert validation result to be conforming with X.509,
> and for the allied process of confirming a certificate chain
> to be similarly conforming.
> 
> I have no particular objection, if it is
> technically appropriate, for PKIX to overload the CrlIssuer
> signal with Russ' meanings
> 
> But one cannot simple replace
> the original processing requirements with an
> interpretative wave of the PKIX magic wand, and 
> still be able to interwork securely with 
> correctly-implemented X.509 certificate-using 
> systems now widespread.
> 
> Peter.
> 
> > 
> > -----Original Message-----
> > From: Peter Williams [mailto:[e-mail]]
> > Sent: Tuesday, October 26, 1999 8:35 PM
> > To: Santosh Chokhani; Peter Williams; 'Russ Housley'; 
> > [e-mail]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > 
> >  
> > > Peter:
> > > 
> > > The issuer of the CRL should be identified from issuer name 
> > > field in the CRL
> > > and not based on what directory entry or what attribute you 
> > > queried.  The
> > > directory is not trusted, the network is not trusted, and 
> > > there is no strong
> > > binding between the attribute value and the object/attribute.
> > 
> > But, from the standard(12.6.2	Certificate extension fields)
> > at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc
> > 
> > "The cRLIssuer component identifies the authority that issues 
> > and signs the
> > CRL. If this component is absent, the CRL issuer name 
> defaults to the
> > certificate issuer name."
> > 
> > I assume we are going to comply with X.509 concerning
> > the rules for identifying the issuer of a CRL, as given
> > above.  If not, the security section of son-of-2459 should
> > identify that PKIX validation processing is non-conforming with
> > the ISO standard.  
> >  
> > Peter.
> > 
> > 
> > > -----Original Message-----
> > > From: Peter Williams [mailto:[e-mail]]
> > > Sent: Tuesday, October 26, 1999 8:02 PM
> > > To: Santosh Chokhani; 'Russ Housley'; [e-mail]
> > > Subject: RE: CRL Distribution Points
> > > 
> > > 
> > > Russ,
> > > 
> > > You need to ensure that an indirect issuer of the
> > > CRL fragment can be identified, so that the signature
> > > can be appropriately verified, as per the X.509 model.
> > > 
> > > How would we do that with your standard today? - whilst
> > > also pointing to the location of the value in 
> > > a directory/uri-resolver?
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > Sent: Tuesday, October 26, 1999 4:39 PM
> > > > To: 'Russ Housley'; [e-mail]
> > > > Subject: RE: CRL Distribution Points
> > > > 
> > > > 
> > > > Russ:
> > > > 
> > > > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > > > idea to include
> > > > Annex M, point to it or borrow the applicable sections in the 
> > > > PKIX RFC.
> > > > 
> > > > -----Original Message-----
> > > > From: Russ Housley [mailto:[e-mail]]
> > > > Sent: Tuesday, October 26, 1999 12:58 PM
> > > > To: [e-mail]
> > > > Subject: CRL Distribution Points
> > > > 
> > > > 
> > > > In reviewing the document that Tim recently posted, I 
> > > > realized that we were 
> > > > not really clear about the semantics of a DistributionPoint 
> > > > with an absent 
> > > > distributionPoint, a present reasons, and a present 
> > > > cRLIssuer.  The ASN.1 
> > > > is repeated below for those who have not memorized it.
> > > > 
> > > > If the cRLDistributionPoints extension does not contain a 
> > > > DistributionPointName, but does contain a cRLIssuer, then 
> > following 
> > > > semantics MUST be assumed:
> > > > 
> > > > 1) If the cRLIssuer is of type directoryName, then the 
> > > > certificateRevocationList attribute in the Directory entry of 
> > > > the cRLIssuer 
> > > > contains the current CRL for the associated reasons.
> > > > 
> > > > 2) If the cRLIssuer is of type URI, then the URI is a 
> > > pointer to the 
> > > > current CRL for the associated reasons.  The expected values 
> > > > for the URI 
> > > > are those defined in 4.2.1.7.
> > > > 
> > > > 3) Processing rules for other values are not defined by this 
> > > > specification.
> > > > 
> > > > Does this seem right?
> > > > 
> > > > Russ
> > > > 
> > > > = = = = = = = = = =
> > > > 
> > > >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > > > DistributionPoint
> > > > 
> > > >     DistributionPoint ::= SEQUENCE {
> > > >          distributionPoint       [0]     
> > > > DistributionPointName OPTIONAL,
> > > >          reasons                 [1]     ReasonFlags OPTIONAL,
> > > >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > > > 
> > > >     DistributionPointName ::= CHOICE {
> > > >          fullName                [0]     GeneralNames,
> > > >          nameRelativeToCRLIssuer [1]     
> > RelativeDistinguishedName }
> > > > 
> > > >     ReasonFlags ::= BIT STRING {
> > > >          unused                  (0),
> > > >          keyCompromise           (1),
> > > >          cACompromise            (2),
> > > >          affiliationChanged      (3),
> > > >          superseded              (4),
> > > >          cessationOfOperation    (5),
> > > >          certificateHold         (6) }
> > > > 
> > > 
> > 
> 


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11527 for <[e-mail]>; Wed, 27 Oct 1999 11:19:26 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhmtt00767; Wed, 27 Oct 1999 18:22:27 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA05041; Wed, 27 Oct 99 14:20:31 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA14549; Wed, 27 Oct 1999 14:22:25 -0400
Date: Wed, 27 Oct 1999 14:22:25 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: New draft - NULL Public Key Signatures
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Ambarish" == Ambarish Malpani <[e-mail]> writes:

 Ambarish> Hi Paul, The reason is to allow a way to indicate that
 Ambarish> something is not signed even when the formal syntax
 Ambarish> requires it to be signed.

Yes, I realize that; the draft makes that clear.

My point is that this is a rather obscure way of providing this
capability.  If it's desirable to allow things to be unsigned, let the 
syntax do so.  Using the syntax for "signed data" where the signature
is actually meaningless is, at best, a weird encoding hack and, at
worst, higly misleading and confusing.

 Ambarish> One example as Marc B. pointed out was unsigned OCSP
 Ambarish> responses.  Another potential example is to actually issue
 Ambarish> self-signed certs with this kind of a signature - to
 Ambarish> clearly indicate that the signature on the cert doesn't
 Ambarish> really mean much.

Why is it useful to be able to issue self-not-signed certs?  The fact
that this proposal allows such things to be done doesn't mean it is
something that *should* be done.  (Dan Harkins, are you there?  :-) )

 Ambarish> Another reason was to allow protocols to actually require
 Ambarish> signatures everywhere, an support this algorithm if the
 Ambarish> signature was optional - for example, in the OCSP protocol,
 Ambarish> we have an optional signature section on the request -
 Ambarish> makes the syntax quite a bit uglier than just requiring a
 Ambarish> signature and allowing for NULL signatures.

But declaring the signature to be optional is far clearer.  And why
does that make the syntax ugly?  I thought one of the benefits of
ASN.1 is that it's trivial to describe optional components.

	paul


Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11364 for <[e-mail]>; Wed, 27 Oct 1999 11:18:15 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1460.8) id <4MW7VGJY>; Wed, 27 Oct 1999 14:18:05 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E4A9B5F@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Peter Williams'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: CRL Distribution Points
Date: Wed, 27 Oct 1999 14:18:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"

Peter:

You really need to carefully review the Annex M in the draft.  That should
explain it all.  If you find incompleteness, errors or inconsistencies in
that Annex, please let me know.  We would be interested in making that Annex
as complete and accurate as possible.


-----Original Message-----
From: Peter Williams [mailto:[e-mail]]
Sent: Wednesday, October 27, 1999 2:16 PM
To: Santosh Chokhani; 'Russ Housley'; [e-mail]
Subject: RE: CRL Distribution Points




> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Wednesday, October 27, 1999 8:16 AM
> To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> [e-mail]
> Subject: RE: CRL Distribution Points
> 
> 
> Peter:
> 
> My interpretation of the statement is that the issuer name in the
> certificate should match the issuer name in the CRL.

This interpretation interferes with the X.509 specification which
enables use of ANY independently-named (validation) authority.  The 
CrIssuer field signals the identity  and intended use of a given 
authority  to relying parties, when optionally present. If the
cRLIssuer value is not present, the default rule you mention 
above controls. Otherwise "the issuer name in the
**cRLIssuer** value should match the issuer name in the CRL."

Let us also note that the name of the CRLDP, when the
RDN flavour is used, is subordinate to the **CRL issuer**,
as identififed using the CrlIssuer Rule, if one
is performing conforming processing. The cRLIssuer
is identified using the processing summarized above.

Why cannot we do the simple thing, and just implement
what X.509 specifies? Its hardly contentious, its
not hard,  and has already been ratified by the ISO voting 
process, which included a PKIX voice.

Lets now advocate the case, with famous-name examples to
make the case easier to follow:

Case
----

Folk have quite widely adopted the separation of power idea
between CAs and VAs (or those who indirectly
issug CRLs). Enterprises WANT to be able to
issue a local/extranet CRL, that controls whether a VeriSign
public certificate is flagged suspended in that
relying-party domain.

Taking IBM as the example enterprise customer that chooses
to quite normally outsource its ceritifcate manufacturing to
VeriSign, IBM may well wish to have VeriSign indicate
the users of IBM certificates should use a given , non-VeriSign
CRL issuer, identified in the CrlIssuer name using
an DN selected in the IBM corporate DN-name space. 

Policies for issuing IBM's indirect CRL would meet IBM 
guidelines, which may be more stringent than the those used by
VeriSign. Furthermore, for IBM is likely to have 
a significantly more realtime data at its RAs concerning
revocation/suspension data than VeriSign has, or has yet 
accepted for processing under its own CPS rules.  

Whether IBM or an outsource VA operate the IBM
CrlIssuer is an operational choice, much like
any decision to deploy a product server on
the IBM LAN, or use a service provider.


Conclusion, to date:
-------------------

The model argued above is what the cRLIssuer field
was designed for; processing must comply for a
user cert validation result to be conforming with X.509,
and for the allied process of confirming a certificate chain
to be similarly conforming.

I have no particular objection, if it is
technically appropriate, for PKIX to overload the CrlIssuer
signal with Russ' meanings

But one cannot simple replace
the original processing requirements with an
interpretative wave of the PKIX magic wand, and 
still be able to interwork securely with 
correctly-implemented X.509 certificate-using 
systems now widespread.

Peter.

> 
> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Tuesday, October 26, 1999 8:35 PM
> To: Santosh Chokhani; Peter Williams; 'Russ Housley'; 
> [e-mail]
> Subject: RE: CRL Distribution Points
> 
> 
> 
>  
> > Peter:
> > 
> > The issuer of the CRL should be identified from issuer name 
> > field in the CRL
> > and not based on what directory entry or what attribute you 
> > queried.  The
> > directory is not trusted, the network is not trusted, and 
> > there is no strong
> > binding between the attribute value and the object/attribute.
> 
> But, from the standard(12.6.2	Certificate extension fields)
> at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc
> 
> "The cRLIssuer component identifies the authority that issues 
> and signs the
> CRL. If this component is absent, the CRL issuer name defaults to the
> certificate issuer name."
> 
> I assume we are going to comply with X.509 concerning
> the rules for identifying the issuer of a CRL, as given
> above.  If not, the security section of son-of-2459 should
> identify that PKIX validation processing is non-conforming with
> the ISO standard.  
>  
> Peter.
> 
> 
> > -----Original Message-----
> > From: Peter Williams [mailto:[e-mail]]
> > Sent: Tuesday, October 26, 1999 8:02 PM
> > To: Santosh Chokhani; 'Russ Housley'; [e-mail]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Russ,
> > 
> > You need to ensure that an indirect issuer of the
> > CRL fragment can be identified, so that the signature
> > can be appropriately verified, as per the X.509 model.
> > 
> > How would we do that with your standard today? - whilst
> > also pointing to the location of the value in 
> > a directory/uri-resolver?
> >  
> > 
> > > -----Original Message-----
> > > From: Santosh Chokhani [mailto:[e-mail]]
> > > Sent: Tuesday, October 26, 1999 4:39 PM
> > > To: 'Russ Housley'; [e-mail]
> > > Subject: RE: CRL Distribution Points
> > > 
> > > 
> > > Russ:
> > > 
> > > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > > idea to include
> > > Annex M, point to it or borrow the applicable sections in the 
> > > PKIX RFC.
> > > 
> > > -----Original Message-----
> > > From: Russ Housley [mailto:[e-mail]]
> > > Sent: Tuesday, October 26, 1999 12:58 PM
> > > To: [e-mail]
> > > Subject: CRL Distribution Points
> > > 
> > > 
> > > In reviewing the document that Tim recently posted, I 
> > > realized that we were 
> > > not really clear about the semantics of a DistributionPoint 
> > > with an absent 
> > > distributionPoint, a present reasons, and a present 
> > > cRLIssuer.  The ASN.1 
> > > is repeated below for those who have not memorized it.
> > > 
> > > If the cRLDistributionPoints extension does not contain a 
> > > DistributionPointName, but does contain a cRLIssuer, then 
> following 
> > > semantics MUST be assumed:
> > > 
> > > 1) If the cRLIssuer is of type directoryName, then the 
> > > certificateRevocationList attribute in the Directory entry of 
> > > the cRLIssuer 
> > > contains the current CRL for the associated reasons.
> > > 
> > > 2) If the cRLIssuer is of type URI, then the URI is a 
> > pointer to the 
> > > current CRL for the associated reasons.  The expected values 
> > > for the URI 
> > > are those defined in 4.2.1.7.
> > > 
> > > 3) Processing rules for other values are not defined by this 
> > > specification.
> > > 
> > > Does this seem right?
> > > 
> > > Russ
> > > 
> > > = = = = = = = = = =
> > > 
> > >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > > DistributionPoint
> > > 
> > >     DistributionPoint ::= SEQUENCE {
> > >          distributionPoint       [0]     
> > > DistributionPointName OPTIONAL,
> > >          reasons                 [1]     ReasonFlags OPTIONAL,
> > >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > > 
> > >     DistributionPointName ::= CHOICE {
> > >          fullName                [0]     GeneralNames,
> > >          nameRelativeToCRLIssuer [1]     
> RelativeDistinguishedName }
> > > 
> > >     ReasonFlags ::= BIT STRING {
> > >          unused                  (0),
> > >          keyCompromise           (1),
> > >          cACompromise            (2),
> > >          affiliationChanged      (3),
> > >          superseded              (4),
> > >          cessationOfOperation    (5),
> > >          certificateHold         (6) }
> > > 
> > 
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11088 for <[e-mail]>; Wed, 27 Oct 1999 11:14:21 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VN6JP5ZQ>; Wed, 27 Oct 1999 11:15:34 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: CRL Distribution Points
Date: Wed, 27 Oct 1999 11:15:33 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Wednesday, October 27, 1999 8:16 AM
> To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> [e-mail]
> Subject: RE: CRL Distribution Points
> 
> 
> Peter:
> 
> My interpretation of the statement is that the issuer name in the
> certificate should match the issuer name in the CRL.

This interpretation interferes with the X.509 specification which
enables use of ANY independently-named (validation) authority.  The 
CrIssuer field signals the identity  and intended use of a given 
authority  to relying parties, when optionally present. If the
cRLIssuer value is not present, the default rule you mention 
above controls. Otherwise "the issuer name in the
**cRLIssuer** value should match the issuer name in the CRL."

Let us also note that the name of the CRLDP, when the
RDN flavour is used, is subordinate to the **CRL issuer**,
as identififed using the CrlIssuer Rule, if one
is performing conforming processing. The cRLIssuer
is identified using the processing summarized above.

Why cannot we do the simple thing, and just implement
what X.509 specifies? Its hardly contentious, its
not hard,  and has already been ratified by the ISO voting 
process, which included a PKIX voice.

Lets now advocate the case, with famous-name examples to
make the case easier to follow:

Case
----

Folk have quite widely adopted the separation of power idea
between CAs and VAs (or those who indirectly
issug CRLs). Enterprises WANT to be able to
issue a local/extranet CRL, that controls whether a VeriSign
public certificate is flagged suspended in that
relying-party domain.

Taking IBM as the example enterprise customer that chooses
to quite normally outsource its ceritifcate manufacturing to
VeriSign, IBM may well wish to have VeriSign indicate
the users of IBM certificates should use a given , non-VeriSign
CRL issuer, identified in the CrlIssuer name using
an DN selected in the IBM corporate DN-name space. 

Policies for issuing IBM's indirect CRL would meet IBM 
guidelines, which may be more stringent than the those used by
VeriSign. Furthermore, for IBM is likely to have 
a significantly more realtime data at its RAs concerning
revocation/suspension data than VeriSign has, or has yet 
accepted for processing under its own CPS rules.  

Whether IBM or an outsource VA operate the IBM
CrlIssuer is an operational choice, much like
any decision to deploy a product server on
the IBM LAN, or use a service provider.


Conclusion, to date:
-------------------

The model argued above is what the cRLIssuer field
was designed for; processing must comply for a
user cert validation result to be conforming with X.509,
and for the allied process of confirming a certificate chain
to be similarly conforming.

I have no particular objection, if it is
technically appropriate, for PKIX to overload the CrlIssuer
signal with Russ' meanings

But one cannot simple replace
the original processing requirements with an
interpretative wave of the PKIX magic wand, and 
still be able to interwork securely with 
correctly-implemented X.509 certificate-using 
systems now widespread.

Peter.

> 
> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Tuesday, October 26, 1999 8:35 PM
> To: Santosh Chokhani; Peter Williams; 'Russ Housley'; 
> [e-mail]
> Subject: RE: CRL Distribution Points
> 
> 
> 
>  
> > Peter:
> > 
> > The issuer of the CRL should be identified from issuer name 
> > field in the CRL
> > and not based on what directory entry or what attribute you 
> > queried.  The
> > directory is not trusted, the network is not trusted, and 
> > there is no strong
> > binding between the attribute value and the object/attribute.
> 
> But, from the standard(12.6.2	Certificate extension fields)
> at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc
> 
> "The cRLIssuer component identifies the authority that issues 
> and signs the
> CRL. If this component is absent, the CRL issuer name defaults to the
> certificate issuer name."
> 
> I assume we are going to comply with X.509 concerning
> the rules for identifying the issuer of a CRL, as given
> above.  If not, the security section of son-of-2459 should
> identify that PKIX validation processing is non-conforming with
> the ISO standard.  
>  
> Peter.
> 
> 
> > -----Original Message-----
> > From: Peter Williams [mailto:[e-mail]]
> > Sent: Tuesday, October 26, 1999 8:02 PM
> > To: Santosh Chokhani; 'Russ Housley'; [e-mail]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Russ,
> > 
> > You need to ensure that an indirect issuer of the
> > CRL fragment can be identified, so that the signature
> > can be appropriately verified, as per the X.509 model.
> > 
> > How would we do that with your standard today? - whilst
> > also pointing to the location of the value in 
> > a directory/uri-resolver?
> >  
> > 
> > > -----Original Message-----
> > > From: Santosh Chokhani [mailto:[e-mail]]
> > > Sent: Tuesday, October 26, 1999 4:39 PM
> > > To: 'Russ Housley'; [e-mail]
> > > Subject: RE: CRL Distribution Points
> > > 
> > > 
> > > Russ:
> > > 
> > > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > > idea to include
> > > Annex M, point to it or borrow the applicable sections in the 
> > > PKIX RFC.
> > > 
> > > -----Original Message-----
> > > From: Russ Housley [mailto:[e-mail]]
> > > Sent: Tuesday, October 26, 1999 12:58 PM
> > > To: [e-mail]
> > > Subject: CRL Distribution Points
> > > 
> > > 
> > > In reviewing the document that Tim recently posted, I 
> > > realized that we were 
> > > not really clear about the semantics of a DistributionPoint 
> > > with an absent 
> > > distributionPoint, a present reasons, and a present 
> > > cRLIssuer.  The ASN.1 
> > > is repeated below for those who have not memorized it.
> > > 
> > > If the cRLDistributionPoints extension does not contain a 
> > > DistributionPointName, but does contain a cRLIssuer, then 
> following 
> > > semantics MUST be assumed:
> > > 
> > > 1) If the cRLIssuer is of type directoryName, then the 
> > > certificateRevocationList attribute in the Directory entry of 
> > > the cRLIssuer 
> > > contains the current CRL for the associated reasons.
> > > 
> > > 2) If the cRLIssuer is of type URI, then the URI is a 
> > pointer to the 
> > > current CRL for the associated reasons.  The expected values 
> > > for the URI 
> > > are those defined in 4.2.1.7.
> > > 
> > > 3) Processing rules for other values are not defined by this 
> > > specification.
> > > 
> > > Does this seem right?
> > > 
> > > Russ
> > > 
> > > = = = = = = = = = =
> > > 
> > >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > > DistributionPoint
> > > 
> > >     DistributionPoint ::= SEQUENCE {
> > >          distributionPoint       [0]     
> > > DistributionPointName OPTIONAL,
> > >          reasons                 [1]     ReasonFlags OPTIONAL,
> > >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > > 
> > >     DistributionPointName ::= CHOICE {
> > >          fullName                [0]     GeneralNames,
> > >          nameRelativeToCRLIssuer [1]     
> RelativeDistinguishedName }
> > > 
> > >     ReasonFlags ::= BIT STRING {
> > >          unused                  (0),
> > >          keyCompromise           (1),
> > >          cACompromise            (2),
> > >          affiliationChanged      (3),
> > >          superseded              (4),
> > >          cessationOfOperation    (5),
> > >          certificateHold         (6) }
> > > 
> > 
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10971 for <[e-mail]>; Wed, 27 Oct 1999 11:12:54 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VN6JP5ZL>; Wed, 27 Oct 1999 11:14:07 -0700
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: Paul Koning <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: New draft - NULL Public Key Signatures
Date: Wed, 27 Oct 1999 11:14:06 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Paul,
    The reason is to allow a way to indicate that something is
not signed even when the formal syntax requires it to be signed.

One example as Marc B. pointed out was unsigned OCSP responses.
Another potential example is to actually issue self-signed certs
with this kind of a signature - to clearly indicate that the
signature on the cert doesn't really mean much.

Another reason was to allow protocols to actually require signatures
everywhere, an support this algorithm if the signature was
optional - for example, in the OCSP protocol, we have an optional
signature section on the request - makes the syntax quite a bit
uglier than just requiring a signature and allowing for NULL
signatures.

Ambarish

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


> -----Original Message-----
> From: Paul Koning [mailto:[e-mail]]
> Sent: Tuesday, October 26, 1999 8:09 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: New draft - NULL Public Key Signatures
> 
> 
> I'm not having much success seeing the analogy between Null ESP and
> null signature, nor a reason why the latter is useful and should be
> standardized. 
> 
> Null ESP serves a specific purpose, which is well documented: to
> provide data integrity without simultaneously providing
> confidentiality.  While that's not often desirable, there are
> certainly cases where it is a useful service.
> 
> But I don't see that the analogy carries over to null 
> signatures.  The 
> political/legal issues that stand in the way of universal
> confidentiality don't apply.  As far as I can tell from the RFC, the
> purpose is really just an encoding hack: a way of specifying that
> signatures are omitted without saying it explictly.
> 
> So what good is that?
> 
> 	paul
> 


Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07686 for <[e-mail]>; Wed, 27 Oct 1999 08:41:33 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP for <[e-mail]> id C6B1415531; Wed, 27 Oct 1999 11:44:07 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 5DF0E7C055 for <[e-mail]>; Wed, 27 Oct 1999 11:44:07 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2232.9) id <V28V7RGY>; Wed, 27 Oct 1999 11:43:42 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Interaction of extendedKeyUsage and keyUsage
Date: Wed, 27 Oct 1999 11:43:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

Hypotheses:
    1 if no KU extension is present, the cert can be used for "anything"
    2 if KU is present, the cert can only be used as specified by the bits
    3 if a particular OID appears in the EKU, the cert can be used as
      specified by that OID.
    4 if the OID does not appear -- or if the EKU is empty -- the cert
      cannot be used
Are those correct?
If so, what happens when #3 meets #1.  E.g., suppose a certificate has
id-kp-OCSPSigning in its EKU as specified by RFC2560. Must it have KU with
digitalSignature, as indicated by RFC2459?


Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06881 for <[e-mail]>; Wed, 27 Oct 1999 08:16:12 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1460.8) id <4MW7VG1X>; Wed, 27 Oct 1999 11:16:01 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E4A9B53@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Peter Williams'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: CRL Distribution Points
Date: Wed, 27 Oct 1999 11:15:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"

Peter:

My interpretation of the statement is that the issuer name in the
certificate should match the issuer name in the CRL.

-----Original Message-----
From: Peter Williams [mailto:[e-mail]]
Sent: Tuesday, October 26, 1999 8:35 PM
To: Santosh Chokhani; Peter Williams; 'Russ Housley'; [e-mail]
Subject: RE: CRL Distribution Points



 
> Peter:
> 
> The issuer of the CRL should be identified from issuer name 
> field in the CRL
> and not based on what directory entry or what attribute you 
> queried.  The
> directory is not trusted, the network is not trusted, and 
> there is no strong
> binding between the attribute value and the object/attribute.

But, from the standard(12.6.2	Certificate extension fields)
at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc

"The cRLIssuer component identifies the authority that issues and signs the
CRL. If this component is absent, the CRL issuer name defaults to the
certificate issuer name."

I assume we are going to comply with X.509 concerning
the rules for identifying the issuer of a CRL, as given
above.  If not, the security section of son-of-2459 should
identify that PKIX validation processing is non-conforming with
the ISO standard.  
 
Peter.


> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Tuesday, October 26, 1999 8:02 PM
> To: Santosh Chokhani; 'Russ Housley'; [e-mail]
> Subject: RE: CRL Distribution Points
> 
> 
> Russ,
> 
> You need to ensure that an indirect issuer of the
> CRL fragment can be identified, so that the signature
> can be appropriately verified, as per the X.509 model.
> 
> How would we do that with your standard today? - whilst
> also pointing to the location of the value in 
> a directory/uri-resolver?
>  
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Tuesday, October 26, 1999 4:39 PM
> > To: 'Russ Housley'; [e-mail]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Russ:
> > 
> > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > idea to include
> > Annex M, point to it or borrow the applicable sections in the 
> > PKIX RFC.
> > 
> > -----Original Message-----
> > From: Russ Housley [mailto:[e-mail]]
> > Sent: Tuesday, October 26, 1999 12:58 PM
> > To: [e-mail]
> > Subject: CRL Distribution Points
> > 
> > 
> > In reviewing the document that Tim recently posted, I 
> > realized that we were 
> > not really clear about the semantics of a DistributionPoint 
> > with an absent 
> > distributionPoint, a present reasons, and a present 
> > cRLIssuer.  The ASN.1 
> > is repeated below for those who have not memorized it.
> > 
> > If the cRLDistributionPoints extension does not contain a 
> > DistributionPointName, but does contain a cRLIssuer, then following 
> > semantics MUST be assumed:
> > 
> > 1) If the cRLIssuer is of type directoryName, then the 
> > certificateRevocationList attribute in the Directory entry of 
> > the cRLIssuer 
> > contains the current CRL for the associated reasons.
> > 
> > 2) If the cRLIssuer is of type URI, then the URI is a 
> pointer to the 
> > current CRL for the associated reasons.  The expected values 
> > for the URI 
> > are those defined in 4.2.1.7.
> > 
> > 3) Processing rules for other values are not defined by this 
> > specification.
> > 
> > Does this seem right?
> > 
> > Russ
> > 
> > = = = = = = = = = =
> > 
> >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > DistributionPoint
> > 
> >     DistributionPoint ::= SEQUENCE {
> >          distributionPoint       [0]     
> > DistributionPointName OPTIONAL,
> >          reasons                 [1]     ReasonFlags OPTIONAL,
> >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > 
> >     DistributionPointName ::= CHOICE {
> >          fullName                [0]     GeneralNames,
> >          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> > 
> >     ReasonFlags ::= BIT STRING {
> >          unused                  (0),
> >          keyCompromise           (1),
> >          cACompromise            (2),
> >          affiliationChanged      (3),
> >          superseded              (4),
> >          cessationOfOperation    (5),
> >          certificateHold         (6) }
> > 
> 


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02607 for <[e-mail]>; Wed, 27 Oct 1999 05:45:18 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09285; Wed, 27 Oct 1999 08:48:26 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-00.txt
Date: Wed, 27 Oct 1999 08:48:26 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Certificate and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-00.txt
	Pages		: 143
	Date		: 26-Oct-99
	
This is the first draft of a specification based upon RFC 2459.  When
complete, this specification will obsolete RFC 2459.  This
specification includes numerous edits and clarifications.  The most
notable departures from RFC 2459 are found in Section 6, Path
Validation.  In RFC 2459, the reader was expected to augment the path
validation algorithm, which concentrated upon policy processing, with
information embedded in earlier sections.  For example, parameter
inheritance is discussed in Section 7, Algorithm Support, and can
certainly affect the validity of a certification path.  However,
parameter inheritance was omitted from the path validation algorithm in RFC 2459.  In this draft, the path validation algorithm has a
comprehensive and extremely detailed description.  Details such as
parameter inheritance are covered thoroughly.  In addition, this
draft anticipates certain corrections proposed in the X.509 standard
for the policy processing aspects of path validation.
A new section 6.3, CRL validation, has been added as well.  This
section provides a supplement to the path validation algorithm that
determines if a particular CRL may be used to verify the status of a
particular certificate.  (The basic path validation algorithm is, by
design, independent of the type and format of status information.)
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
in the Internet.  An overview of the approach and model are provided
as an introduction.  The X.509 v3 certificate format is described in
detail, with additional information regarding the format and
semantics of Internet name forms (e.g., IP addresses).  Standard
certificate extensions are described and one new Internet-specific
extension is defined.  A required set of certificate extensions is
specified.  The X.509 v2 CRL format is described and a required
extension set is defined as well.  An algorithm for X.509 certificate
path validation is described. Supplemental infor

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-new-part1-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from news.rdc1.tn.home.com ([e-mail] [24.2.7.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA01842 for <[e-mail]>; Wed, 27 Oct 1999 05:12:37 -0700 (PDT)
Received: from ci280291a ([24.6.126.32]) by news.rdc1.tn.home.com (InterMail v4.01.01.00 201-229-111) with SMTP id <19991027121545.CGLH8996.news.rdc1.tn.home.com@ci280291a> for <[e-mail]>; Wed, 27 Oct 1999 05:15:45 -0700
Message-ID: <025101bf206f$e2d2fcc0$[e-mail]>
Reply-To: "eZDesk.com" <[e-mail]>
From: "eZDesk.com" <[e-mail]>
To: <[e-mail]>
Subject: New Loan Product Release
Date: Wed, 27 Oct 1999 06:39:10 -0500
Organization: EFS, Inc. d/b/a eZDesk.com
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Using your EXISTING Loan System (windows), you can send
loan documents directly to anyone with just a click !

Click2Doc(TM) makes it easy.  Think!  FREE same day delivery of loan
docs, disclosures, applications, approvals, conditions, etc. to anyone by
email.  Recipient needs NO software.  NO plugins.  NO downloads.  They can
save, view, print.  Documents Set can be password protected.

www.Click2Doc.com






Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01103 for <[e-mail]>; Wed, 27 Oct 1999 04:26:33 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05619; Wed, 27 Oct 1999 07:29:41 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Certificate Management Messages over CMS to Proposed Standard
Reply-to: [e-mail]
Date: Wed, 27 Oct 1999 07:29:41 -0400
Sender: [e-mail]

The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider Certificate Management Messages over
CMS <draft-ietf-pkix-cmc-05.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by November 16, 1999.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-05.txt


Received: from www.certifeidtime.com. (test.glassey.com [207.126.98.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA14399 for <[e-mail]>; Tue, 26 Oct 1999 19:35:55 -0700 (PDT)
Received: from gw by www.certifeidtime.com. (SMI-8.6/SMI-SVR4) id TAA01458; Tue, 26 Oct 1999 19:39:50 -0700
Message-ID: <017f01bf2024$6af1b480$[e-mail]>
From: "GMT" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: TYPO in Roadmap-04 re BERT 
Date: Tue, 26 Oct 1999 19:38:56 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300

FYI  All - BERT is not dead. The concluding statement in the PKI Roadmap is
incorrect here.

The BERT Token Specification is undergoing a redesign to allow it to support
virtually any kind of event representation. It also will have a predefined
set of event types including a Notarial Subtoken complete with a
ceremony-service marker. The token structure will represent a digital
harness with an encoded and protected manifest. This will allow the modular
plugging in of a number of optional token components to create an
interoperable policy centric token. - the ultimate timestamp so to speak -

Anyway, the new token structure will also have an applications and Network
transparent API to address the marking, validating, and verifying of
virtually all events in time and space. We feel this is the start of "agency
control" and conveyance models and that they will operate  by demonstrating
the intent of the user. These token data structures and the API for managing
them are very important to eCommerce and will be of more important to PKIX
as the evolution of the Internet and Global ECommerce continues.

The currently underway draft will not make this meeting but will be filed
shortly afterward and will be available for comment as such prior to the
next meeting.

If I can answer any questions in the mean time please feel free to contact
me or Michael directly

[e-mail]
[e-mail]

Todd Glassey



> Todd:
>
> Here's the BERT excerpt from the roadmap, published Oct 22...note the
> status at the end.
>
>    DOCUMENT TITLE: Basic Event Representation Token <draft-ietf-pkix-
>    bert1-01.txt>
>
>    DESCRIPTION: This document defines a finite method of representing a
>    discrete instant in time as a referable event. The Basic Event
>    Representation Token (BERT) is a light-weight binary token designed
>    for use in large numbers over short periods of time. The tokens
>    contain only a single instance of an event stamp and the trust
>    process is referenced against an external reference.
>
>    STATUS: Work has been discontinued.
>
>



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10230 for <[e-mail]>; Tue, 26 Oct 1999 17:42:17 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VN6JPZ51>; Tue, 26 Oct 1999 17:35:32 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Santosh Chokhani <[e-mail]>, Peter Williams <[e-mail]>, "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: CRL Distribution Points
Date: Tue, 26 Oct 1999 17:35:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

 
> Peter:
> 
> The issuer of the CRL should be identified from issuer name 
> field in the CRL
> and not based on what directory entry or what attribute you 
> queried.  The
> directory is not trusted, the network is not trusted, and 
> there is no strong
> binding between the attribute value and the object/attribute.

But, from the standard(12.6.2	Certificate extension fields)
at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc

"The cRLIssuer component identifies the authority that issues and signs the
CRL. If this component is absent, the CRL issuer name defaults to the
certificate issuer name."

I assume we are going to comply with X.509 concerning
the rules for identifying the issuer of a CRL, as given
above.  If not, the security section of son-of-2459 should
identify that PKIX validation processing is non-conforming with
the ISO standard.  
 
Peter.


> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Tuesday, October 26, 1999 8:02 PM
> To: Santosh Chokhani; 'Russ Housley'; [e-mail]
> Subject: RE: CRL Distribution Points
> 
> 
> Russ,
> 
> You need to ensure that an indirect issuer of the
> CRL fragment can be identified, so that the signature
> can be appropriately verified, as per the X.509 model.
> 
> How would we do that with your standard today? - whilst
> also pointing to the location of the value in 
> a directory/uri-resolver?
>  
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Tuesday, October 26, 1999 4:39 PM
> > To: 'Russ Housley'; [e-mail]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Russ:
> > 
> > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > idea to include
> > Annex M, point to it or borrow the applicable sections in the 
> > PKIX RFC.
> > 
> > -----Original Message-----
> > From: Russ Housley [mailto:[e-mail]]
> > Sent: Tuesday, October 26, 1999 12:58 PM
> > To: [e-mail]
> > Subject: CRL Distribution Points
> > 
> > 
> > In reviewing the document that Tim recently posted, I 
> > realized that we were 
> > not really clear about the semantics of a DistributionPoint 
> > with an absent 
> > distributionPoint, a present reasons, and a present 
> > cRLIssuer.  The ASN.1 
> > is repeated below for those who have not memorized it.
> > 
> > If the cRLDistributionPoints extension does not contain a 
> > DistributionPointName, but does contain a cRLIssuer, then following 
> > semantics MUST be assumed:
> > 
> > 1) If the cRLIssuer is of type directoryName, then the 
> > certificateRevocationList attribute in the Directory entry of 
> > the cRLIssuer 
> > contains the current CRL for the associated reasons.
> > 
> > 2) If the cRLIssuer is of type URI, then the URI is a 
> pointer to the 
> > current CRL for the associated reasons.  The expected values 
> > for the URI 
> > are those defined in 4.2.1.7.
> > 
> > 3) Processing rules for other values are not defined by this 
> > specification.
> > 
> > Does this seem right?
> > 
> > Russ
> > 
> > = = = = = = = = = =
> > 
> >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > DistributionPoint
> > 
> >     DistributionPoint ::= SEQUENCE {
> >          distributionPoint       [0]     
> > DistributionPointName OPTIONAL,
> >          reasons                 [1]     ReasonFlags OPTIONAL,
> >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > 
> >     DistributionPointName ::= CHOICE {
> >          fullName                [0]     GeneralNames,
> >          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> > 
> >     ReasonFlags ::= BIT STRING {
> >          unused                  (0),
> >          keyCompromise           (1),
> >          cACompromise            (2),
> >          affiliationChanged      (3),
> >          superseded              (4),
> >          cessationOfOperation    (5),
> >          certificateHold         (6) }
> > 
> 


Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09682 for <[e-mail]>; Tue, 26 Oct 1999 17:12:05 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1460.8) id <4MW7VF6Q>; Tue, 26 Oct 1999 20:11:49 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E4A9B51@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Peter Williams'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: CRL Distribution Points
Date: Tue, 26 Oct 1999 20:11:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain

Peter:

The issuer of the CRL should be identified from issuer name field in the CRL
and not based on what directory entry or what attribute you queried.  The
directory is not trusted, the network is not trusted, and there is no strong
binding between the attribute value and the object/attribute.

-----Original Message-----
From: Peter Williams [mailto:[e-mail]]
Sent: Tuesday, October 26, 1999 8:02 PM
To: Santosh Chokhani; 'Russ Housley'; [e-mail]
Subject: RE: CRL Distribution Points


Russ,

You need to ensure that an indirect issuer of the
CRL fragment can be identified, so that the signature
can be appropriately verified, as per the X.509 model.

How would we do that with your standard today? - whilst
also pointing to the location of the value in 
a directory/uri-resolver?
 

> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Tuesday, October 26, 1999 4:39 PM
> To: 'Russ Housley'; [e-mail]
> Subject: RE: CRL Distribution Points
> 
> 
> Russ:
> 
> Please Annex M on X.509 Draft Amendment.  It will be a good 
> idea to include
> Annex M, point to it or borrow the applicable sections in the 
> PKIX RFC.
> 
> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Tuesday, October 26, 1999 12:58 PM
> To: [e-mail]
> Subject: CRL Distribution Points
> 
> 
> In reviewing the document that Tim recently posted, I 
> realized that we were 
> not really clear about the semantics of a DistributionPoint 
> with an absent 
> distributionPoint, a present reasons, and a present 
> cRLIssuer.  The ASN.1 
> is repeated below for those who have not memorized it.
> 
> If the cRLDistributionPoints extension does not contain a 
> DistributionPointName, but does contain a cRLIssuer, then following 
> semantics MUST be assumed:
> 
> 1) If the cRLIssuer is of type directoryName, then the 
> certificateRevocationList attribute in the Directory entry of 
> the cRLIssuer 
> contains the current CRL for the associated reasons.
> 
> 2) If the cRLIssuer is of type URI, then the URI is a pointer to the 
> current CRL for the associated reasons.  The expected values 
> for the URI 
> are those defined in 4.2.1.7.
> 
> 3) Processing rules for other values are not defined by this 
> specification.
> 
> Does this seem right?
> 
> Russ
> 
> = = = = = = = = = =
> 
>     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> DistributionPoint
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     
> DistributionPointName OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
>     DistributionPointName ::= CHOICE {
>          fullName                [0]     GeneralNames,
>          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> 
>     ReasonFlags ::= BIT STRING {
>          unused                  (0),
>          keyCompromise           (1),
>          cACompromise            (2),
>          affiliationChanged      (3),
>          superseded              (4),
>          cessationOfOperation    (5),
>          certificateHold         (6) }
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09441 for <[e-mail]>; Tue, 26 Oct 1999 17:08:36 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VN6JPZYA>; Tue, 26 Oct 1999 17:01:51 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: CRL Distribution Points
Date: Tue, 26 Oct 1999 17:01:44 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Russ,

You need to ensure that an indirect issuer of the
CRL fragment can be identified, so that the signature
can be appropriately verified, as per the X.509 model.

How would we do that with your standard today? - whilst
also pointing to the location of the value in 
a directory/uri-resolver?
 

> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Tuesday, October 26, 1999 4:39 PM
> To: 'Russ Housley'; [e-mail]
> Subject: RE: CRL Distribution Points
> 
> 
> Russ:
> 
> Please Annex M on X.509 Draft Amendment.  It will be a good 
> idea to include
> Annex M, point to it or borrow the applicable sections in the 
> PKIX RFC.
> 
> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Tuesday, October 26, 1999 12:58 PM
> To: [e-mail]
> Subject: CRL Distribution Points
> 
> 
> In reviewing the document that Tim recently posted, I 
> realized that we were 
> not really clear about the semantics of a DistributionPoint 
> with an absent 
> distributionPoint, a present reasons, and a present 
> cRLIssuer.  The ASN.1 
> is repeated below for those who have not memorized it.
> 
> If the cRLDistributionPoints extension does not contain a 
> DistributionPointName, but does contain a cRLIssuer, then following 
> semantics MUST be assumed:
> 
> 1) If the cRLIssuer is of type directoryName, then the 
> certificateRevocationList attribute in the Directory entry of 
> the cRLIssuer 
> contains the current CRL for the associated reasons.
> 
> 2) If the cRLIssuer is of type URI, then the URI is a pointer to the 
> current CRL for the associated reasons.  The expected values 
> for the URI 
> are those defined in 4.2.1.7.
> 
> 3) Processing rules for other values are not defined by this 
> specification.
> 
> Does this seem right?
> 
> Russ
> 
> = = = = = = = = = =
> 
>     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> DistributionPoint
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     
> DistributionPointName OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
>     DistributionPointName ::= CHOICE {
>          fullName                [0]     GeneralNames,
>          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> 
>     ReasonFlags ::= BIT STRING {
>          unused                  (0),
>          keyCompromise           (1),
>          cACompromise            (2),
>          affiliationChanged      (3),
>          superseded              (4),
>          cessationOfOperation    (5),
>          certificateHold         (6) }
> 


Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08920 for <[e-mail]>; Tue, 26 Oct 1999 16:39:18 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1460.8) id <4MW7VF61>; Tue, 26 Oct 1999 19:39:02 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E4A9B4F@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: CRL Distribution Points
Date: Tue, 26 Oct 1999 19:39:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain

Russ:

Please Annex M on X.509 Draft Amendment.  It will be a good idea to include
Annex M, point to it or borrow the applicable sections in the PKIX RFC.

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Tuesday, October 26, 1999 12:58 PM
To: [e-mail]
Subject: CRL Distribution Points


In reviewing the document that Tim recently posted, I realized that we were 
not really clear about the semantics of a DistributionPoint with an absent 
distributionPoint, a present reasons, and a present cRLIssuer.  The ASN.1 
is repeated below for those who have not memorized it.

If the cRLDistributionPoints extension does not contain a 
DistributionPointName, but does contain a cRLIssuer, then following 
semantics MUST be assumed:

1) If the cRLIssuer is of type directoryName, then the 
certificateRevocationList attribute in the Directory entry of the cRLIssuer 
contains the current CRL for the associated reasons.

2) If the cRLIssuer is of type URI, then the URI is a pointer to the 
current CRL for the associated reasons.  The expected values for the URI 
are those defined in 4.2.1.7.

3) Processing rules for other values are not defined by this specification.

Does this seem right?

Russ

= = = = = = = = = =

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

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

    DistributionPointName ::= CHOICE {
         fullName                [0]     GeneralNames,
         nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

    ReasonFlags ::= BIT STRING {
         unused                  (0),
         keyCompromise           (1),
         cACompromise            (2),
         affiliationChanged      (3),
         superseded              (4),
         cessationOfOperation    (5),
         certificateHold         (6) }


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08591 for <[e-mail]>; Tue, 26 Oct 1999 16:31:17 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id QAA17321; Tue, 26 Oct 1999 16:25:54 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 26 Oct 1999 19:30:17 -0500
To: Warwick Ford <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: FW: ISC Meeting Notice - Nov. 8-11, Washington, DC
Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail] >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Here is what the IETF has planned for Thursday morning.  Several of the 
people that are active in PKIX are also active in S/MIME.  This scheduling 
conflict is quite unfortunate.

Russ

THURSDAY, November 11, 1999
0800-1700  IETF Registration - West Conference Center
0800-0900  Continental Breakfast -
0900-1130  Morning Sessions
         APP  fax        Internet Fax WG
         APP  mmms       Mobile Multimedia Messaging Service BOF
         OPS  tewg       Internet Traffic Engineering WG
         RTG  mobileip   IP Routing for Wireless/Mobile Hosts WG
         SEC  smime      S/MIME Mail Security WG
         TSV  avt        Audio/Video Transport WG *


At 08:36 AM 10/18/99 -0700, Warwick Ford wrote:
>FYI, attached is the meeting notice for the next American Bar Association
>Information Security Committee meeting, which is scheduled for Washington DC
>the same week as the IETF.  To take advantage of this co-location, the ABA
>group has requested a meeting with PKIX experts to discuss various topics of
>mutual interest.  Accordingly, an unofficial joint meeting has been
>scheduled for the Thursday morning 11/11.  This meeting has no official
>status in the IETF and anyone is welcome to attend.  We don't have a venue
>yet, so any offers to host that meeting will be appreciated.  (Maybe 30-40
>people(?), preferably close to the Omni Shoreham.)
>
>Warwick
>



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08295 for <[e-mail]>; Tue, 26 Oct 1999 16:26:13 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id QAA17198; Tue, 26 Oct 1999 16:20:47 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 26 Oct 1999 19:25:15 -0500
To: "Xiong Shao Jun" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: directory entry with NULL DN
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

NULL DNs are intended for use in environments where the subject does not 
have a DN.  If your subject has an LDAP entry, it has a DN, so you should 
populate it.

Russ

At 04:08 PM 10/24/99 +0800, Xiong Shao Jun wrote:
>Hi, there. I posted a mail a few days ago, but received no reply.
>I have some questions about rfc2587. If a PKI subject has null
>DN in certificate, how can it have an entry in LDAP?
>
>Thanx in advance.
>
>Xiong Shaojun
>China Merchants Bank



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08176 for <[e-mail]>; Tue, 26 Oct 1999 16:25:14 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id QAA17136 for <[e-mail]>; Tue, 26 Oct 1999 16:20:00 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 26 Oct 1999 11:57:54 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: CRL Distribution Points
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

In reviewing the document that Tim recently posted, I realized that we were 
not really clear about the semantics of a DistributionPoint with an absent 
distributionPoint, a present reasons, and a present cRLIssuer.  The ASN.1 
is repeated below for those who have not memorized it.

If the cRLDistributionPoints extension does not contain a 
DistributionPointName, but does contain a cRLIssuer, then following 
semantics MUST be assumed:

1) If the cRLIssuer is of type directoryName, then the 
certificateRevocationList attribute in the Directory entry of the cRLIssuer 
contains the current CRL for the associated reasons.

2) If the cRLIssuer is of type URI, then the URI is a pointer to the 
current CRL for the associated reasons.  The expected values for the URI 
are those defined in 4.2.1.7.

3) Processing rules for other values are not defined by this specification.

Does this seem right?

Russ

= = = = = = = = = =

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

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

    DistributionPointName ::= CHOICE {
         fullName                [0]     GeneralNames,
         nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

    ReasonFlags ::= BIT STRING {
         unused                  (0),
         keyCompromise           (1),
         cACompromise            (2),
         affiliationChanged      (3),
         superseded              (4),
         cessationOfOperation    (5),
         certificateHold         (6) }



Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07451 for <[e-mail]>; Tue, 26 Oct 1999 15:43:51 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
Date: Tue, 26 Oct 1999 15:47:04 -0700
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: New version of PKIX - IPsec draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

draft-ietf-ipsec-pki-req-03.txt is out and being discussed in the IPsec WG. 
Information on that WG can be found at <http://www.vpnc.org/ietf-ipsec/>.

--Paul Hoffman, Director
--VPN Consortium



Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07303 for <[e-mail]>; Tue, 26 Oct 1999 15:35:30 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
Date: Tue, 26 Oct 1999 15:38:45 -0700
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: New version of PKIX - IPsec draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

draft-ietf-ipsec-pki-req-03.txt is out and being discussed in the IPsec WG. 
Information on that WG can be found at <http://www.vpnc.org/ietf-ipsec/>.

--Paul Hoffman, Director
--VPN Consortium



Received: from barbar.esat.kuleuven.ac.be ([e-mail] [134.58.56.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04684 for <[e-mail]>; Tue, 26 Oct 1999 13:14:55 -0700 (PDT)
Received: from bronx (bronx.esat.kuleuven.ac.be [134.58.189.79]) by barbar (version 8.8.5)  with ESMTP id WAA14424; Tue, 26 Oct 1999 22:17:59 +0200 (METDST)
Organization: ESAT, K.U.Leuven, Belgium
Date: Tue, 26 Oct 1999 22:17:59 +0200 (CEST)
From: Eurocrypt 2000 <[e-mail]>
X-Sender: ec2000@bronx
To: [e-mail]
Subject: Eurocrypt 2000 submission deadline: November 3, 1999
Message-ID: <Pine.LNX.4.10.9910262217260.4721-100000@bronx>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-------------------------------------------------------------
                  E U R O C R Y P T    2 0 0 0
                         May 14-18, 2000
                    Bruges (Brugge), Belgium

     http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/
-------------------------------------------------------------

This is a reminder that the submission deadline for 
Eurocrypt 2000 is November 3, 1999. 

Visit http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/ 
for more information.

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



Received: from crack.x509.com ([e-mail] [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02163 for <[e-mail]>; Tue, 26 Oct 1999 11:05:50 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id LAA17415 for <[e-mail]>; Tue, 26 Oct 1999 11:08:55 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 26 Oct 1999 11:17:51 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: New draft - NULL Public Key Signatures
References: <000701bf1fc1$b0beb2a0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phillip M Hallam-Baker wrote:
> 
> Steve,
> 
>         Yes, I agree that the joke is pretty funny. I don't think turning
> it into an RFC would improve the joke, and we may well find that the
> joke ends up being on us.
> 
>         Given the ability of companies to mess up big time I can well imagine
> some company selling a product claiming to be PKIX compliant, offering only
> the NULL signature, export rules, licensing restrictions already mean that
> many products ship requiring a crypto engine to be obtained elsewhere.
> 

The absence of a NPKA RFC doesn't prevent that.  Nothing in PKIX says that
you MUST (or even SHOULD) support any particular crypto algorithm, or even a
particular OID for a particular algorithm.

>         If the product runs without security it is inevitable that someone will
> use it without. I remember a while back when I persuaded a company that they
> had a problem with a crypto implementation, sent them extensive
> documentation
> on the changes needed. A year later the product was broken with great media
> fanfare. Turns out my memo had made it to the documentation but not the
> code.
> 

I, for one, am not advocating that anything be able to run without security. 
I don't see what the big deal is about standardizing this.  Like everything
else, those of us who know what we're doing won't hang ourselves with this
rope.  Sure, some idiot might misuse the standard, but the IETF can't prevent
that from happening.  The proper forum to address those kinds of concerns is
something like a PKI accreditation body, that certifies a given level of
conformance.

>         Or it may just be that I am in a particularly humourless mood given
> that there are a couple of nuclear plants in the vicinity and I have been
> assured via the television that the events which occurred in Japan could
> not occur in the US by 'experts' who clearly lack the level of knowledge of
> nuclear processes taught at UK high schools.
> 
>         This thing we are building has to be usable by folk who _have_ a
> degree in Nuclear Physics :-)
> 
>         Folk who need a NULL signature for Test purposes will probably find
> that SHA-1 or MD5 can be used to the same effect, with the significant
> advantage that integrity problems are revealled. I have a serious concern
> that applying NULL in the context envisaged by Marc may remove an integrity
> check which in the pure SSL context is not significant but which becomes
> significant in a hybrid SSL/message passing system.
> 

Which kind of hybrid contexts are you referring to?  Actually, the answer
isn't that important -- there'll always be some way to abuse the system.  The
existence of such possibilities shouldn't stop us from agreeing on a
technical standard.

>         The overhead of SHA-1 is low, we already have the OID. Ergo no need
> for a NULL draft to confuse the befuddled holders of doctorates in nuclear
> physics.
> 

The availability of SHA-1 isn't the point.  In fact, using a raw digest
algorithm instead of an "officially" NULL signature is really just muddying
the waters without adding any kind of security benefit.  So there's a digest
of the pack/blob/message?  It doesn't achieve anything.  Much better to
explicitly say "I'm not including any integrity/authentication here, where
you might expect to see it.  You should derive integrity and/or
authentication some other way."

		Marc

p.s. - As to the humour in the draft, let me proclaim my support for as much
humour as possible in these documents.  The stuff's hard enough to read as it
is.  But, if humour upsets people, then I can live (well, exist, really)
without it.


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28498 for <[e-mail]>; Tue, 26 Oct 1999 08:06:13 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhmpo13034; Tue, 26 Oct 1999 15:09:15 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA14631; Tue, 26 Oct 99 11:07:20 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA02085; Tue, 26 Oct 1999 11:09:13 -0400
Date: Tue, 26 Oct 1999 11:09:13 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: New draft - NULL Public Key Signatures
References: <v04020a03b43abe53b3ee@[128.33.238.29]> <000701bf1fc1$b0beb2a0$[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

I'm not having much success seeing the analogy between Null ESP and
null signature, nor a reason why the latter is useful and should be
standardized. 

Null ESP serves a specific purpose, which is well documented: to
provide data integrity without simultaneously providing
confidentiality.  While that's not often desirable, there are
certainly cases where it is a useful service.

But I don't see that the analogy carries over to null signatures.  The 
political/legal issues that stand in the way of universal
confidentiality don't apply.  As far as I can tell from the RFC, the
purpose is really just an encoding hack: a way of specifying that
signatures are omitted without saying it explictly.

So what good is that?

	paul


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27934 for <[e-mail]>; Tue, 26 Oct 1999 07:48:18 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA05707; Tue, 26 Oct 1999 07:48:56 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA20424; Tue, 26 Oct 1999 07:50:33 -0700 (PDT)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VH4XCRTD; Tue, 26 Oct 1999 07:50:52 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: New draft - NULL Public Key Signatures
Date: Tue, 26 Oct 1999 10:52:14 -0400
Message-ID: <000701bf1fc1$b0beb2a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <v04020a03b43abe53b3ee@[128.33.238.29]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal

Steve,

	Yes, I agree that the joke is pretty funny. I don't think turning
it into an RFC would improve the joke, and we may well find that the
joke ends up being on us.

	Given the ability of companies to mess up big time I can well imagine
some company selling a product claiming to be PKIX compliant, offering only
the NULL signature, export rules, licensing restrictions already mean that
many products ship requiring a crypto engine to be obtained elsewhere.

	If the product runs without security it is inevitable that someone will
use it without. I remember a while back when I persuaded a company that they
had a problem with a crypto implementation, sent them extensive
documentation
on the changes needed. A year later the product was broken with great media
fanfare. Turns out my memo had made it to the documentation but not the
code.

	Or it may just be that I am in a particularly humourless mood given
that there are a couple of nuclear plants in the vicinity and I have been
assured via the television that the events which occurred in Japan could
not occur in the US by 'experts' who clearly lack the level of knowledge of
nuclear processes taught at UK high schools.


	This thing we are building has to be usable by folk who _have_ a
degree in Nuclear Physics :-)


	Folk who need a NULL signature for Test purposes will probably find
that SHA-1 or MD5 can be used to the same effect, with the significant
advantage that integrity problems are revealled. I have a serious concern
that applying NULL in the context envisaged by Marc may remove an integrity
check which in the pure SSL context is not significant but which becomes
significant in a hybrid SSL/message passing system.

	The overhead of SHA-1 is low, we already have the OID. Ergo no need
for a NULL draft to confuse the befuddled holders of doctorates in nuclear
physics.


		Phill


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Monday, October 25, 1999 10:15 PM
> To: Phillip M Hallam-Baker
> Cc: [e-mail]
> Subject: RE: New draft - NULL Public Key Signatures
>
>
> Phill & Marc,
>
> This draft, which Ambarish and I discussed months ago, is written in the
> same spirit as RFC 2410, the NULL encryption algorithm and its use in ESP.
> Maybe we can clue in the otherwise clusless in the security considerations
> section, but we have precedent for this style of RFC. I didn't think of it
> as anything but a fun document which serves a very minimal (technical)
> purpose, but maybe my co-conspirator had more ambitious plans.
>
> Steve
>



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA23364 for <[e-mail]>; Tue, 26 Oct 1999 04:22:05 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01587; Tue, 26 Oct 1999 07:25:06 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-roadmap-04.txt
Date: Tue, 26 Oct 1999 07:25:06 -0400
Sender: [e-mail]

--NextPart

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

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA23331 for <[e-mail]>; Tue, 26 Oct 1999 04:22:01 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01575; Tue, 26 Oct 1999 07:25:01 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-ecdsa-02.txt
Date: Tue, 26 Oct 1999 07:25:00 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure  
                          Representation of Elliptic Curve Digital Signature    
                          Algorithm (ECDSA) Keys and Signatures in Internet     
                          X.509 Public Key Infrastructure Certificates
	Author(s)	: L. Bassham, D. Johnson, W. Polk
	Filename	: draft-ietf-pkix-ipki-ecdsa-02.txt
	Pages		: 15
	Date		: 22-Oct-99
	
This is the third draft of a profile for specification of Elliptic
Curve Digital Signature Algorithm (ECDSA) keys and signatures in
Internet Public Key Infrastructure X.509 certificates and certificate
revocation lists. This specification is an addendum to RFC 2459;
implementations must also conform to RFC 2459.  In addition, this
document references ANSI X9.62 for the specification of the ECDSA
algorithm.  This specification only addresses the format of ECDSA
keys and signatures.  Please send comments on this document to the
[e-mail] mail list.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki-ecdsa-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA21628 for <[e-mail]>; Tue, 26 Oct 1999 03:32:59 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id MAA37020 for <[e-mail]>; Tue, 26 Oct 1999 12:35:50 +0200
Message-ID: <[e-mail]>
Date: Tue, 26 Oct 1999 12:35:25 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Comments on dhpop-02
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Comments on draft-ietf-pkix-dhpop-02

The following comments are mainly presentation and vocabulary
oriented.

For the presentation, I read the document twice but could not have a
clear view of the description being made. I would guess that I would
need much more time to understand it, which I don't have.

This means that the document should be improved to ease the reading.
In particular the document refers upfront to two algorithms which
are not clearly referenced afterwards. The relationship between
sections 3,4 and 5 is not crystal clear.

My main concerns are vocabulary related. The document makes use of
the word "signature" whereas no signature is ever involved. 

I understand a signature as being verifiable by anyone. If it is
only verifiable (and thus forgeable) by one verifier, then it is
only an integrity check value.

The use of the word "signature" should be avoided and several
replacements are proposed. 

The current abstract is:

This document describes two methods for producing a signature from a
Diffie-Hellman key pair.  This behavior is needed for such
operations as creating a signature of a PKCS #10 certification
request.  These algorithms are designed to provide a proof-of-
possession rather than general purpose signing.

I would propose the following:

This document describes two methods for producing an integrity check
value from a Diffie-Hellman key pair.  This behavior is needed for
such operations as creating an integrity check value of a PKCS #10
certification request.  These algorithms are designed to provide a
proof-of- possession rather than general purpose signing.

Then, in the introduction, I would propose:

This document describes two new data origin authentication
algorithms using the Diffie- Hellman key agreement process to
provide a shared secret as the basis for the construction of an
integrity check value. With the first algorithm, the integrity check
value is constructed for a specific recipient/verifier by using a
D-H public key of that verifier.  With the second algorithm, the
integrity check value is constructed for arbitrary verifiers.  This
is done by creating an appropriate D-H key pair and using it for the
creation of the integrity check value.

The title of section 2 should be " Using DH Ephemeral keys for the
authentication process" and the next sentence: 

   The steps for creating a DH-based integrity check value are:



This does not provide all the changes required in the document but
gives the general direction for the replacements.

And additional unrelated topic. LeadingInfo and TrailingInfo are
introduced in section 3, page 3, item c) but only explained on the
next page in section 4. It would be good to move the explanations in
section 3. 

Denis


Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA26202 for <[e-mail]>; Mon, 25 Oct 1999 19:56:37 -0700 (PDT)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FK6WBF00.PG3 for <[e-mail]>; Tue, 26 Oct 1999 02:59:39 +0000 
Received: from nma.com ([209.21.28.126]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FK6WB000.20E; Tue, 26 Oct 1999 02:59:24 +0000 
Message-ID: <[e-mail]>
Date: Mon, 25 Oct 1999 19:59:58 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Phillip M Hallam-Baker <[e-mail]>, [e-mail]
Subject: Re: New draft - NULL Public Key Signatures
References: <[e-mail]> <v04020a03b43abe53b3ee@[128.33.238.29]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Phill & Marc,
>
> This draft, which Ambarish and I discussed months ago, is written in the
> same spirit as RFC 2410, the NULL encryption algorithm and its use in ESP.
> Maybe we can clue in the otherwise clusless in the security considerations
> section, but we have precedent for this style of RFC.

If you mean the section:

   NULL is a block cipher the origins of which appear to be lost in
   antiquity.  Despite rumors that the National Security Agency
   suppressed publication of this algorithm, there is no evidence of
   such action on their part. Rather, recent archaeological evidence
   suggests that the NULL algorithm was developed in Roman times, as an
   exportable alternative to Ceaser ciphers. However, because Roman
   numerals lack a symbol for zero, written records of the algorithm's
   development were lost to historians for over two millennia.

then out of place humor has just been redefined. Maybe it is indeed
time to consider technical writing rules when submitting RFCs, which
do not have to include references to "Ceaser" [SIC] in order to be
interesting.

Cheers,

Ed Gerck



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA25080 for <[e-mail]>; Mon, 25 Oct 1999 19:31:21 -0700 (PDT)
Received: from mega (t1o69p51.telia.com [62.20.144.51]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id EAA53685; Tue, 26 Oct 1999 04:31:25 +0200
Message-ID: <001401bf1f62$8f4086d0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "'SEIS-List'" <[e-mail]>, <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: "Magnus (RSA)" <[e-mail]>
Subject: Re: QC certificates MAY CERTAINLY be compared!
Date: Tue, 26 Oct 1999 04:31:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id TAA25082

Stefan,

1. The QC statemnent in question does not mention *different* issuers

2. The statement is still incorrect when applied to SEIS-cards from different
issuers as unique identity in those is "person-number" and nothing else.  Name is volatile.
I.e. SEIS-certs may very well be compared but you must restrict the comparision to
the attributes that form the STATIC and unique identity.  Regardless if the certs
are issued from the same or different issuers.

3.  No comments to the Container-ID stuff?

/Anders

-----Original Message-----
From: Stefan Santesson <[e-mail]>
To: Anders Rundgren <[e-mail]>; 'SEIS-List' <[e-mail]>; [e-mail] <[e-mail]>
Cc: Magnus (RSA) <[e-mail]>
Date: Monday, October 25, 1999 22:56
Subject: Re: QC certificates MAY CERTAINLY be compared!


Anders,

This is a consequence of the profile, not an opinion of utilization.

If you have two certificates issued by different issuers, and you compare
these certificates and find differences in the subject names, then you may
not be able to tell if these certificates are issued to the same individual
or not. At least not on the basis of what is defined in the QC profile.

This does not mean that you can not do name comparison in a "controlled
environment" based on some other knowledge.

/Stefan

At 17:55 1999-10-25 +0100, Anders Rundgren wrote:
>Stefan,
>I have said it before and I say it again.  The following QC-statement is 
>higly doubtful:
>
>"Comparing two qualified certificates to determine if they represent
> the same physical entity may provide misleading results and should
> not be performed"
>
>As you know our famous (?) SEIS-card does indeed allow certificates to
>be compared for subject identity.   That is IMO the whole (and only) point 
>with *real* ID-cards!
>
>So this is a statement of the CPS.  Not of the draft.
>
>
>
>BTW, why no explicit support for "container ID" (card serial) as most QCs 
>will be
>put in smart cards?  It was in SEIS already.
>
>
>Anders
>
>
>-----Original Message-----
>From: Stefan Santesson <[e-mail]>
>To: [e-mail] <[e-mail]>
>Date: Monday, October 25, 1999 14:14
>Subject: New submitted draft for Qualified Certificates
>
>
>>All,
>>
>>A new draft for a Qualified Certificates Profile was submitted friday 22.
>>
>>The new draft can be obtained from:
>>http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt
>>
>>The QC website has been udated accrodingly:
>>http://www.accurata.se/QC/
>>
>>See also under settled topics to obtain information about major
>>considerations since the last draft.
>>
>>/Stefan
>>-------------------------------------------------------------------
>>Stefan Santesson                <[e-mail]>
>>Accurata AB                     http://www.accurata.se
>>Slagthuset                      Tel. [phone]              
>>211 20  Malmö                   Fax. [phone]              
>>Sweden                        Mobile [phone]
>>
>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>-------------------------------------------------------------------
>>





Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23718 for <[e-mail]>; Mon, 25 Oct 1999 19:16:41 -0700 (PDT)
Received: from [128.33.238.29] (TC061.BBN.COM [128.33.238.61]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA03244; Mon, 25 Oct 1999 22:19:39 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a03b43abe53b3ee@[128.33.238.29]>
In-Reply-To: <002501bf1f24$9e1dcca0$[e-mail]>
References: <[e-mail]>
Date: Mon, 25 Oct 1999 22:14:39 -0400
To: "Phillip M Hallam-Baker" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: New draft - NULL Public Key Signatures
Cc: <[e-mail]>

Phill & Marc,

This draft, which Ambarish and I discussed months ago, is written in the
same spirit as RFC 2410, the NULL encryption algorithm and its use in ESP.
Maybe we can clue in the otherwise clusless in the security considerations
section, but we have precedent for this style of RFC. I didn't think of it
as anything but a fun document which serves a very minimal (technical)
purpose, but maybe my co-conspirator had more ambitious plans.

Steve


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23243 for <[e-mail]>; Mon, 25 Oct 1999 19:09:06 -0700 (PDT)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FK6U4700.5A2 for <[e-mail]>; Tue, 26 Oct 1999 02:12:07 +0000 
Received: from nma.com ([209.21.28.126]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FK6U3S00.G02 for <[e-mail]>; Tue, 26 Oct 1999 02:11:52 +0000 
Message-ID: <[e-mail]>
Date: Mon, 25 Oct 1999 19:12:26 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-roadmap-04.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
>
>         Title           : Internet X.509 Public Key Infrastructure PKIX Roadmap
>         Author(s)       : A. Arsenault, S. Turner
>         Filename        : draft-ietf-pkix-roadmap-04.txt
>         Pages           : 40
>         Date            : 22-Oct-99

>From the above draft:

   According to [SIMONETTI], the intent is that the digitalSignature bit
   should be set when what is desired is the ability to sign ephemeral
   transactions; e.g., for a single session authentication. These
   transactions are "ephemeral" in the sense that they are important
   only while they are in existence; after the session is terminated,
   there is no long-term record of the digital signature and its
   properties kept. When something is intended to be kept for some
   period of time, the nonRepudiation bit should be set.

The last phrase finds no support on what was discussed in this WG,
non-repudiation is not a non-ephemeral digital signature.

There are also other instances where the draft finds no support in
the WG discussions, even when it says it has:

    The discussion on the PKIX mailing list has centered on the
   digitalSignature bit and the nonRepudiation bit. The question has
   come down to something like: When support for the service of non-
   repudiation is desired, should both the digitalSignature and
   nonRepudiation bits be set, or just the nonRepudiation bit?

because this question was neither substantive nor representative
of the discussions -- unless "has come down to" means something
else.

Cheers,

Ed Gerck



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17081 for <[e-mail]>; Mon, 25 Oct 1999 14:56:40 -0700 (PDT)
Received: from foo.telia.se (t1o68p29.telia.com [62.20.138.29]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id XAA19165; Mon, 25 Oct 1999 23:59:35 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 26 Oct 1999 00:01:12 +0200
To: "Anders Rundgren" <[e-mail]>, "'SEIS-List'" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC certificates MAY CERTAINLY be compared!
Cc: "Magnus (RSA)" <[e-mail]>
In-Reply-To: <000801bf1f09$c9fbeac0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA17082

Anders,

This is a consequence of the profile, not an opinion of utilization.

If you have two certificates issued by different issuers, and you compare
these certificates and find differences in the subject names, then you may
not be able to tell if these certificates are issued to the same individual
or not. At least not on the basis of what is defined in the QC profile.

This does not mean that you can not do name comparison in a "controlled
environment" based on some other knowledge.

/Stefan

At 17:55 1999-10-25 +0100, Anders Rundgren wrote:
>Stefan,
>I have said it before and I say it again.  The following QC-statement is 
>higly doubtful:
>
>"Comparing two qualified certificates to determine if they represent
> the same physical entity may provide misleading results and should
> not be performed"
>
>As you know our famous (?) SEIS-card does indeed allow certificates to
>be compared for subject identity.   That is IMO the whole (and only) point 
>with *real* ID-cards!
>
>So this is a statement of the CPS.  Not of the draft.
>
>
>
>BTW, why no explicit support for "container ID" (card serial) as most QCs 
>will be
>put in smart cards?  It was in SEIS already.
>
>
>Anders
>
>
>-----Original Message-----
>From: Stefan Santesson <[e-mail]>
>To: [e-mail] <[e-mail]>
>Date: Monday, October 25, 1999 14:14
>Subject: New submitted draft for Qualified Certificates
>
>
>>All,
>>
>>A new draft for a Qualified Certificates Profile was submitted friday 22.
>>
>>The new draft can be obtained from:
>>http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt
>>
>>The QC website has been udated accrodingly:
>>http://www.accurata.se/QC/
>>
>>See also under settled topics to obtain information about major
>>considerations since the last draft.
>>
>>/Stefan
>>-------------------------------------------------------------------
>>Stefan Santesson                <[e-mail]>
>>Accurata AB                     http://www.accurata.se
>>Slagthuset                      Tel. [phone]              
>>211 20  Malmö                   Fax. [phone]              
>>Sweden                        Mobile [phone]
>>
>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>-------------------------------------------------------------------
>>



Received: from crack.x509.com ([e-mail] [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16488 for <[e-mail]>; Mon, 25 Oct 1999 14:25:26 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id OAA13366 for <[e-mail]>; Mon, 25 Oct 1999 14:28:27 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 25 Oct 1999 14:37:22 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: New draft - NULL Public Key Signatures
References: <002501bf1f24$9e1dcca0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phillip M Hallam-Baker wrote:
> 
> At the very least I would want to see a very clear message stating
> that this mechanism offers no security and is for test purposes only.
> 
> Unfortunately the text is written with the assumption that the reader
> understands the purpose.

I disagree about it being only useful for test purposes.  For the same
reason, given below, I disagree when you say:

> 
> I don't think that the same case can be made for the need for a NULL
> integrity algorithm as for a NULL confidentiality algorithm. The need
> for the NULL IPSEC method arose because it is very hard to debug
> a system when you can't read any messages
> 

A NULL signture algorithm is just what the doctor ordered for getting rid of
signature baggage when authentication and integrity are provided by other
means.

I'll grant that the need for this only arises in very specific circumstances,
but to relegate it to just testing is going too far.  The particular
circumstance I have in mind, BTW, is when you're doing something like OCSP
over SSL, _and_ you don't care about future non-repudiation.  In that
specific case, the SSL protection and the OCSP signature are redundant.  It
would be nice to finesse away the OCSP signature.  This would allow
optimizations like reusing the SSL session key, to avoid costly PK
operations.

As to the draft's humour, perhaps it is a bit misplaced.  It would be better
not to undermine the serious applications of the algorithm.

		Marc


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15108 for <[e-mail]>; Mon, 25 Oct 1999 13:04:28 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id NAA00779; Mon, 25 Oct 1999 13:05:02 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id NAA18847; Mon, 25 Oct 1999 13:06:15 -0700 (PDT)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VH4XC2VR; Mon, 25 Oct 1999 13:06:33 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>, <[e-mail]>
Subject: RE: New draft - NULL Public Key Signatures
Date: Mon, 25 Oct 1999 16:07:51 -0400
Message-ID: <002501bf1f24$9e1dcca0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal

I just got round to reading the draft. I find the levity unnecessary
and somewhat disturbing.

>1.  Introduction
>
>   This memo defines the NULL public key algorithm. It explains how NPKA
>   NULL algorithm should be used both for digital signatures and
>   encryption/key exchange.

>   Despite the fact that we are not lawyers, we are relatively confident
>   that it is quite safe to use this algorithm for export for any key
>   length size. It is also quite impossible for people to discover your
>   private key via timing, power analysis or other cryptographic
>   methods, as long as you are only using this algorithm.

At the very least I would want to see a very clear message stating
that this mechanism offers no security and is for test purposes only.

Unfortunately the text is written with the assumption that the reader
understands the purpose.

I don't think that the same case can be made for the need for a NULL
integrity algorithm as for a NULL confidentiality algorithm. The need
for the NULL IPSEC method arose because it is very hard to debug 
a system when you can't read any messages


The humourous references to the attacks the scheme is proof against
are I suspect likely to fall flat when some knuckle-brain implements
this and uses it for a real purpose. 

If workers at a nuclear fuel reprocessing plant can be ill trained 
enough to willingly carry buckets of enriched uranium about the place
by hand methinks we should not underestimate the risk of overestimating
the general level of competence.


		Phill

> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Tuesday, October 19, 1999 7:16 PM
> To: [e-mail]
> Subject: New draft - NULL Public Key Signatures
> 
> 
> 
> Hi Guys,
>     Given the traffic on this list, it sounds like this IETF is
> going to be a pretty boring one. :-)
> 
> I have just submitted an individual draft about NULL Public Key
> Signatures, which I hope will be part of this working group soon
> (make things at the PKIX meeting more interesting).
> 
> The main (serious) reason for this draft, is to allow people to
> describe data items that may be signed or unsigned more easily
> in ASN.1.
> 
> Also, having a NULL algorithm is asthetically pleasing.
> 
> So here it is.
> 
> Please send all your flames/comments to this list.
> 
> Thanks,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 
> 


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA10989 for <[e-mail]>; Mon, 25 Oct 1999 08:56:09 -0700 (PDT)
Received: from mega (t3o69p96.telia.com [62.20.145.96]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id RAA43417; Mon, 25 Oct 1999 17:56:00 +0200
Message-ID: <000801bf1f09$c9fbeac0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "'SEIS-List'" <[e-mail]>, "Stefan Santesson" <[e-mail]>, <[e-mail]>
Cc: "Magnus (RSA)" <[e-mail]>
Subject: QC certificates MAY CERTAINLY be compared!
Date: Mon, 25 Oct 1999 17:55:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA10990

Stefan,
I have said it before and I say it again.  The following QC-statement is higly doubtful:

"Comparing two qualified certificates to determine if they represent
 the same physical entity may provide misleading results and should
 not be performed"

As you know our famous (?) SEIS-card does indeed allow certificates to
be compared for subject identity.   That is IMO the whole (and only) point with *real* ID-cards!

So this is a statement of the CPS.  Not of the draft.



BTW, why no explicit support for "container ID" (card serial) as most QCs will be
put in smart cards?  It was in SEIS already.


Anders


-----Original Message-----
From: Stefan Santesson <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Monday, October 25, 1999 14:14
Subject: New submitted draft for Qualified Certificates


>All,
>
>A new draft for a Qualified Certificates Profile was submitted friday 22.
>
>The new draft can be obtained from:
>http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt
>
>The QC website has been udated accrodingly:
>http://www.accurata.se/QC/
>
>See also under settled topics to obtain information about major
>considerations since the last draft.
>
>/Stefan
>-------------------------------------------------------------------
>Stefan Santesson                <[e-mail]>
>Accurata AB                     http://www.accurata.se
>Slagthuset                      Tel. [phone]              
>211 20  Malmö                   Fax. [phone]              
>Sweden                        Mobile [phone]
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10838 for <[e-mail]>; Mon, 25 Oct 1999 08:55:31 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id RAA55768; Mon, 25 Oct 1999 17:58:10 +0200
Message-ID: <[e-mail]>
Date: Mon, 25 Oct 1999 17:57:42 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: updated path validation text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim,

Thanks for sending the section in advance, since we have not yet
since the draft, that was (?) posted by 5PM on October 22.  :-)

> Folks,
> 
> We are currently editing "son-of-RFC 2459" which should - no, *will* - be
> posted by 5PM on October 22 (that is, before the Washington meeting
> cut-off).  In general, that should be plenty of time to review and discuss
> before the meeting.  Most of it is minor stuff, and pretty straightforward.

(text deleted)

> Please take a long, hard look at this text!  Your comments are appreciated!

Since you asked, here is some feedback.

In RFC 2459, we had five state variables, now we have twelve !
Verifying the accuracy of the whole description can only be done
while implementing the specification. However, besides the
complexity, I would like to point to some concerns.

I tried to read the text as a new reader and found that the text on
contrained subtrees works fine when subject (DN) names are used, but
it is not clear to understand the description when subjectAltNames
are used in leaf certificates.

Another concern is the following : the whole approach is implictly
making the assumption that all the information for path validation
is within the certificates themselves. This is one approach. Another
approach, which can be used in combination, is to allow some of the
information normally carried out in certificates (e.g. the
equivalent of the contrained subtrees) to be defined in a local
policy. The text should allow for that alternative.

Denis
 
> Thanks,
> 
> Tim Polk


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10117 for <[e-mail]>; Mon, 25 Oct 1999 08:10:30 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id RAA27644 for <[e-mail]>; Mon, 25 Oct 1999 17:13:14 +0200
Message-ID: <[e-mail]>
Date: Mon, 25 Oct 1999 17:12:46 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Comments on ac509prof-01
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

First of all, thanks for Stephen and Russ, for providing the
document in time. It has a much better shape and content when
compared to the previous version. I have however several comments:

The document is far too authorization oriented (as the current PDAM
from ISO). While the basic content of the document is in the right
direction, the abstract is not appropriate. The reader does not care
too much about the possible uses of the attribute certificates, but
care about what they are.

The current abstract is:

 Authorization services are required for numerous Internet
protocols,
 including TLS, IPSec, and S/MIME. The X.509 Attribute Certificate
 provides a structure that can form the basis for such services
 [X.509]. This specification defines a profile for the use of X.509
 Attribute Certificates to provide authorization services for
 Internet protocols. Some optional features are also specified which
 are not required for conformance to the base profile.

The document contents however (misplaced in section 4) a very good
abstract that should be reused to replace the current abstract. Here
is a proposal:

   This specification defines a profile for the use of X.509
   Attribute Certificates. Attribute certificates may be used in 
   a wide range of applications and environments covering a broad 
   spectrum of interoperability goals and a broader spectrum of 
   operational and assurance requirements. The goal of this document
   is to establish a common baseline for generic applications 
   requiring broad interoperability and limited special purpose 
   requirements.  In particular, the emphasis will be on supporting 
   the use of attribute certificates for informal Internet
electronic
   mail, IPSec, and WWW applications.


The section 4.2 about Object Identifiers is misplaced, since it is a
recap of what is supported but no explanations are provided at this
time about their rational.


AAControls are introduced in section 4.6.1 where it is said: "

   The AAControls PKC extension, intended to be used in CA 
   and AC Issuer PKCs, *MAY* be used to help answer the question.

However in section 5 on Attribute Certificate Validation we have the
following text:

 2. All PKC's on the path from the AA CA down to and including the
    AC issuer's PKC *MUST* contain an aaControls extension as
defined
    below (the PKC with the AA CA's as subject need not contain
    this extension).
 3. Only those attributes in the AC which are allowed according to
    all of the aaControls extension values in all of the PKCs from
    the AA CA to the AC issuer, may be used for authorization
    decisions, all other attributes MUST be ignored ...

This is contradictory. There are basically at least two environments
where AC can be used: an on-line authorization scheme and a
store-and-forward environment manipulating signed messages linked to
ACs. Only one environment is really addressed here and there is no
reason to impose the use of AAControls to both environments.
Furthermore when using ACs in an on-line access control scheme the
use of AA controls is not a must. If the access enforcement function
uses an authorization scheme using both the name of the Attribute
Authority and the value of the attribute, there is no need to make
sure that the AC is trusted to issue any attribute value. For these
reasons, the use of AAControls is not needed at all. There are two
options: suppress them or make them truly optional.

Other detailed comments

On page 4, we have the following paragraph:

   In other cases, it is more suitable for a client simply to
   authenticate to the server and for the server to request ("pull")
   the client's AC from an AC issuer or a repository. A major
benefit
   of the "pull" model is that it can be implemented without changes
to
   the client or client-server protocol. It is also more suitable
for
   some inter-domain cases where the client's rights should be
assigned
   within the server's domain, rather than within the client's
"home"
   domain.

It would be nice to warn the user about the disadvantages of the
pull model. It is thus proposed to add the following after the
second sentence.

A major disadvantage of the "pull" model is that without any change
a receiving entity does not know which attribute certificate to use
and thus the principle of least privilege cannot be supported. In
addition, all attributes certificates are not necessarily public and
thus instead of providing a complex access control scheme to
restrict the access to those attribute certificates, the scheme is
better suited to public attributes or to attributes used in a closed
domain.

At the top of page 10. The first sentence reads: 
   For any protocol where the AC is passed in an authenticated
message ...

It should be noticed that attribute certificates are not necessarily
used in a protocol, but also in data structures (e.g. a signed
message). The sentence should be changed to:

   For any environment where the AC is passed in an authenticated
message ...


Side comments

Section 4.5.1 is for legacy systems and it is questionable if the
complexity involved by the encipherment does not negate its
practical use. 

In section 4.5.2 (Access Identity), the syntax encourages for a
multiplicity of names, one for each service, whereas the PKI
encourages for the reverse. In fact, in that case attribute
certificates are not more used to carry attributes like roles, but
names instead.

Denis


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08385 for <[e-mail]>; Mon, 25 Oct 1999 06:12:33 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id PAA13639 for <[e-mail]>; Mon, 25 Oct 1999 15:15:30 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 25 Oct 1999 15:15:58 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: New submitted draft for Qualified Certificates
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA08386

All,

A new draft for a Qualified Certificates Profile was submitted friday 22.

The new draft can be obtained from:
http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt

The QC website has been udated accrodingly:
http://www.accurata.se/QC/

See also under settled topics to obtain information about major
considerations since the last draft.

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

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


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05418 for <[e-mail]>; Mon, 25 Oct 1999 03:58:29 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03489; Mon, 25 Oct 1999 07:01:27 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-roadmap-04.txt
Date: Mon, 25 Oct 1999 07:01:27 -0400
Sender: [e-mail]

--NextPart

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

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05406 for <[e-mail]>; Mon, 25 Oct 1999 03:58:23 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03477; Mon, 25 Oct 1999 07:01:21 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-ecdsa-02.txt
Date: Mon, 25 Oct 1999 07:01:21 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure  
                          Representation of Elliptic Curve Digital Signature    
                          Algorithm (ECDSA) Keys and Signatures in Internet     
                          X.509 Public Key Infrastructure Certificates
	Author(s)	: L. Bassham, D. Johnson, W. Polk
	Filename	: draft-ietf-pkix-ipki-ecdsa-02.txt
	Pages		: 15
	Date		: 22-Oct-99
	
This is the third draft of a profile for specification of Elliptic
Curve Digital Signature Algorithm (ECDSA) keys and signatures in
Internet Public Key Infrastructure X.509 certificates and certificate
revocation lists. This specification is an addendum to RFC 2459;
implementations must also conform to RFC 2459.  In addition, this
document references ANSI X9.62 for the specification of the ECDSA
algorithm.  This specification only addresses the format of ECDSA
keys and signatures.  Please send comments on this document to the
[e-mail] mail list.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki-ecdsa-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from ns.cmbchina.com ([202.96.161.112]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA28927 for <[e-mail]>; Sun, 24 Oct 1999 01:06:46 -0700 (PDT)
Received: from cmbchina.com ([10.1.4.27]) by ns.cmbchina.com (Netscape Messaging Server 3.01)  with ESMTP id AAA20366 for <[e-mail]>; Sun, 24 Oct 1999 16:09:01 -0800
Message-ID: <[e-mail]>
Date: Sun, 24 Oct 1999 16:08:53 +0800
From: "Xiong Shao Jun" <[e-mail]>
Organization: China Merchants Bank
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: directory entry with NULL DN
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi, there. I posted a mail a few days ago, but received no reply.
I have some questions about rfc2587. If a PKI subject has null
DN in certificate, how can it have an entry in LDAP?

Thanx in advance.

Xiong Shaojun
China Merchants Bank



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA11486 for <[e-mail]>; Fri, 22 Oct 1999 15:42:26 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id PAA08740; Fri, 22 Oct 1999 15:45:11 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 22 Oct 1999 15:45:26 -0700
To: Paul Koning <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Semantics
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:09 PM 10/22/99 -0400, you wrote:
>>>>>> "Tony" == Tony Bartoletti <[e-mail]> writes:
>
> Tony> At 04:46 PM 10/22/99 -0400, Michael Duren wrote:
>
> Mike> Denis,
>  
> Mike> In looking at the TSP specification, I have one observation.
>  
> Mike> In section 2.1 of the document, it is stated that the serial
> Mike> number shall be "a monotonically incrementing integer for each
> Mike> newly generated time stamp token".  However, in section 2.4.2
> Mike> when the meaning and the usage of the serial number is
> Mike> discussed, it is referred to as "a strictly monotonically
> Mike> increasing integer."
>  
> Mike> My understanding is that "monotonically increasing" values can
> Mike> be equal (i.e. the time value is monotonically increasing) and
> Mike> "strictly increasing" values cannot have equal values.  I am
> Mike> not sure what "strictly monotonically increasing" implies.
> Mike> Seems to me that the serial number should be referred to as
> Mike> "strictly increasing" or "unique and monotonically increasing"
> Mike> in both places.
>  
> Mike> Any comments?
>  
> Mike> Mike Duren
>
> Tony> "Strictly" speaking, you are correct.
>
> Tony> The sequence <2,5,7,7,7,9> is monotonically increasing because
> Tony> it never decreases.
>
> Tony> Uniqueness (1-to-1 mapping) requires a "strictly increasing"
> Tony> (or decreasing) seq.
>
>That doesn't match the terminology I'm familiar with.
>
>2,5,7,7,7... is "monotonically non-decreasing" but it is not
>"monotonically increasing".

I believe the term "monotonic sequence" is intended to imply that
the sign (+/-) of the differences never changes.  It is either
always "+" or always "-", which allows "+0" or "-0".  Since this
leads to 4 possibilities, some schools take "strictly" as a
refinement of monotonic, and I suppose some instead take "increasing"
as a refinement of "non-decreasing".

Come to think of it, with "increasing, decreasing, non-increasing,
and non-decreasing" understood, the term "monotonic" becomes redundant. 

I agree, as you state below, that we should avoid terms that
may be misinterpreted, and try to use "plain english" where possible.

>But given that there appear to be differing interpretations of the
>terminology, it would be best not to use these ambiguous technical
>terms but rather describe in plain english what the required property
>is (i.e., "each value must be > than its predecessor" or "each value
>must be >= its predecessor" depending on which is wanted).
>
>	paul
>
>

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA10953 for <[e-mail]>; Fri, 22 Oct 1999 15:07:10 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhmbw18402; Fri, 22 Oct 1999 22:09:48 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA07467; Fri, 22 Oct 99 18:07:55 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id SAA27476; Fri, 22 Oct 1999 18:09:47 -0400
Date: Fri, 22 Oct 1999 18:09:47 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Semantics
References: <002001bf1cce$8d3402e0$1146d8d1@Mike> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Tony" == Tony Bartoletti <[e-mail]> writes:

 Tony> At 04:46 PM 10/22/99 -0400, Michael Duren wrote:

 Mike> Denis,
  
 Mike> In looking at the TSP specification, I have one observation.
  
 Mike> In section 2.1 of the document, it is stated that the serial
 Mike> number shall be "a monotonically incrementing integer for each
 Mike> newly generated time stamp token".  However, in section 2.4.2
 Mike> when the meaning and the usage of the serial number is
 Mike> discussed, it is referred to as "a strictly monotonically
 Mike> increasing integer."
  
 Mike> My understanding is that "monotonically increasing" values can
 Mike> be equal (i.e. the time value is monotonically increasing) and
 Mike> "strictly increasing" values cannot have equal values.  I am
 Mike> not sure what "strictly monotonically increasing" implies.
 Mike> Seems to me that the serial number should be referred to as
 Mike> "strictly increasing" or "unique and monotonically increasing"
 Mike> in both places.
  
 Mike> Any comments?
  
 Mike> Mike Duren

 Tony> "Strictly" speaking, you are correct.

 Tony> The sequence <2,5,7,7,7,9> is monotonically increasing because
 Tony> it never decreases.

 Tony> Uniqueness (1-to-1 mapping) requires a "strictly increasing"
 Tony> (or decreasing) seq.

That doesn't match the terminology I'm familiar with.

2,5,7,7,7... is "monotonically non-decreasing" but it is not
"monotonically increasing".

But given that there appear to be differing interpretations of the
terminology, it would be best not to use these ambiguous technical
terms but rather describe in plain english what the required property
is (i.e., "each value must be > than its predecessor" or "each value
must be >= its predecessor" depending on which is wanted).

	paul


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA10586 for <[e-mail]>; Fri, 22 Oct 1999 14:52:47 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id OAA12651; Fri, 22 Oct 1999 14:55:15 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 22 Oct 1999 14:55:30 -0700
To: "Michael Duren" <[e-mail]>, "Denis Pinkas" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Semantics
Cc: <[e-mail]>
In-Reply-To: <002001bf1cce$8d3402e0$1146d8d1@Mike>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"

At 04:46 PM 10/22/99 -0400, Michael Duren wrote: 

>>>>

<excerpt><smaller>Denis,

</smaller>  

<smaller>In looking at the TSP specification, I have one observation.

</smaller>  

<smaller>In section 2.1 of the document, it is stated that the serial
number shall be "a monotonically incrementing integer for each newly
generated time stamp token".  However, in section 2.4.2 when the meaning
and the usage of the serial number is discussed, it is referred to as "a
strictly monotonically increasing integer."

</smaller>  

<smaller>My understanding is that "monotonically increasing" values can
be equal (i.e. the time value is monotonically increasing) and "strictly
increasing" values cannot have equal values.  I am not sure what
"strictly monotonically increasing" implies.  Seems to me that the serial
number should be referred to as "strictly increasing" or "unique and
monotonically increasing" in both places.

</smaller>  

<smaller>Any comments?

</smaller>  

<smaller>Mike Duren

</smaller>  

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


"Strictly" speaking, you are correct.


The sequence <<2,5,7,7,7,9> is monotonically increasing because it never
decreases.


Uniqueness (1-to-1 mapping) requires a "strictly increasing" (or
decreasing) seq.


___tony___ (Hey, that MS in math finally paid off!)






Tony Bartoletti                                             LL

IOWA Center                                              LL LL

Lawrence Livermore National Laboratory                LL LL LL

PO Box 808, L - 089                                   LL LL LL

Livermore, CA 94551-9900                              LL LL LLLLLLLL

phone: [phone]   fax: [phone]               LL LLLLLLLL

email: [e-mail]                                   LLLLLLLL


Received: from emerald.lightlink.com ([e-mail] [205.232.34.14]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA07054 for <[e-mail]>; Fri, 22 Oct 1999 14:04:21 -0700 (PDT)
Received: from Mike ([209.216.70.17]) by emerald.lightlink.com (8.8.8/8.8.8) with ESMTP id RAA32212; Fri, 22 Oct 1999 17:07:02 -0400
Message-ID: <002001bf1cce$8d3402e0$1146d8d1@Mike>
Reply-To: "Michael Duren" <[e-mail]>
From: "Michael Duren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: Semantics
Date: Fri, 22 Oct 1999 16:46:34 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01BF1CAD.00235A20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01BF1CAD.00235A20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Denis,
=20
In looking at the TSP specification, I have one observation.
=20
In section 2.1 of the document, it is stated that the serial number =
shall be "a monotonically incrementing integer for each newly generated =
time stamp token".  However, in section 2.4.2 when the meaning and the =
usage of the serial number is discussed, it is referred to as "a =
strictly monotonically increasing integer."
=20
My understanding is that "monotonically increasing" values can be equal =
(i.e. the time value is monotonically increasing) and "strictly =
increasing" values cannot have equal values.  I am not sure what =
"strictly monotonically increasing" implies.  Seems to me that the =
serial number should be referred to as "strictly increasing" or "unique =
and monotonically increasing" in both places.
=20
Any comments?

Mike Duren
=20

------=_NextPart_000_001B_01BF1CAD.00235A20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Denis,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>In looking at the TSP specification, =
I have one=20
observation.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>In section 2.1 of the document, it is stated that =
the serial=20
number shall be &quot;a monotonically incrementing integer for each =
newly=20
generated time stamp token&quot;.&nbsp; However, in section 2.4.2 when =
the=20
meaning and the usage of the serial number is discussed, it is referred =
to as=20
&quot;a strictly monotonically increasing integer.&quot;</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>My understanding is that &quot;monotonically =
increasing&quot;=20
values can be equal (i.e. the time value is monotonically increasing) =
and=20
&quot;strictly increasing&quot; values cannot have equal values.&nbsp; I =
am not=20
sure what &quot;strictly monotonically increasing&quot; implies.&nbsp;=20
</FONT><FONT size=3D2>Seems to me that the serial number should be =
referred to as=20
&quot;strictly increasing&quot; or &quot;unique and monotonically=20
increasing&quot; in both places.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Any comments?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Mike Duren</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_001B_01BF1CAD.00235A20--



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA06497 for <[e-mail]>; Fri, 22 Oct 1999 13:59:50 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA25422; Fri, 22 Oct 1999 13:53:56 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 22 Oct 1999 13:23:42 -0400
To: Francois Rousseau <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-ac509prof-01.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

Francois:

This is a topic for the IETF meeting.  There is also an issue of 
compatibility with RFC 2530.

Russ


At 04:34 PM 10/19/99 -0400, Francois Rousseau wrote:
>Russ and/or Steve,
>
>The syntax of the issuer field in version 2 ACs was modified in the X.509
>FPDAM such there would not be a need for the authorityKeyIdentifier
>extension in an AC to assist the AC verifier in checking the signature of
>the AC. By instead filling the optional baseCertificateId component of the
>issuer field, the intend was that you would achieve the same result without
>using any extensions, which is also the approach recommended in the X.509
>FPDAM. The only reason the issuerName component of the issuer field was
>left was for backward compatibility with version 1 ACs as defined in
>X.509(97).
>
>In addition, I do not see the argument at paragraph 4.3.3 when you say
>using the baseCertificateId field to reference the AC issuer would mean
>that the AC verifier would be dependent on the AC issuer's public key
>infrastructure.
>
>François



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA04391 for <[e-mail]>; Fri, 22 Oct 1999 13:30:58 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VJST66NF>; Fri, 22 Oct 1999 13:24:07 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Zahid Ahmed <[e-mail]>, "Luo, Feng (Exchange)" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: certificate chain
Date: Fri, 22 Oct 1999 13:24:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> -----Original Message-----
> From: Zahid Ahmed [mailto:[e-mail]]
> Sent: Friday, October 22, 1999 11:44 AM
> To: Peter Williams; Luo, Feng (Exchange); '[e-mail]'
> Subject: RE: certificate chain
> 
> 
> I think validating the server cert is necessary but
> not sufficient. Validating that the CA root public
> cert is a trusted CA would also be required in many
> clients. However, it seems that many SSL clients do
> not do this (including browsers?). So, I think, in
> practice we do have different levels of cert-based
> authe going on.

Each vendor does their own validation procedures on
the certiifcate processes of SSL; this is correct,
as SSL does not standardize those processes. It
is also consistent with the design of a "socket"
protocol.  


> 
> In the case of anonymously-originated messages, the
> (web) servers still need to be validated; the clients,
> i.e., the senders, could be anonymous. 

This is one option.  SSL also enables the server
to be anonymous ; that is,  it does not cite a certificate.

This means that a vendor client UA must have other
means to authenticate the server's handshake msgs; this may
mean that the server cert is locally supplied by the client
based on the src-address of the socket, or non-certificate 
based techniques are used.

This design ensure that SSL sockets can address multiuple
applications, without being tied to any given application; it 
allows for either server or client side path formation
according to the needs of the sockct application, for
either party. Furthermore, neither side is required
to use the certs which are delivered in the SSL stream,
it can always use an alternative chain, or no
chain at all.

Peter.

These features are important elements of SSL design. They
limit the power of CAs, or one of the parties, to control
communications. SSL does enable the parties to leverage
third-parties to remove the element of mutual suspicion.
Any further role of third-parties in an SSL design is
upto the vendors application; https is one such
semi-standardized concept linking SSL to UA-web-centered
http.
> 
> 
> 
> 
> > -----Original Message-----
> > From: Peter Williams [mailto:[e-mail]]
> > Sent: Thursday, October 21, 1999 5:34 PM
> > To: Luo, Feng (Exchange); '[e-mail]'
> > Subject: RE: certificate chain
> > 
> > 
> > 
> > SSL does not specify the rules for certificate chain
> > validation. Also remember, that an SSL handshake
> > can use anonymously-originated messages in either 
> > direction.
> > 
> > TLS systems have to offer the backwards compatible
> > with SSL v3, which means that TLS systems
> > must process v1 certs.
> > 
> > 
> > > -----Original Message-----
> > > From: Luo, Feng (Exchange) [mailto:[e-mail]]
> > > Sent: Thursday, October 21, 1999 5:29 PM
> > > To: '[e-mail]'
> > > Subject: certificate chain
> > > 
> > > 
> > > In the SSL handshake, what's the standard that the 
> > SSL-enabled client
> > > authenticates the SSL-enabled sever in the certificate chain 
> > > of the web
> > > server. It seems like that the Netscape browser and IE only 
> > > look at the
> > > server certificate sent by the web server, but the Marimba 
> > > tuner is looking
> > > at not only the server certificate but also the CA 
> > > certificate which issued
> > > that server certificate.
> > > Can some one tell me which method is the RFC standard? Where 
> > > can I have the
> > > documentation on this?
> > > 
> > > Thanks
> > > Feng
> > > 
> > > 
> > > **************************************************************
> > > *********
> > > Bear Stearns is not responsible for any recommendation, 
> > solicitation, 
> > > offer or agreement or any information about any 
> > transaction, customer 
> > > account or account activity contained in this communication.
> > > **************************************************************
> > > *********
> > > 
> > 
> 


Received: from generalserver3.commerceone.com (mail.commerceone.com [204.71.220.19]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA27186 for <[e-mail]>; Fri, 22 Oct 1999 11:48:48 -0700 (PDT)
Received: by GENERALSERVER3 with Internet Mail Service (5.5.2448.0) id <VJHF7H4B>; Fri, 22 Oct 1999 11:46:58 -0700
Message-ID: <[e-mail]>
From: Zahid Ahmed <[e-mail]>
To: Peter Williams <[e-mail]>, "Luo, Feng (Exchange)" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: certificate chain
Date: Fri, 22 Oct 1999 11:44:24 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

I think validating the server cert is necessary but
not sufficient. Validating that the CA root public
cert is a trusted CA would also be required in many
clients. However, it seems that many SSL clients do
not do this (including browsers?). So, I think, in
practice we do have different levels of cert-based
authe going on.

In the case of anonymously-originated messages, the
(web) servers still need to be validated; the clients,
i.e., the senders, could be anonymous. 




> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Thursday, October 21, 1999 5:34 PM
> To: Luo, Feng (Exchange); '[e-mail]'
> Subject: RE: certificate chain
> 
> 
> 
> SSL does not specify the rules for certificate chain
> validation. Also remember, that an SSL handshake
> can use anonymously-originated messages in either 
> direction.
> 
> TLS systems have to offer the backwards compatible
> with SSL v3, which means that TLS systems
> must process v1 certs.
> 
> 
> > -----Original Message-----
> > From: Luo, Feng (Exchange) [mailto:[e-mail]]
> > Sent: Thursday, October 21, 1999 5:29 PM
> > To: '[e-mail]'
> > Subject: certificate chain
> > 
> > 
> > In the SSL handshake, what's the standard that the 
> SSL-enabled client
> > authenticates the SSL-enabled sever in the certificate chain 
> > of the web
> > server. It seems like that the Netscape browser and IE only 
> > look at the
> > server certificate sent by the web server, but the Marimba 
> > tuner is looking
> > at not only the server certificate but also the CA 
> > certificate which issued
> > that server certificate.
> > Can some one tell me which method is the RFC standard? Where 
> > can I have the
> > documentation on this?
> > 
> > Thanks
> > Feng
> > 
> > 
> > **************************************************************
> > *********
> > Bear Stearns is not responsible for any recommendation, 
> solicitation, 
> > offer or agreement or any information about any 
> transaction, customer 
> > account or account activity contained in this communication.
> > **************************************************************
> > *********
> > 
> 


Received: from antimony.network-alchemy.com (Antimony.Network-Alchemy.COM [199.46.17.226]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA16927 for <[e-mail]>; Fri, 22 Oct 1999 09:30:44 -0700 (PDT)
Received: (from briank@localhost) by antimony.network-alchemy.com (8.8.8/8.8.8) id JAA10094; Fri, 22 Oct 1999 09:31:41 -0700 (PDT) (envelope-from briank)
From: Brian Korver <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: CRACK
In-Reply-To: <[e-mail]> from Ari Huttunen at "Oct 22, 99 06:14:01 pm"
To: [e-mail] (Ari Huttunen)
Date: Fri, 22 Oct 1999 09:31:41 -0700 (PDT)
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
X-Mailer: ELM [version 2.4ME+ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Ari Huttunen writes:
> There's another architectural thing you should consider. What about modifying
> the protocol so that when the server starts believing in the authenticity of the
> client, the server issues the client's public key a certificate? This certificate
> would have a very limited life-time, just enough for the purpose at hand.
> It would be transported to the client in the 'last' message, whatever that is.
> 
> Although this creates more public key operations, the legacy authentication
> functionality could be located on a different physical box than the actual
> security gateway.. This achieves a very similar function to the Kerberos ticket
> granting server, and the certificate is similar to Kerberos tickets. You'd of
> course have to set up the trust relations appropriately.
> 
> There could also exist "one time certificates" that can be used only once
> during their life-time to gain access, similar to one time passwords. Some
> way or another they would be revoked the moment they are used.
> 
> (CPU is basically very cheap. If not this year, then perhaps next..)

We thought about that, but there are already perfectly good protocols
for obtaining certificates (CEP, PKIX, whatever) and these certificates
could be short-lived for exactly this purpose.  On the other hand,
as you point out, this is a more heavyweight mechanism.  Hence
the draft.

brian
[e-mail]


Received: from dfintra.datafellows.com (dfintra.datafellows.com [194.197.29.8]) by mail.imc.org (8.9.3/8.9.3) with SMTP id IAA11123 for <[e-mail]>; Fri, 22 Oct 1999 08:10:47 -0700 (PDT)
Received: (qmail 22079 invoked from network); 22 Oct 1999 15:12:56 -0000
Received: from df129-180.datafellows.com (HELO DataFellows.com) (10.128.129.180) by dfintra.datafellows.com with SMTP; 22 Oct 1999 15:12:56 -0000
Message-ID: <[e-mail]>
Date: Fri, 22 Oct 1999 18:14:01 +0300
From: Ari Huttunen <[e-mail]>
Organization: Data Fellows Oyj
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Brian Korver <[e-mail]>
CC: "Waters, Stephen" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: CRACK
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(PKIX: CRACK refers to draft-harkins-ipsec-ike-crack-00.txt.)

Brian Korver wrote:

> Waters, Stephen writes:
> > Hi Dan,
> >
> > Looks good.
> >
> > Where did CRACK come from? A dubious name in a security protocol.

A very catching marketing trick, I presume. ;-)

>
> >
> > Can the client's private/public key be unique for each connection?
>
> Sure.  But that would require an implementation+policy that would generate
> a separate IKE SA for each connection.  If you connect frequently, I'm not
> sure you would want that.
>

There's another architectural thing you should consider. What about modifying
the protocol so that when the server starts believing in the authenticity of the
client, the server issues the client's public key a certificate? This certificate
would have a very limited life-time, just enough for the purpose at hand.
It would be transported to the client in the 'last' message, whatever that is.

Although this creates more public key operations, the legacy authentication
functionality could be located on a different physical box than the actual
security gateway.. This achieves a very similar function to the Kerberos ticket
granting server, and the certificate is similar to Kerberos tickets. You'd of
course have to set up the trust relations appropriately.

There could also exist "one time certificates" that can be used only once
during their life-time to gain access, similar to one time passwords. Some
way or another they would be revoked the moment they are used.

(CPU is basically very cheap. If not this year, then perhaps next..)

>
> >
> >
> > Steve.
>
> brian
> [e-mail]

--
Ari Huttunen                   phone: [phone]
Senior Software Engineer       fax  : [phone]

Data Fellows Corporation       http://www.DataFellows.com

F-Secure products: Integrated Solutions for Enterprise Security




Received: from matrix3 (zoovan-nas2-18.zoolink.com [216.94.40.146]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA12022 for <[e-mail]>; Fri, 22 Oct 1999 03:01:41 -0700 (PDT)
From: [e-mail]
Received: from mail pickup service by matrix3 with Microsoft SMTPSVC; Fri, 22 Oct 1999 02:55:05 -0700
To: <[e-mail]>
Subject: Keep in touch.
Date: Fri, 22 Oct 1999 02:55:05 -0700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Message-ID: <07b7905550916a9MATRIX3@matrix3>

Want to keep in touch with old friends from school?
The Gradfinder website is the perfect place to do just that.

On Gradfinder you can search for friends, add your
current contact info, a current photo, and details
about what you are up to these days. You can update
your info at any time after that. All changes happen
immediately. There are also message boards you can use
to help organize reunions. You can use our photo album
wizard to create online albums to share with friends
and family.

There are currently over 100,000 schools listed from
grade 1 to university from 60 countries around the world.

This service is free so check it out!

This site can be found at:

http://www.gradfinder.com




Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA12123 for <[e-mail]>; Thu, 21 Oct 1999 17:41:10 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VJST65G2>; Thu, 21 Oct 1999 17:34:18 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "Luo, Feng (Exchange)" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: certificate chain
Date: Thu, 21 Oct 1999 17:34:17 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

SSL does not specify the rules for certificate chain
validation. Also remember, that an SSL handshake
can use anonymously-originated messages in either 
direction.

TLS systems have to offer the backwards compatible
with SSL v3, which means that TLS systems
must process v1 certs.


> -----Original Message-----
> From: Luo, Feng (Exchange) [mailto:[e-mail]]
> Sent: Thursday, October 21, 1999 5:29 PM
> To: '[e-mail]'
> Subject: certificate chain
> 
> 
> In the SSL handshake, what's the standard that the SSL-enabled client
> authenticates the SSL-enabled sever in the certificate chain 
> of the web
> server. It seems like that the Netscape browser and IE only 
> look at the
> server certificate sent by the web server, but the Marimba 
> tuner is looking
> at not only the server certificate but also the CA 
> certificate which issued
> that server certificate.
> Can some one tell me which method is the RFC standard? Where 
> can I have the
> documentation on this?
> 
> Thanks
> Feng
> 
> 
> **************************************************************
> *********
> Bear Stearns is not responsible for any recommendation, solicitation, 
> offer or agreement or any information about any transaction, customer 
> account or account activity contained in this communication.
> **************************************************************
> *********
> 


Received: from bearhub.bear.com (bearhub.bear.com [207.159.107.85]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA11762 for <[e-mail]>; Thu, 21 Oct 1999 17:25:06 -0700 (PDT)
Received: from bear.com (localhost [127.0.0.1]) by bearhub.bear.com (8.9.3/8.9.2) with SMTP id UAA16776 for <[e-mail]>; Thu, 21 Oct 1999 20:27:17 -0400 (EDT)
Received: by whmsx2.bear.com with Internet Mail Service (5.5.2650.10) id <V2LHV7P3>; Thu, 21 Oct 1999 20:28:43 -0400
Message-ID: <[e-mail]>
From: "Luo, Feng (Exchange)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: certificate chain
Date: Thu, 21 Oct 1999 20:28:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain

In the SSL handshake, what's the standard that the SSL-enabled client
authenticates the SSL-enabled sever in the certificate chain of the web
server. It seems like that the Netscape browser and IE only look at the
server certificate sent by the web server, but the Marimba tuner is looking
at not only the server certificate but also the CA certificate which issued
that server certificate.
Can some one tell me which method is the RFC standard? Where can I have the
documentation on this?

Thanks
Feng


***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***********************************************************************



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA29396 for <[e-mail]>; Thu, 21 Oct 1999 03:50:20 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13995; Thu, 21 Oct 1999 06:52:58 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-04.txt
Date: Thu, 21 Oct 1999 06:52:57 -0400
Sender: [e-mail]

--NextPart

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

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from smtp01.netservers.net (smtp01.netservers.net [209.196.128.109]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA18880 for <[e-mail]>; Wed, 20 Oct 1999 15:40:28 -0700 (PDT)
Received: from oemcomputer (1Cust14.tnt1.sfo1.da.uu.net [63.17.183.14]) by smtp01.netservers.net (8.8.8/8.8.8) with SMTP id PAA24078; Wed, 20 Oct 1999 15:42:05 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <003b01bf1b4c$6048a020$98affea9@oemcomputer>
From: "Toni Price" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Fw: PKI Opportunities
Date: Wed, 20 Oct 1999 15:42:17 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01BF1B11.B046FEE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01BF1B11.B046FEE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



IETF Member:

My name is Toni Price and I have been retained to do a search for two =
"PKI" professionals with a leading provider of encryption-based network =
security solutions in Silicon Valley.  I am looking for a PKI Standards =
Engineer and a PKI Systems Engineer.  If you know of anyone looking for =
this kind of opportunity I would appreciate a referral. =20

Please give them my telephone number and e-mail information.

Thank you,

Toni Price
Price-Serrano People Services, Inc.
510-436-0858/office
510-436-0859/fax
[e-mail]

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>IETF Member:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>My name is Toni Price and I have been =
retained to=20
do a search for two "PKI" professionals&nbsp;with a leading provider of=20
encryption-based network security solutions in Silicon Valley.&nbsp; I =
am=20
looking for a PKI Standards Engineer and a PKI Systems Engineer.&nbsp; =
If you=20
know of anyone looking for this kind of opportunity I would appreciate a =

referral.&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Please give them my telephone number =
and e-mail=20
information.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial><FONT face=3D"Lucida =
Handwriting">Toni=20
Price<BR></FONT>Price-Serrano People Services,=20
Inc.<BR>510-436-0858/office<BR>510-436-0859/fax<BR><A=20
href=3D"mailto:[e-mail]">[e-mail]</A></FONT><=
/FONT></DIV></BODY></HTML>

------=_NextPart_000_0036_01BF1B11.B046FEE0--



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA14787 for <[e-mail]>; Wed, 20 Oct 1999 10:45:54 -0700 (PDT)
Received: from rsalaptop (RSA-LAPTOP [192.168.3.229]) by seine.valicert.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VH9JSSKC; Wed, 20 Oct 1999 10:39:00 -0700
From: "Peter Williams" <[e-mail]>
To: <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Wed, 20 Oct 1999 10:51:19 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>

 
> 
> OTOH, I do see a use for such a service for
> Denis' purpose, which, I guess, is to figure out 
> whether a certificate was valid at some time
> in the past as part of evaluating the evidence
> for NR purposes. That's not what I read SCVP or
> OCSP-X as trying to address though.
> 
> Stephen. 
 

I believe OCSP-X is trying, amongst other things, to address the 
functions laid out in Section 8.1 of the VeriSign CPS, and 
similar requirements set out in more modern security
practice designs.
https://www.verisign.com/repository/CPS1.2/CPSCH8.HTM

The idea of authorization in VeriSign CPS 8.1 contrasts 
with technical authorization:

As Phill said, there is an "integrated" element of authorization,
but not the sense of X.509 AC's authorization
model, I suggest. The VeriSign CPS was designed to control the
behaviour of humans by tying them to intent so they
can be criminally prosecuted by govts or held in breach,
or liable for a tort, etc. ACs were designed
to instrument technical security systems, not
faciliate a legal protocol, per se.

In conclusion:

(1) I believe OCSP-X may co-locate "AC-type authorization
and access control" with signature verification functions. 
I disagree with Phill's apparent assertion that it is natural
for the VA deploymen to inherently colocate technical authentication 
and access  control decision making, and/or enforcement. 

(2) I also believe It IS appropriate in TTP-grade VAs (like VeriSign
and ValiCert) for there to be integrated, "natural" legal
authorization processing during signature verification,
as controlled by a C/VPS legal protocol.  OCSP-X seems to 
intend to enable this function to be partially performed 
by an entity distinct from the relying-party. The practice
statement of the VA responder (ValiCert's, AT&T's...)
then control the precise legal semantics, once the
OCSP-X packets have performed the raw signalling
and communication.


Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA12631 for <[e-mail]>; Tue, 19 Oct 1999 17:27:40 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id RAA28668 for <[e-mail]>; Tue, 19 Oct 1999 17:28:13 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 19 Oct 1999 17:38:11 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: New draft - NULL Public Key Signatures
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Actually, I think defining a NULL signature algorithm would be pretty useful.

One thing I was looking for in the draft was a defintion of the ASN.1 SIGNED
macro with a NPKA signature, e.g. that the signatureValue shall consist of a
0-length BIT STRING.  I guess this might show up in section 2.5...

Also, in the interest of interoperability I think only one OID should be
defined. (One of the good properties to put in section 6 is that NPKA
produces the same signature results regardless of what hash algorithm is
used.)


Other comments:

2.1.1 - Shouldn't

   S{C, V} => C
   G{E, B} => E

be

   S{C, V} => E
   G{E, B} => C

?  Similarly for 2.1.2...


2.2 - RC5 is a symmetric cipher.  Better to use RSA to avoid confusion.

6 - Another good property: Useful for protocols that were so short-sighted as
to require a signature in the ASN.1 without any regard to other possible
authentication methods.  The NPKA can be used to avoid redundant
authentication.

		Marc


Ambarish Malpani wrote:
> 
> Hi Guys,
>     Given the traffic on this list, it sounds like this IETF is
> going to be a pretty boring one. :-)
> 
> I have just submitted an individual draft about NULL Public Key
> Signatures, which I hope will be part of this working group soon
> (make things at the PKIX meeting more interesting).
> 
> The main (serious) reason for this draft, is to allow people to
> describe data items that may be signed or unsigned more easily
> in ASN.1.
> 
> Also, having a NULL algorithm is asthetically pleasing.
> 
> So here it is.
> 
> Please send all your flames/comments to this list.
> 
> Thanks,
> Ambarish
>


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA11116 for <[e-mail]>; Tue, 19 Oct 1999 16:22:59 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VFR0WJP9>; Tue, 19 Oct 1999 16:16:04 -0700
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: [e-mail]
Subject: New draft - NULL Public Key Signatures
Date: Tue, 19 Oct 1999 16:16:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF1A87.EA04BF30"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF1A87.EA04BF30
Content-Type: text/plain;
	charset="iso-8859-1"


Hi Guys,
    Given the traffic on this list, it sounds like this IETF is
going to be a pretty boring one. :-)

I have just submitted an individual draft about NULL Public Key
Signatures, which I hope will be part of this working group soon
(make things at the PKIX meeting more interesting).

The main (serious) reason for this draft, is to allow people to
describe data items that may be signed or unsigned more easily
in ASN.1.

Also, having a NULL algorithm is asthetically pleasing.

So here it is.

Please send all your flames/comments to this list.

Thanks,
Ambarish

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


------_=_NextPart_000_01BF1A87.EA04BF30
Content-Type: text/plain;
	name="nullSignatures-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="nullSignatures-00.txt"


Network Working Group                             A. Malpani (ValiCert)
Category: Internet-Draft                                   October 1999
Expires in six months


		 The NULL Public Key Algorithm (NPKA)
		     <draft-malpani-npka-00.txt>

Status of this Memo


   This document is an Internet-Draft.  Internet Drafts are working =
doc-
   uments of the Internet Engineering Task Force (IETF), its Areas, and
   its Working Groups.  Note that other groups may also distribute =
work-
   ing documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other =
documents
   at any time.  It is not appropriate to use Internet Drafts as refer-
   ence material, or to cite them other than as a ``working draft'' or
   ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the internet-drafts =
Shadow
   Directories on:

      ftp.is.co.za (Africa)
      nic.nordu.net (Europe)
      ds.internic.net (US East Coast)
      ftp.isi.edu (US West Coast)
      munnari.oz.au (Pacific Rim)

   Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This memo defines the NULL public key algorithm. The original goal
   of this effort was to be able to allow people to optionally sign
   data, without needing the make the signature optional in the ASN.1.
   While we were at it, we decided to, for completeness, also specify
   the method for NULL public key encryption.

1.  Introduction

   This memo defines the NULL public key algorithm. It explains how =
NPKA
   NULL algorithm should be used both for digital signatures and
   encryption/key exchange.

   Despite the fact that we are not lawyers, we are relatively =
confident
   that it is quite safe to use this algorithm for export for any key
   length size. It is also quite impossible for people to discover your
   private key via timing, power analysis or other cryptographic
   methods, as long as you are only using this algorithm.

2. Algorithm Details

2.1 Algorithm Definition

   In this section, we will show how NPKA can be used for both digital
   signatures and key exchange. We use the following notation:

    B represents the puBlic key
    V represents the priVate key
    C is the Clear text message
    E is the Encrypted message
    S is the Signing algorithm
    G is the siGnature verification algorithm
    Y is the key/data encrYption algorithm
    D is the key/data decryption algorithm
    F{x, y} is the function F on data elements x and y

2.1.1 Digital Signatures

   This section shows how a private key is used to create a digital
   signature and a public key used to verify the digital signature.

   For signatures, the holder of the private key uses the message and
   the private key to produce a digital signature, which can be =
verified
   by anyone with the holder's public key.

   S{C, V} =3D> C
   G{E, B} =3D> E

   Note: This satisfies the property required by all public key
   signature algorithms - G{S{C, V}, B} =3D> C

2.1.2 Encryption/Key Exchange

   This section shows how a public key is used to encrypt data/keys
   and a public key used to decrypt the data.

   Y{C, B} =3D> C
   D{E, V} =3D> E

   Note: This satisfies the property required by all public key
   encryption algorithms - D{Y{C, B}, V} =3D> C

2.2 Keying Material

   Like other modern ciphers, e.g., RC5 [RFC-2040], NPKA
   can make use of keys of varying lengths.  However, no
   measurable increase in security is afforded by the use of longer key
   lengths.

2.3 Padding

   NULL has a block size of 1 byte, thus padding is not necessary.

2.4. Performance

   The NULL encryption algorithm is significantly faster than other
   commonly used symmetric encryption algorithms and implementations of
   the base algorithm are available for all commonly used hardware and
   OS platforms.

2.5 Test Vectors

   [TBD]
   We should also show what a cert with an NPKA signature looks like

3. Object Identifiers

   [TBD]
   We need to create the OIDs for sha1withNPKA, md4withNPKA, ...

4. Operational Requirements

   [TBD]

5. Security Considerations

   If you do implement this algorithm, please make sure that signatures
   using that algorithm are only accepted in places where you do not =
need
   signatures. Similarly, encryption with this algorithm is only =
performed
   where you do not want encryption.

6. Algorithm properties

   In this section, we try to outline the main properties of NPKA.

   - Very, very high performance for both encryption and decryption,
   for key exchange and signing.
   - No export restrictions (for any key length).
   - No risk of exposing your private key to any potential attacks.
   - Short key sizes are as strong as keys twice as long.
   - Small algorithm footprint - excellent for smart card support or =
other
   low memory devices.
   - Support for any sized key.
   - Can easily be used in both a block or streaming mode.
   - Great synchronization properties - loss of a single bit in =
transmission
   results in only a single bit loss at the receiver (?)

7. Intellectual Property Rights

   [TBD]

8. Acknowledgments

   Spiritual and textual guidance for this document we provided by
   [RFC2410].

9.  References

   [RFC-2410]   Glenn R., and Kent, S., "The NULL Encryption Algorithm =
and
		Its Use With IPsec", RFC 2410, November 1998.

10.  Editors' Addresses

   Ambarish Malpani
   ValiCert, Inc.
   1215 Terra Bella,
   Mountain View, CA 94043

   EMail: [e-mail]
   Phone: [phone]


11.  Full Copyright Statement

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

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

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

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


------_=_NextPart_000_01BF1A87.EA04BF30--


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA09990 for <[e-mail]>; Tue, 19 Oct 1999 15:27:47 -0700 (PDT)
Received: by balinese.baltimore.ie; id XAA15606; Tue, 19 Oct 1999 23:30:17 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma015595; Tue, 19 Oct 99 23:29:36 +0100
Received: from baltimore.ie ([192.168.20.110]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id XAA25760; Tue, 19 Oct 1999 23:29:27 +0100
Message-ID: <[e-mail]>
Date: Tue, 19 Oct 1999 23:33:45 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Francois Rousseau <[e-mail]>
CC: [e-mail], xme <[e-mail]>, RussHousley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-ac509prof-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Francois,

> The syntax of the issuer field in version 2 ACs was modified in the X.509
> FPDAM such there would not be a need for the authorityKeyIdentifier
> extension in an AC to assist the AC verifier in checking the signature of
> the AC. By instead filling the optional baseCertificateId component of the
> issuer field, the intend was that you would achieve the same result without
> using any extensions, which is also the approach recommended in the X.509
> FPDAM. The only reason the issuerName component of the issuer field was
> left was for backward compatibility with version 1 ACs as defined in
> X.509(97).

Fair enough, we can add text to say that AKID is not needed if
baseCerificateId is used.

> In addition, I do not see the argument at paragraph 4.3.3 when you say
> using the baseCertificateId field to reference the AC issuer would mean
> that the AC verifier would be dependent on the AC issuer's public key
> infrastructure.

I guess we meant that use of baseCertificateId means that the 
AC relying party is also a relying party for whoever the AA
puts in as its PKC issuer. I can envisage some interdomain
cases where the AA is within one PKI (say certfied by CA-1)
but the AC relying party doesn't trust CA-1. If some CA the
relying party does trust (CA-2), issues another PKC for the AA,
then the relying party can use the AC is the AC has the
AA's name in the issuer field. Not sure if this'll be a 
real case, but I think its useful to allow such a split.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from dylithium.adga.ca ([206.222.76.26]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA06432 for <[e-mail]>; Tue, 19 Oct 1999 13:37:27 -0700 (PDT)
Received: from xfile (blackhole.abnet.net [209.112.11.3]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id QAA29448 for <[e-mail]>; Tue, 19 Oct 1999 16:37:55 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 19 Oct 1999 16:34:24 -0400
To: [e-mail]
From: Francois Rousseau <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-ac509prof-01.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.imc.org id NAA06433

Russ and/or Steve,

The syntax of the issuer field in version 2 ACs was modified in the X.509
FPDAM such there would not be a need for the authorityKeyIdentifier
extension in an AC to assist the AC verifier in checking the signature of
the AC. By instead filling the optional baseCertificateId component of the
issuer field, the intend was that you would achieve the same result without
using any extensions, which is also the approach recommended in the X.509
FPDAM. The only reason the issuerName component of the issuer field was
left was for backward compatibility with version 1 ACs as defined in
X.509(97).

In addition, I do not see the argument at paragraph 4.3.3 when you say
using the baseCertificateId field to reference the AC issuer would mean
that the AC verifier would be dependent on the AC issuer's public key
infrastructure.

François


Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA03202 for <[e-mail]>; Tue, 19 Oct 1999 11:05:26 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id OAA28370 for <[e-mail]>; Tue, 19 Oct 1999 14:06:17 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 19 Oct 1999 14:00:59 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: OID Typo in RFC2560?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

Forgive me if this has been caught earlier.  In clause 4.2.2.2 of RFC
2560 it says: "OCSP signing delegation SHALL be designated by the
inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
extension included in the OCSP response signer's certificate."  And
later it provides an oid reference of: id-kp-OCSPSigning OBJECT
IDENTIFIER ::= {id-kp 9}.  After that though, it refers to the
"id-ad-ocspSigning value as described above." I assume this is just a
typo and "id-ad-ocspSigning" should be replaced with
"id-kp-OCSPSigning"?  Or did I miss something?

spt



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA28909 for <[e-mail]>; Mon, 18 Oct 1999 08:34:22 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA04721; Mon, 18 Oct 1999 08:34:24 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA21109; Mon, 18 Oct 1999 08:36:15 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <SF5SPDHR>; Mon, 18 Oct 1999 08:36:16 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: ISC Meeting Notice - Nov. 8-11, Washington, DC
Date: Mon, 18 Oct 1999 08:36:14 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF197E.83B898C0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF197E.83B898C0
Content-Type: text/plain;
	charset="iso-8859-1"

FYI, attached is the meeting notice for the next American Bar Association
Information Security Committee meeting, which is scheduled for Washington DC
the same week as the IETF.  To take advantage of this co-location, the ABA
group has requested a meeting with PKIX experts to discuss various topics of
mutual interest.  Accordingly, an unofficial joint meeting has been
scheduled for the Thursday morning 11/11.  This meeting has no official
status in the IETF and anyone is welcome to attend.  We don't have a venue
yet, so any offers to host that meeting will be appreciated.  (Maybe 30-40
people(?), preferably close to the Omni Shoreham.)

Warwick


------_=_NextPart_000_01BF197E.83B898C0
Content-Type: application/msword;
	name="MeetingNotice11-99 dc v5.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="MeetingNotice11-99 dc v5.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAYwAAAAAAAAAA
EAAAZQAAAAEAAAD+////AAAAAGIAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAcQAJBAAACBK/AAAAAAAAEAAAAAAABAAAND0AAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAu2QAABZBAQAWQQEANDkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAOwDAAAAAAAA7AMAAOwD
AAAAAAAA7AMAAAAAAADsAwAAAAAAAOwDAAAAAAAA7AMAAFQAAAAAAAAAAAAAAEAEAAAAAAAAQAQA
AAAAAABABAAAAAAAAEAEAAAAAAAAQAQAADQAAAB0BAAATAAAAEAEAAAAAAAAshwAALYAAAAgBQAA
RAIAAGQHAAAAAAAAZAcAAAAAAABkBwAAAAAAAGQHAAAAAAAAZAcAAOYAAABKCAAARAAAAI4IAAAk
AAAAmxkAAAIAAACdGQAAAAAAAJ0ZAAAAAAAAnRkAADwAAADZGQAAUAEAACkbAABQAQAAeRwAACQA
AABoHQAA9AEAAFwfAADmAAAAnRwAABUAAAAAAAAAAAAAAAAAAAAAAAAA7AMAAAAAAACyCAAAAAAA
AAAAAAAAAAAAAAAAAAAAAABkBwAAAAAAAGQHAAAAAAAAsggAAAAAAACyCAAAAAAAAJ0cAAAAAAAA
mgoAAAAAAADsAwAAAAAAAOwDAAAAAAAAZAcAAAAAAAAAAAAAAAAAAGQHAAAAAAAA1AQAAEwAAACa
CgAAAAAAAJoKAAAAAAAAmgoAAAAAAACyCAAABgEAAOwDAAAAAAAAZAcAAAAAAADsAwAAAAAAAGQH
AAAAAAAAmxkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAQAAAAAAABABAAAAAAAAOwDAAAAAAAA7AMA
AAAAAADsAwAAAAAAAOwDAAAAAAAAsggAAAAAAACbGQAAAAAAAJoKAADaBQAAmgoAAAAAAAB0EAAA
GgEAALUYAADMAAAA7AMAAAAAAADsAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmxkAAAAAAABkBwAAAAAAAMAEAAAUAAAA0MqJzNIR
vwFABAAAAAAAAEAEAAAAAAAAuAkAAOIAAACBGQAAGgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09DSAgICAgQUJBIElORk9STUFUSU9OIFNFQ1VSSVRZIENPTU1JVFRFRSAt
IFBSRUxJTUlOQVJZIE1FRVRJTkcgTk9USUNFDT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0NUGxlYXNlIGNv
cnJlc3BvbmQgd2l0aDoNCyAgIE1pY2hhZWwgUy4gQmF1bSwgRXNxLgsgICAxMzUwIENoYXJsZXN0
b24gUm9hZA0gICBNb3VudGFpbiBWaWV3LCBDQSAgOTQwNDMNICAgdjogKzEgKDY1MCkgNDI5LTM0
NDQLICAgZjogKzEgKDY1MCkgNDI5LTUxMTMLICAgZTogEyBIWVBFUkxJTksgIm1haWx0bzptaWNo
YWVsQHZlcmlzaWduLmNvbSIgARRtYWlsdG86bWljaGFlbEB2ZXJpc2lnbi5jb20VDQ1EZWFyIENv
bW1pdHRlZSBhbmQgUHJvc3BlY3RpdmUgTWVtYmVyczogDVlvdSBhcmUgY29yZGlhbGx5IGludml0
ZWQgdG8gcGFydGljaXBhdGUgaW4gdGhlIEluZm9ybWF0aW9uIFNlY3VyaXR5IENvbW1pdHRlZSwg
U2VjdGlvbiBvZiBTY2llbmNlICYgVGVjaG5vbG9neSwgQW1lcmljYW4gQmFyIEFzc29jaWF0aW9u
knMgZmFsbCBtZWV0aW5nLiAgVGhlIG1lZXRpbmcgd2lsbCBiZSBoZWxkIE1vbmRheSwgTm92ZW1i
ZXIgOHRoLCAxOTk5IHRocm91Z2ggV2VkbmVzZGF5LCBOb3ZlbWJlciAxMHRoLCBpbiBXYXNoaW5n
dG9uLCBELkMuLCBhdCB0aGUgUmFkaXNzb24gQmFyY2VsbyBIb3RlbC4gaW4gV2FzaGluZ3Rvbiwg
RC5DLiAgT3VyIGhvc3QgYW5kIHByaW1hcnkgc3BvbnNvciB3aWxsIGJlIFRoZSBVLlMuIEVudmly
b25tZW50YWwgUHJvdGVjdGlvbiBBZ2VuY3kuICBUaGUgbWVldGluZyBsb2NhdGlvbiB0aW1lZnJh
bWUgd2lsbCBhbHNvIGZhY2lsaXRhdGUgYW4gaW5mb3JtYWwgam9pbnQgbWVldGluZyB3aXRoIHRo
ZSBJRVRGknMgUEtJWCBXb3JraW5nIEdyb3VwIG9uIFRodXJzZGF5IG1vcm5pbmcgTm92ZW1iZXIg
MTF0aC4NVGhlIENvbW1pdHRlZSB3aWxsIGNvbnRpbnVlIGl0cyBhZHZhbmNlbWVudCBvZiBwdWJs
aWMga2V5IGluZnJhc3RydWN0dXJlIGxlZ2FsIGFuZCBjb250cm9sIGlzc3VlcyB3aXRoaW4gdGhl
IGNvbnRleHQgb2YgaXRzIG1ham9yIHByb2plY3QsIHRoZSBQS0kgQXNzZXNzbWVudCBHdWlkZWxp
bmVzIChQQUcpLiBJbiBhZGRpdGlvbiB0byBmdXJ0aGVyIGdlbmVyYWwgZHJhZnRpbmcgYW5kIGVk
aXRpbmcgb2YgdGhlIFBBRywgdGhlIElTQyBtZWV0aW5nIHdpbGwgaW5jbHVkZSBwcmVzZW50YXRp
b24gYW5kIGRpc2N1c3Npb24gb2YgZm91ciBlLWNvbW1lcmNlIHNjZW5hcmlvcyBhZ2FpbnN0IHdo
aWNoIHRoZSBkcmFmdCBQQUcgd2lsbCBiZSBhcHBsaWVkIGFuZCBldmFsdWF0ZWQuIEFsc28sIHdl
IHdpbGwgZ2l2ZSBmdXJ0aGVyIGF0dGVudGlvbiB0byB0aGUgQ29tbW9uIENyaXRlcmlhIGFuZCB0
aGUgZXZpZGVudGlhcnkgYmFzaXMgZm9yIHRoZSBjcmltaW5hbCBlbmZvcmNlbWVudCBvZiBQS0kt
cmVsYXRlZCBjcmltZXMgLSB0byB0aGUgZXh0ZW50IHRoYXQgc3VjaCBpc3N1ZXMgaW1wbGljYXRl
IHRoZSBQQUcuDUNvbnNpc3RlbnQgd2l0aCBTZWN0aW9uIHBvbGljeSwgSVNDIG1lZXRpbmcgcGFy
dGljaXBhbnRzIG11c3QgYmUgbWVtYmVycyBvZiBib3RoIHRoZSBBQkEgYW5kIHRoZSBBQkEgU2Vj
dGlvbiBvZiBTY2llbmNlIGFuZCBUZWNobm9sb2d5LiBGb3IgbWVtYmVyc2hpcCBpbmZvcm1hdGlv
biwgcGxlYXNlIGNvbnRhY3QgQW5uIEtvd2Fsc2t5LCBNYW5hZ2VyIGZvciB0aGUgU2VjdGlvbiBv
ZiBTY2llbmNlICYgVGVjaG5vbG9neSwgYXQgQUJBIGhlYWRxdWFydGVycyBpbiBDaGljYWdvIGJ5
IHBob25lOiArMSAoMzEyKSA5ODggNTU5OSwgZmF4OiArMSAoMzEyKSA5ODggNTYyOCwgb3IgZW1h
aWw6IDwTIEhZUEVSTElOSyAibWFpbHRvOnNjaWVuY2V0ZWNoQGFiYW5ldC5vcmciIAEUc2NpZW5j
ZXRlY2hAYWJhbmV0Lm9yZxU+LiAgQXNzb2NpYXRlIG1lbWJlcnNoaXAgaW4gYm90aCB0aGUgQUJB
IGFuZCB0aGUgU2VjdGlvbiBvZiBTY2llbmNlIGFuZCBUZWNobm9sb2d5IGlzIGF2YWlsYWJsZSBm
b3Igbm9uLWxhd3llcnMgYXQgYSBjb3N0IG9mICQxMjUgVS5TLiBwZXIgeWVhci4gIFlvdSBjYW4g
YWxzbyBvYnRhaW4gbWVtYmVyc2hpcCBmb3JtcyBhdCB0aGUgbWVldGluZy4NSSBsb29rIGZvcndh
cmQgdG8gc2VlaW5nIHlvdSBpbiBXYXNoaW5ndG9uLCBELkMuDVNpbmNlcmVseSwgDQ1NaWNoYWVs
IFMuIEJhdW0gC0NoYWlyLCBJbmZvcm1hdGlvbiBTZWN1cml0eSBDb21taXR0ZWULU2VjdGlvbiBv
ZiBTY2llbmNlICYgVGVjaG5vbG9neSwgQUJBDElORk9STUFUSU9OIFNFQ1VSSVRZIENPTU1JVFRF
RQ1FbGVjdHJvbmljIENvbW1lcmNlIERpdmlzaW9uDVNlY3Rpb24gb2YgU2NpZW5jZSAmIFRlY2hu
b2xvZ3ksIEFCQQ04LTEwIE5vdmVtYmVyIDE5OTksIFdhc2hpbmd0b24sIEQuQy4NICAgICAgIFBy
b3Bvc2VkIEFnZW5kYSAoYnJlYWtzIHRha2VuIGFzIG5lZWRlZDtlc3MgY2FzdWFsOyBhbGwgdGlt
ZXMgYXJlIGxvY2FsKQ0NRGF5IE9uZSCWIDggTm92ZW1iZXIgMTk5OSCWIE1vbmRheSALoKCgoCAw
ODowMCCWIDA4OjMwIEdyZWV0aW5ncywgc2V0dXAsIGNvZmZlZSwgYW5kIGFkbWluaXN0cmF0aXZl
IG1hdHRlcnMNoKCgoCAwODozMCCWIDA5OjAwIEludHJvZHVjdGlvbnMsIG1lZXRpbmcgbG9naXN0
aWNzLCBnZW5lcmFsIGFubm91bmNlbWVudHMgDaCgoKAgMDk6MDAgliAwOTozMCBVcGRhdGVzIGZy
b20gYXJvdW5kIHRoZSBQS0kgd29ybGQ7IGFubm91bmNpbmcgdGhlIEF1c3RyYWxpYW4gUEFHIFRH
DaCgoKAgMDk6MzAgliAxMDowMCBXRyB1cGRhdGVzLCBjb29yZGluYXRpb24gb2Ygd29yayBwcm9k
dWN0IHJlc3BvbnNpYmlsaXRpZXMgZm9yIHRoaXMgbWVldGluZw2goKCgIDEwOjAwIJYgMTI6MDAg
V0cgYnJlYWtvdXRzDaCgoKAgMTI6MDAgliAxMzowMCBMdW5jaGVvbiBzcGVha2VyczogR2FyeSBT
dG9uZWJ1cm5lciwgTklTVCAtIFRvcGljOiBDb21tb24gQ3JpdGVyaWEgYW5kIFByb3RlY3Rpb24g
UHJvZmlsZSBVcGRhdGU7DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbdGJkXSwg
QklUUyBGaW5hbmNpYWwgU2VydmljZXMgU2VjdXJpdHkgTGFib3JhdG9yeSAtIFRvcGljOiBQS0kg
UHJvZHVjdCBUZXN0aW5nIJYgTGVzc29ucyBMZWFybmVkDaCgoKAgMTM6MDAgliAxNTozMCBXRyBC
cmVha291dHMNoKCgoCAxNTozMCCWIDE2OjMwIEluaXRpYWwgcHJlc2VudGF0aW9uIG9mIGEgdmVu
ZG9yLWNvbnN1bWVyIHNjZW5hcmlvIGFuZCByZXF1aXJlbWVudHMgKGZvciBhIFBBRyBhcHBlbmRp
eCkNoKCgoCAxNjozMCCWIDE3OjAwIFJlZ3JvdXAgliBjb29yZGluYXRlIGVmZm9ydHMgZm9yIGRh
eSB0d28NoKCgoCAxNzowMCCWID8/Pz8gICBEaW5uZXIgYXQgYSBsb2NhbCByZXN0YXVyYW50IFRC
RA2goKCgDURheSBUd28gliA5IE5vdmVtYmVyIDE5OTkgliBUdWVzZGF5C6CgoKAgMDg6MDAgliAw
ODozMCBTZXR1cCwgY29mZmVlLCBhZG1pbmlzdHJhdGl2ZSBtYXR0ZXJzC6CgoKAgMDg6MzAgliAw
OTowMCBNZWV0aW5nIGxvZ2lzdGljcywgZ2VuZXJhbCBhbm5vdW5jZW1lbnRzIAugoKCgIDA5OjAw
IJYgMTA6MDAgV0cgdXBkYXRlcywgZnVydGhlciBjb29yZGluYXRpb24gb2Ygd29yayBwcm9kdWN0
IHJlc3BvbnNpYmlsaXRpZXMgC6CgoKAgMTA6MDAgliAxMjowMCBXRyBicmVha291dHMLoKCgoCAx
MjowMCCWIDEzOjAwIEx1bmNoZW9uIHNwZWFrZXI6IERhdmlkIFNjaHdhcnosIFUuUy4gRVBBLCBP
ZmZpY2Ugb2YgRW52aXJvbm1lbnRhbCBJbmZvcm1hdGlvbiCWIA0gIFRvcGljOiBFdmlkZW50aWFy
eSBjaGFsbGVuZ2VzIGZvciBQS0kgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgZ292ZXJubWVudCBl
bmZvcmNlbWVudA2goKCgIDEzOjAwIJYgMTY6MTUgV0cgYnJlYWtvdXRzDaCgoKAgMTY6MTUgliAx
NjozMCBJbml0aWFsIHByZXNlbnRhdGlvbiBvZiBhIGdvdmVybm1lbnQtY2l0aXplbiBzY2VuYXJp
byBhbmQgcmVxdWlyZW1lbnRzIChmb3IgYSBQQUcgYXBwZW5kaXgpDaCgoKAgMTY6MzAgliAxNzow
MCBSZWdyb3VwIJYgY29vcmRpbmF0ZSBlZmZvcnRzIGZvciBkYXkgdGhyZWU7IG1lZXQgYXQgYSBs
b2NhbCB3YXRlcmluZyBob2xlDQ1EYXkgVGhyZWUgliAxMCBOb3ZlbWJlciAxOTk5IJYgV2VkbmVz
ZGF5C6CgoKAgMDg6MDAgliAwODozMCBTZXR1cCwgY29mZmVlLCBhZG1pbmlzdHJhdGl2ZSBtYXR0
ZXJzC6CgoKAgMDg6MzAgliAwOTowMCBNZWV0aW5nIGxvZ2lzdGljcywgZ2VuZXJhbCBhbm5vdW5j
ZW1lbnRzDaCgoKAgMDk6MDAgliAwOTozMCBDeWJlck5vdGFyeSBwYXRoIGZvcndhcmQgYW5kIGlu
aXRpYWwgcHJlc2VudGF0aW9uIG9mIG5vdGFyaWFsIHNjZW5hcmlvIGZvciB0aGUgUEFHDaCgoKAg
MDk6MzAgliAxMjowMCBXRyBicmVha291dHMgDaCgoKAgMTI6MDAgliAxOjMwIFdvcmtpbmcgbHVu
Y2g7IGluaXRpYWwgcHJlc2VudGF0aW9uIG9mIGEgcHJpdmFjeSBzY2VuYXJpbyBhbmQgcmVxdWly
ZW1lbnRzIChmb3IgYSBQQUcgYXBwZW5kaXgpOw0JCSAgSW5pdGlhbCBwcmVzZW50YXRpb24gb2Yg
YSBidXNpbmVzcy10by1idXNpbmVzcyBub25yZXB1ZGlhdGlvbiBzY2VuYXJpbyBhbmQgcmVxcy4g
KGZvciBhIFBBRyBhcHBlbmRpeCkNoKCgoCAxMzozMCCWIDE1OjAwIEZpbmFsIGJyZWFrb3V0cw2g
oKCgIDE1OjAwIJYgMTY6MDAgV0cgcmVwb3J0cywgcGF0aCBmb3J3YXJkLCBjbG9zZQ2goKCgIDE2
OjAwIJYgMTc6MDAgQ29vcmRpbmF0aW9uIGZvciB0aGUgSm9pbnQgSVNDL1BLSVgsIG1lZXQgYXQg
YSBsb2NhbCB3YXRlcmluZyBob2xlDQ1EYXkgRm91ciCWIDExIE5vdmVtYmVyIDE5OTkgliBUaHVy
c2RheSwgbG9jYXRpb24gaW4gV2FzaC4sIERDIAugoKCgIDA5OjAwIJYgPz8gVEJEICBBIGpvaW50
IGluZm9ybWFsIG1lZXRpbmcgd2l0aCB0aGUgSUVURpJzIFBLSVggV29ya2luZyBHcm91cA0JCSAg
ICBBIHRlbnRhdGl2ZSBtZWV0aW5nIGFnZW5kYSB3aWxsIGJlIHNlbnQgdG8gdGhlIElTQyBsaXN0
LXNlcnZlIGFzYXAuDQ0MDElORk9STUFUSU9OIFNFQ1VSSVRZIENPTU1JVFRFRSCWIFdvcmtpbmcg
R3JvdXAgSW5mb3JtYXRpb24NRWxlY3Ryb25pYyBDb21tZXJjZSBEaXZpc2lvbg1TZWN0aW9uIG9m
IFNjaWVuY2UgJiBUZWNobm9sb2d5LCBBQkENOC0xMCBOb3ZlbWJlciAxOTk5LCBXYXNoaW5ndG9u
LCBELkMuDQ0qKkFjY3JlZGl0YXRpb24gV29ya2luZyBHcm91cCANQ29udGFjdHM6CUNoYXJsaWUg
TWVycmlsbCwgRXNxLiATIEhZUEVSTElOSyAibWFpbHRvOmNtZXJyaWxsQGNvbmNlbnRyaWMubmV0
IiABFG1haWx0bzpjbWVycmlsbEBjb25jZW50cmljLm5ldBUgDQkJUmFuZHkgU2FiZXR0LCBFc3Eu
IBMgSFlQRVJMSU5LICJtYWlsdG86cnNhYmV0dEBzcHlydXMuY29tIiABFG1haWx0bzpyc2FiZXR0
QHNweXJ1cy5jb20VIA0NVGhlIEF1Z3VzdCAxOTk5IElTQyBtZWV0aW5nIGluIE90dGF3YSB3YXMg
YSBzdWNjZXNzZnVsIHRlc3Qgb2YgdGhlIHByb2Nlc3Mgb2YgdXNpbmcgZGlzdHJpYnV0ZWQgZWRp
dGluZyB0byBhY2NlbGVyYXRlIGNvbXBsZXRpb24gb2YgdGhlIFBBRy4gIFRoZSBwYXJ0aWNpcGFu
dHMgcmV2aWV3ZWQgc2VnbWVudCA3LCBjb3ZlcmluZyBTZWN0aW9uIEcuNCBvZiB0aGUgUEFHIChD
ZXJ0aWZpY2F0ZSBMaWZlIEN5Y2xlKS4gQSBmaW5hbCBkcmFmdCBvZiB0aGF0IHNlZ21lbnQgd2ls
bCBzb29uIGJlIHBvc3RlZCBvbiB0aGUgd2Vic2l0ZS4gIEFkZGl0aW9uYWxseSwgdHdvIG90aGVy
IGRyYWZ0cyB3ZXJlIG1vdmVkIGZvcndhcmQgKFNlZ21lbnQgNiwgY292ZXJpbmcgUEFHIFNlY3Rp
b24gRy4zIChJJkEpLCBhbmQgU2VnbWVudCAxMSwgY292ZXJpbmcgUEFHIFNlY3Rpb24gRy43IChD
ZXJ0aWZpY2F0ZSBQcm9maWxlKSkuICBUaG9zZSBzZWdtZW50cywgYWxvbmcgd2l0aCBhbnkgb3Ro
ZXJzIHRoYXQgYXJlIHJlYWR5IGZvciBmaW5hbCBjb25zaWRlcmF0aW9uLCB3aWxsIGJlIHBvc3Rl
ZCB0byB0aGUgd2Vic2l0ZSBwcmlvciB0byB0aGUgTm92ZW1iZXIgbWVldGluZy4gQXMgY29tcGxl
dGlvbiBvZiBhZGRpdGlvbmFsIHNlZ21lbnRzIG9jY3VyLCB3ZSB3aWxsIGNvbmNlbnRyYXRlIG9u
IHRob3NlIHNlZ21lbnRzIHRoYXQgcmVxdWlyZSBmdXJ0aGVyIHdvcmsuIEEgbGlzdCBvZiBzZWdt
ZW50cyB0byBiZSBjb21wbGV0ZWQgd2lsbCBhbHNvIGFwcGVhciBvbiB0aGUgd2Vic2l0ZS4NDUFs
c28gaW4gT3R0YXdhLCBzZXZlcmFsIGxpdmVseSBhbmQgaW5mb3JtYXRpdmUgYnJlYWtvdXQgc2Vz
c2lvbnMgd2VyZSBoZWxkLCBpbmNsdWRpbmcgZGlzY3Vzc2lvbiBvZiB1cGRhdGVzIHRvIFJGQyAy
NTI3LCByZXN1bHRpbmcgaW4gZnVydGhlciByZWZpbmVtZW50IG9mIHNwZWNpZmljIFBBRyBzZWN0
aW9ucy4gIFRoZSBjaGFtcGlvbnMgYW5kIGFzc2lzdGFudHMgZm9yIGFsbCBzZWdtZW50cyB3aWxs
IGxlYWQgYnJlYWtvdXRzIG9uIHRoZWlyIHJlc3BlY3RpdmUgc2Vzc2lvbnMgb24gdGhlIGZpcnN0
IGRheTsgbmV3IHZlcnNpb25zIHdpbGwgYmUgbWFkZSBhdmFpbGFibGUgdG8gdGhlIHdob2xlIGdy
b3VwIGZvciByZXZpZXcgbGF0ZXIgaW4gdGhlIG1lZXRpbmcuIFRoZSBsYXRlc3QgY29tcGxldGUg
UEFHLCBEcmFmdCA5IGRhdGVkIEp1bmUgMjksIDE5OTksIGlzIGF2YWlsYWJsZSBmb3IgZG93bmxv
YWRpbmcgYXQgdGhlIFBBRyByZXBvc2l0b3J5IGF0IDwTSFlQRVJMSU5LICJodHRwOi8vZ3N1bGF3
LmdzdS5lZHUvZ3N1ZWNwL2lzY2xhd2ciARRodHRwOi8vZ3N1bGF3LmdzdS5lZHUvZ3N1ZWNwL2lz
Y2xhd2cVPi4gIFBsZWFzZSBlLW1haWwgb3VyIGdyYWNpb3VzIHZvbHVudGVlciBUb2RkIFZpbmNl
bnQgb2YgR2VvcmdpYSBTdGF0ZSBVbml2ZXJzaXR5IGF0IBMgSFlQRVJMSU5LICJtYWlsdG86d2lu
Y2hlbEBtaW5kc3ByaW5nLmNvbSIgARRtYWlsdG86d2luY2hlbEBtaW5kc3ByaW5nLmNvbRUgaWYg
eW91IGhhdmUgYW55IHByb2JsZW0gYWNjZXNzaW5nIHRoZXNlIGRvY3VtZW50cy4gIE1vcmUgc3Bl
Y2lmaWMgZWRpdGluZyBhbmQgZHJhZnRpbmcgaW5zdHJ1Y3Rpb25zIGZvciB0aGUgV2FzaGluZ3Rv
biBtZWV0aW5nIHdpbGwgYmUgZW1haWxlZC4gCwsLKiogQXVkaXQgYW5kIENvbnRyb2xzIFdvcmtp
bmcgR3JvdXANQ29udGFjdHM6CUtldmluIENvbGVtYW4sIENQQSATIEhZUEVSTElOSyAibWFpbHRv
Omtjb2xlbWFuQGtwbWcuY29tIiABFG1haWx0bzprY29sZW1hbkBrcG1nLmNvbRUNCQlCaWxsIER6
aWFkeWssIBMgSFlQRVJMSU5LICJtYWlsdG86d2R6aWFkeWtAZG9tdXMuY29tIiABFG1haWx0bzp3
ZHppYWR5a0Bkb211cy5jb20VDQkJR2VuZSBPemdhciwgQ1BBIBMgSFlQRVJMSU5LICJtYWlsdG86
Z296Z2FyQGtwbWcuY29tIiABFG1haWx0bzpnb3pnYXJAa3BtZy5jb20VIA1UaGUgQXVkaXQgYW5k
IENvbnRyb2xzIFdvcmtpbmcgR3JvdXAgd2lsbCBmb2N1cyBpdHMgZWZmb3J0cyBvbiB0aGUgZGV2
ZWxvcG1lbnQgb2YgZ3VpZGFuY2UsIGluIHRoZSBmb3JtIG9mIGEgbWF0cml4LCBmb3IgdmFyaW91
cyBsZXZlbHMgb2YgdHJ1c3Qgd2l0aGluIGEgUEtJIGluIHNldmVyYWwgc2NlbmFyaW9zIHN1Y2gg
YXMgYmFzaWMgYXV0aGVudGljYXRpb24gZm9yIHNpbXBsZSBjb25zdW1lciBwdXJjaGFzZXMgYW5k
IHNpZ25pbmcgb2YgbGVnYWwgZG9jdW1lbnRzLiAgVGhpcyBtYXRyaXggd2lsbCBwcm92aWRlIGd1
aWRhbmNlIHRvIGF1ZGl0b3JzIHdoZW4gcGVyZm9ybWluZyBhbiBhdWRpdCBhbmQgcHJvdmlkZSBp
bmRpdmlkdWFscyB3aXRoIGEgc3Ryb25nZXIgYmFzaXMgZm9yIGFueSBhc3Nlc3NtZW50IHRoZXkg
bWF5IG1ha2Ugd2l0aCByZXNwZWN0IHRvIHRoZSBQS0kuICBUaGlzIG1hdHJpeCB3aWxsIGJlIGFk
dmFuY2VkIGluIHBhcmFsbGVsIHdpdGggdGhlIJNmb3VyIHNjZW5hcmlvc5QgbWVudGlvbmVkIGFi
b3ZlLiAgV2Ugd2lsbCB3b3JrIHdpdGggdGhlIGNoYW1waW9ucyBvZiB0aGUgdmFyaW91cyBzY2Vu
YXJpb3MgdG8gYXNzdXJlIHRoYXQgYXVkaXQvY29udHJvbCByZXF1aXJlbWVudHMgYXJlIGZhY2ls
aXRhdGVkIGluIGVhY2ggc2NlbmFyaW8uDQ0qKkNlcnRpZmljYXRlIFNlcnZpY2VzIEFncmVlbWVu
dHMgV29ya2luZyBHcm91cCALQ29udGFjdHM6CVN0ZXBoZW4gV3UsIEVzcS4gEyBIWVBFUkxJTksg
Im1haWx0bzpzd3VAdmVyaXNpZ24uY29tIiABFG1haWx0bzpzd3VAdmVyaXNpZ24uY29tFSAgIA0J
CVRvbSBNZWxsaW5nLCBFc3EuIBMgSFlQRVJMSU5LICJtYWlsdG86bWVsdEBwZXJraW5zY29pZS5j
b20iIAEUbWFpbHRvOm1lbHRAcGVya2luc2NvaWUuY29tFQkNC1RoZSBDZXJ0aWZpY2F0aW9uIFNl
cnZpY2VzIEFncmVlbWVudHMgV29yayBHcm91cCBpcyB0YXNrZWQgd2l0aCB3cml0aW5nIGEgYm9v
ayBlbnRpdGxlZCCTQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBBZ3JlZW1lbnRzLJQgdGhhdCBpcyBh
biBvdXRncm93dGggb2YgdGhlIElTQydzIGFjY3JlZGl0YXRpb24gYW5kIGNlcnRpZmljYXRlIHBv
bGljaWVzIGFjdGl2aXR5LiAgVGhlIHB1cnBvc2Ugb2YgIkNlcnRpZmljYXRpb24gU2VydmljZXMg
QWdyZWVtZW50cyIgaXMgdG8gYXNzaXN0IHRoZSBhdXRob3JzIG9mIGEgY2VydGlmaWNhdGUgcG9s
aWN5IGRlZmluaXRpb24sIGNlcnRpZmljYXRpb24gcHJhY3RpY2Ugc3RhdGVtZW50LCBzdWJzY3Jp
YmVyIGFncmVlbWVudCwgcmVseWluZyBwYXJ0eSBhZ3JlZW1lbnQsIG9yIG90aGVyIGFncmVlbWVu
dCByZWxhdGluZyB0byBjZXJ0aWZpY2F0aW9uIHNlcnZpY2VzIGJ5IHByb3ZpZGluZyBtb2RlbCBm
b3JtcyBhbmQgYSBtZW51IG9mIGFsdGVybmF0aXZlIGxlZ2FsIHdvcmRpbmcgZm9yIHVzZSBpbiBw
YXJ0aWN1bGFyIGNsYXVzZXMgb2Ygc3VjaCBkb2N1bWVudHMuICBUaGUgZG9jdW1lbnQgd2lsbCBp
bmNsdWRlIGNvbW1lbnRzIGFuZCBhbm5vdGF0aW9ucyB0byB0aGUgUEFHLiAgQXQgdGhlIE90dGF3
YSBtZWV0aW5nLCB0aGUgZ3JvdXAgYXNzaXN0ZWQgdGhlIGVmZm9ydHMgb2YgdGhlIEFjY3JlZGl0
YXRpb24gV29ya2luZyBHcm91cCBpbiBpdHMgZWZmb3J0cyB0byBjb21wbGV0ZSB0aGUgUEFHLiAg
SW4gYWRkaXRpb24sIHdvcmtpbmcgZ3JvdXAgbWVtYmVycyBhdCB0aGUgT3R0YXdhIG1lZXRpbmcg
YmVnYW4gZGV2ZWxvcGluZyBhIGxpc3Qgb2YgYWdyZWVtZW50cyB0aGF0IGNvdWxkIGJlIHVzZWQg
d2l0aCBQS0lzIGFuZCBVUkxzIG9mIHNvbWUgY3VycmVudCBpbnN0YW5jZXMgb2Ygc3VjaCBhZ3Jl
ZW1lbnRzLiAgVGhlc2UgZWZmb3J0cyB3aWxsIGNvbnRpbnVlIGF0IHRoaXMgbWVldGluZy4gDQ0M
KipDb25zdW1lcnMgYW5kIFBLSSBXb3JrIEdyb3VwDUNvbnRhY3RzOiAJQmFyY2xheSBULiBCbGFp
ciATIEhZUEVSTElOSyAibWFpbHRvOmJhcmNsYXlAdXdpLmNvbSIgARRtYWlsdG86YmFyY2xheUB1
d2kuY29tFQ1EZW5sZXkgQ2hldywgRXNxLiATIEhZUEVSTElOSyAibWFpbHRvOkRlbmxleS5DaGV3
QG55LmZyYi5vcmciIAEUbWFpbHRvOkRlbmxleS5DaGV3QG55LmZyYi5vcmcVDQkJV2luY2hlbCAn
VG9kZCcgVmluY2VudCwgSUlJLCBFc3EuIBMgSFlQRVJMSU5LICJtYWlsdG86V2luY2hlbEBtaW5k
c3ByaW5nLmNvbSIgARRtYWlsdG86V2luY2hlbEBtaW5kc3ByaW5nLmNvbRUgDQ1UaGlzIFRhc2sg
R3JvdXAgd2lsbCBhc3Nlc3MgdGhlIHJlc3VsdHMgZnJvbSB0aGUgU3BlY2lhbCBXb3Jrc2hvcCBv
biBDb25zdW1lcnMgYW5kIFBLSSAoaGVsZCBpbiBDcnlzdGFsIENpdHkpIGFuZCB0aGUgY29uc3Vt
ZXIgZ3JvdXAgZGlzY3Vzc2lvbnMgaGVsZCBpbiBPdHRhd2E7IHByb3Bvc2UgcmV2aXNpb25zIGFu
ZCBuZXcgY29udGVudCBmb3IgdGhlIFBBRyBhY2NvcmRpbmdseSwgd2l0aCBhIGZvY3VzIG9uIGxl
Z2FsIHByZXN1bXB0aW9uczsgYW5kIHByb3ZpZGUgZmluYWwgZWRpdG9yaWFsIHJldmlldyB0aGUg
ZHJhZnQgTW9kZWwgUEtJIENvbnN1bWVyIERpc2Nsb3N1cmUgRG9jdW1lbnQsIGluY2x1ZGluZyBh
Z3JlZW1lbnQgY29uY2VybmluZyBpdHMgZGlzdHJpYnV0aW9uIGFuZCBndWlkZSB0byBpbXBsZW1l
bnRhdGlvbiwgYXMgd2VsbCBhcyBpdHMgdGllcyB0byB0aGUgUEFHLg0NDSoqQ3liZXJOb3Rhcnkg
V29ya2luZyBHcm91cA1Db250YWN0czoJSm9lIEFsaGFkZWZmLCBFc3EuIBMgSFlQRVJMSU5LICJt
YWlsdG86amFsaGFkZWZAdXMub3JhY2xlLmNvbSIgARRtYWlsdG86amFsaGFkZWZAdXMub3JhY2xl
LmNvbRUNQ2xhdWRlIFBlcnJlYXVsdCwgRXNxLiBtYWlsdG86E0hZUEVSTElOSyAibWFpbHRvOmNw
ZXJyZWF1bHRAVlBOdGVjaC5jb20iARRjcGVycmVhdWx0QFZQTnRlY2guY29tFQ0JCUphY2sgU2V0
aCwgRXNxLiBbdGVsLiArMSAoMzA1KSA0NDctODE1M10NDVRoZSBDeWJlck5vdGFyeSBXb3JraW5n
IEdyb3VwIHdpbGwgZGV2ZWxvcCB0ZXJtcyBvZiByZWZlcmVuY2UgYW5kIGRldGVybWluZSBob3cg
dGhlIG5vdGFyaWFsIGNvbW11bml0eSBjYW4gYmVzdCB1dGlsaXplIHRoZSBQQUcuIEF0IHRoZSBO
b3ZlbWJlciBtZWV0aW5nLCB0aGUgV0cgd2lsbCBkZXZlbG9wL3ByZXNlbnQgYSBkcmFmdCBub3Rh
cmlhbCBzY2VuYXJpbyAoYW5kIGNvcnJlc3BvbmRpbmcgcmVxdWlyZW1lbnRzKSBmb3IgaW5jbHVz
aW9uIGluIGFuIGFwcGVuZGl4IHRvIHRoZSBQQUcuDQ0NKipHbG9iYWwgVHJhZGUgYW5kIENvbXBh
cmF0aXZlIExhdyBXb3JraW5nIEdyb3VwDUNvbnRhY3RzOiAJSmFuamFhcCBCb3MsIEVzcS4gEyBI
WVBFUkxJTksgbWFpbHRvOkphbmphYXBAYm9zLm5sIAEUSmFuamFhcEBib3MubmwVIA1XaWxsaWFt
IEtlbm5haXIsIEVzcS4gEyBIWVBFUkxJTksgIm1haWx0bzprZW5uYWlyQGpvaG52ZW5uLmNvLnVr
IiABFG1haWx0bzprZW5uYWlyQGpvaG52ZW5uLmNvLnVrFSANEyBIWVBFUkxJTksgIm1haWx0bzoi
IAEUFUouIEYuIFNhdXJpb2wgEyBIWVBFUkxJTksgIm1haWx0bzpqZnNhdXJpb2xAbGFiY2FsLmNv
bSIgARRtYWlsdG86amZzYXVyaW9sQGxhYmNhbC5jb20VIA0NVGhlIEdsb2JhbCBOb3RpY2VzIGFu
ZCBDb21wYXJhdGl2ZSBMYXcgV29ya2luZyBHcm91cCB3aWxsIGFkdmFuY2Ugc3RhbmRhcmQgbm90
aWNlcywgZGlzY2xvc3VyZXMgYW5kIHdhcm5pbmdzIGZvciBjZXJ0aWZpY2F0ZXMgYW5kIGVuZC11
c2VyIFBLSS1vcmllbnRlZCBwcm9kdWN0cyBhbmQgc2VydmljZXMgYXMgYSB3YXkgb2YgZmFjaWxp
dGF0aW5nIHRyYWRlIG92ZXIgc2VjdXJlIGdsb2JhbCBpbmZyYXN0cnVjdHVyZXMuICBUaGlzIGdy
b3VwIGlzIHdvcmtpbmcgaW5mb3JtYWxseSB3aXRoIHRoZSBJbnRlcm5hdGlvbmFsIENoYW1iZXIg
b2YgQ29tbWVyY2WScyBFLVRlcm1zIFdvcmtpbmcgR3JvdXAuDQ0gDSoqS2V5IFJlY292ZXJ5IFdv
cmtpbmcgR3JvdXAgKEtSV0cpDUNvbnRhY3RzOglFbWlseSBGcnllLCBFc3EuIBMgSFlQRVJMSU5L
ICJtYWlsdG86ZW1pbHlmcnllQGlibS5uZXQiIAEUbWFpbHRvOmVtaWx5ZnJ5ZUBpYm0ubmV0FQ0J
CUR3aWdodCBPbHNvbiwgRXNxLiATIEhZUEVSTElOSyAibWFpbHRvOmRvbHNvbkBkc2llc2Nyb3cu
Y29tIiABFG1haWx0bzpkb2xzb25AZHNpZXNjcm93LmNvbRUgIA0JCVJhbmR5IFNhYmV0dCwgRXNx
LiATIEhZUEVSTElOSyAibWFpbHRvOnJzYWJldHRAc3B5cnVzLmNvbSIgARRtYWlsdG86cnNhYmV0
dEBzcHlydXMuY29tFSANDVRoZSBLZXkgUmVjb3ZlcnkgV29ya2luZyBHcm91cCBtb25pdG9ycyBr
ZXkgcmVjb3ZlcnkgaW5pdGlhdGl2ZXMsIGxlZ2lzbGF0aW9uLCBhbmQgYnVzaW5lc3MgbW9kZWxz
IGRvbWVzdGljYWxseSBhbmQgaW50ZXJuYXRpb25hbGx5LiAgV29yayBhdCB0aGUgQXVndXN0IG1l
ZXRpbmcgd2lsbCBmb2N1cyBvbiBrZXkgbWFuYWdlbWVudCBpbnRlcm9wZXJhYmlsaXR5LiAgRnVy
dGhlciBkcmFmdGluZyB0byBtZWV0IG5vdGljZSByZXF1aXJlbWVudHMgaW4ga2V5IHJlY292ZXJ5
IGltcGxlbWVudGF0aW9ucyB3aWxsIGFsc28gYmUgY29tcGxldGVkLg0NDSoqUmVjaXByb2NpdHkg
YW5kIEdvdmVybm1lbnQgVGFzayBHcm91cA1Db250YWN0czogCURhdmlkIEJpbGxldGVyLCBFc3Eu
IBMgSFlQRVJMSU5LICJtYWlsdG86YmlsbGV0ZXJAc2Vjc3RhdGUud2EuZ292IiABFGJpbGxldGVy
QG1haWxjaXR5LmNvbSAVDQkJUm9iZXJ0IFN0ZXdhcnQsIEVzcS4gEyBIWVBFUkxJTksgInJzdGV3
YXJ0QGJyLnN0YXRlLnV0LnVzIiABFHJzdGV3YXJ0QGJyLnN0YXRlLnV0LnVzFRMgSFlQRVJMSU5L
IG1haWx0bzogARQVDUpvZSBBbGhhZGVmZiwgRXNxLiATIEhZUEVSTElOSyAibWFpbHRvOmphbGhh
ZGVmQHVzLm9yYWNsZS5jb20iIAEUbWFpbHRvOmphbGhhZGVmQHVzLm9yYWNsZS5jb20VDQ1UaGUg
UmVjaXByb2NpdHkgVGFzayBHcm91cCB3aWxsIGZpbmFsaXplIGEgcmVkcmFmdCBvZiB0aGUgTW9k
ZWwgUmVjaXByb2NpdHkgQWdyZWVtZW50IEZyYW1ld29yay4gIFRoaXMgZG9jdW1lbnQgd2lsbCBw
cm92aWRlIGd1aWRlbGluZXMgZm9yIHRoZSBjcm9zcy1ib3JkZXIgcmVjb2duaXRpb24gb2YgZm9y
ZWlnbi1saWNlbnNlZCBjZXJ0aWZpY2F0aW9uIGF1dGhvcml0aWVzLiAgVGhlIGZpcnN0IGRyYWZ0
IG9mIHRoaXMgZG9jdW1lbnQgd2FzIHVzZWQgdG8gZXN0YWJsaXNoIHJlY2lwcm9jaXR5IGJldHdl
ZW4gdGhlIHN0YXRlcyBvZiBVdGFoIGFuZCBOb3J0aCBDYXJvbGluYS4gIEFkZGl0aW9uYWwgZG9j
dW1lbnRzIHdpbGwgYmUgY29uc2lkZXJlZCB0aGF0IHdpbGwgcHJvdmlkZSBwcml2YXRlIHNlY3Rv
ci1nZW5lcmF0ZWQgc29sdXRpb25zIGluIHRoZSBmb3JtIG9mIGd1aWRlbGluZXMgYW5kIGNvbnRy
YWN0IHRlcm1zIGRlc2lnbmVkIHRvIGhlbHAgY29tcGFuaWVzIG9idGFpbiBsZWdhbCByZWNvZ25p
dGlvbiBmb3IgdGhlaXIgYWN0cyBpbiBmb3JlaWduIGp1cmlzZGljdGlvbnMuDQwNSW5mb3JtYXRp
b24gU2VjdXJpdHkgQ29tbWl0dGVlIJYgV2FzaGluZ3RvbiwgREMNTUVFVElORyBERVRBSUxTDTgt
MTEgTm92ZW1iZXIgMTk5OSAgKE1vbmRheSCWIFRodXJzZGF5KQ0NSVNDIE1lZXRpbmcgTG9jYXRp
b24sIE1vbmRheS1XZWRuZXNkYXkgOC0xMCBOb3ZlbWJlcjoNDVJhZGlzc29uIEJhcmNlbG8gSG90
ZWwNMjEyMSBQIFN0cmVldCwgTi5XLg1XYXNoaW5ndG9uLCBELkMuICAyMDAzNw1QaG9uZTogICsx
ICgyMDIpIDI5My0zMTAwDXVybCAgEyBIWVBFUkxJTksgImh0dHBzOi8vd3d3LnJhZGlzc29uLmNv
bS8iIAEUaHR0cHM6Ly93d3cucmFkaXNzb24uY29tFQ0NSVNDL1BLSVggSm9pbnQgTWVldGluZyCW
IExvY2F0aW9uIFRCRCwgVGh1cnNkYXkgMTEgTm92ZW1iZXI6DVRCRAkgICAgICANDUF0dGlyZSBm
b3IgdGhlIElTQyBtZWV0aW5nOiBCdXNpbmVzcyBjYXN1YWwNDVBsZWFzZSBSU1ZQOg1QYXJ0aWNp
cGFudHMgcGxhbm5pbmcgdG8gYXR0ZW5kIHRoZSBOb3ZlbWJlciA4dGgtMTB0aCBtZWV0aW5nIHNo
b3VsZCBSU1ZQIHRvIEFubiBLb3dhbHNreSwgTWFuYWdlciBmb3IgdGhlIFNlY3Rpb24gb2YgU2Np
ZW5jZSAmIFRlY2hub2xvZ3ksIGF0IEFCQSBoZWFkcXVhcnRlcnMgaW4gQ2hpY2FnbyBieSBwaG9u
ZTogKzEgKDMxMikgOTg4LTU1OTksIGZheDogKzEgKDMxMikgOTg4LTU2MjgsIG9yIBMgSFlQRVJM
SU5LICJtYWlsdG86c2NpZW5jZXRlY2hAYWJhbmV0Lm9yZyIgARRtYWlsdG86c2NpZW5jZXRlY2hA
YWJhbmV0Lm9yZxUgDQ1JZiB5b3UgYXJlIHBhcnRpY2lwYXRpbmcgaW4gdGhlIEFjY3JlZGl0YXRp
b24gV29yayBHcm91cCdzIFBLSSBBc3Nlc3NtZW50IEd1aWRlbGluZXMgKFBBRyksIHBsZWFzZSBh
bHNvIFJTVlAgaXRzIGNvLXJhcHBvcnRldXIgQ2hhcyBNZXJyaWxsIGF0IBMgSFlQRVJMSU5LICJt
YWlsdG86Y21lcnJpbGxAY29uY2VudHJpYy5uZXQiIAEUbWFpbHRvOmNtZXJyaWxsQGNvbmNlbnRy
aWMubmV0FSBmb3IgYWR2YW5jZSBwbGFubmluZyBvZiB0aGUgZWRpdGluZyBwcm9jZXNzLg0NTWVh
bHMgYW5kIEZlZXM6IEF0IGNvc3QsIFRCRA0NRXh0cmFjdXJyaWN1bGFyIEFjdGl2aXRpZXM6ICBG
dXJ0aGVyIGFjdGl2aXRpZXMgVEJEDQ0NDFN1Z2dlc3RlZCBMb2RnaW5nOg0NUmFkaXNzb24gQmFy
Y2VsbyBIb3RlbCANMjEyMSBQIFN0cmVldCwgTi5XLg1XYXNoaW5ndG9uLCBELkMuIDIwMDM3OA1Q
aG9uZTogKzEgKDIwMikgMjkzLTMxMDANTWVldGluZyByYXRlOiAkMTY5LjAwL25pZ2h0IA11cmw6
IBMgSFlQRVJMSU5LICJodHRwczovL3d3dy5yYWRpc3Nvbi5jb20iIAEUaHR0cHM6Ly93d3cucmFk
aXNzb24uY29tFQ1PdGhlciBsb2RnaW5nOg0NRG95bGUgV2FzaGluZ3RvbiBIb3RlbA0xNTAwIE5l
dyBIYW1wc2hpcmUgQXZlbnVlDVdhc2hpbmd0b24sIEQuQy4gMjAwMzANUGhvbmU6ICArMSAoMjAy
KSA0ODMtNjAwMA11cmw6IBMgSFlQRVJMSU5LICJodHRwOi8vd3d3LmRveWxlLWhvdGVscy5pZSIg
ARRodHRwOi8vd3d3LmRveWxlLWhvdGVscy5pZRUgDQ0NDVdhc2hpbmd0b24gTW9uYXJjaCBIb3Rl
bA0yNDAxIE0gU3RyZWV0LCBOLlcuDVdhc2hpbmd0b24sIEQuQy4gMjAwMzcNUGhvbmU6ICsxICgy
MDIpIDQyOS0yNDAwDQwNU2VlIHlvdSBpbiBXYXNoaW5ndG9uLCBELkMhDT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAARAUAAHoFAAB7BQAApAUAAKUFAACmBQAAwQUAAMIF
AADtBQAAswYAALUGAADaBgAA3AYAABAHAAARBwAABwgAAAkIAAALCAAAmgsAAJsLAADGCwAAxwsA
AMgLAADeCwAA3wsAAD8NAABADQAAXg0AAMYNAADcDQAA9Q0AAAAOAAAWDgAAOQ4AAOoPAAA7EAAA
QRAAAEIQAABtEAAAbxAAAHAQAAB2EAAAnBAAAJ8RAADCEQAAHRMAAGoTAABYFAAAgBQAAAcXAABF
FwAAVhcAAFkXAADiFwAA4xcAAB4YAACHGAAApBgAAMYYAADHGAAA8xgAAPQYAAD1GAAAExkAABQZ
AAAA/fb97Pbn9v0A5QDlANwA5QD99v3S9uf2/QDQAMz9wf29ALu1u7UAuwC7AL0AuwC9AL0AvQC7
0ADQALAAqLClsAAEMEoRAAAPAgiBA2qSAQAABggBVQgBCQNqAAAAAFUIAQpXygcBAQBhQjqmAAM2
CIEGNQiBPioBABUACIFDShQAY0gBAGRocEM6pmdIAAAHNgiBQ0oUAAM1CIETAgiBA2rlAAAABggB
Q0oUAFUIAREACIFjSAEAZGhiQzqmZ0gAAANIKgEIMEoRAENKFAAAEwIIgQNqAAAAAAYIAUNKFABV
CAENA2oAAAAAQ0oUAFUIAQRDShQAQQAEAABMBAAAkQQAAN0EAADeBAAA9gQAACgFAABEBQAAwwUA
AMQFAADtBQAACwgAAEkKAACmDAAA1wwAAOMMAADkDAAAQA0AAF8NAAB8DQAAoQ0AAMYNAAD6AAAA
AAAAAAAAAAAA8wAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA7gAAAAAAAAAA
AAAAAOUAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADZ
AAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA2QAAAAAA
AAAAAAAAAM8AAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAAMoAAAAAAAAAAAAA
AADKAAAAAAAAAAAAAAAAygAAAAAAAAAAAAAAAMEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAgAAAMkATEkAQ3GBQABtAAAAAQAAAMkATEkAQAFEAAPhAAAEYRg+gADAAAPhGD6
AAMQAA+EYPoABxAAD4Rg+g3GBQABaAGACQAAMSQBD4Rg+g3GBQABaAGABQAAMSQBD4Rg+gAGBAAD
JAAxJAERhGD6BQAAMSQBEYRg+gAVAAQAAEwEAACRBAAA3QQAAN4EAAD2BAAAKAUAAEQFAADDBQAA
xAUAAO0FAAALCAAASQoAAKYMAADXDAAA4wwAAOQMAABADQAAXw0AAHwNAAChDQAAxg0AABYOAAAX
DgAAgw4AAM8OAAAmDwAAhA8AAKQPAAAZEAAAnRAAAL0QAAApEQAAZREAAJoRAACfEQAAFBMAAGsT
AACLEwAA+hMAAFcUAABYFAAA9hQAAFwVAAB9FQAA8BUAAFoWAAB9FgAAsBYAAAYXAAAHFwAAlxcA
AOEXAADiFwAA4xcAAB8YAAA8GAAAYRgAAIYYAACHGAAAphgAABYZAABxGQAAchkAAH4cAAB/HAAA
GiAAAHogAADPIAAAISEAALojAAC7IwAASyQAAKkkAACFKAAAhigAAKYoAAABKQAAYCkAANIpAADT
KQAAlSsAAJYrAACXKwAAsysAAB0sAAB/LAAAAPz59vPw7ejm5gDj5uPj49/d3d3d5gAA3d3d3QAA
3d3dAN3dAADdAN3d3d0AAN3dAN0AAN3a3d3d3d3d3d3d3d0A3d3d4+MA3d3j4wAAAN0A3d3d3QAA
AAQJAw0BAAINAQAHAhAACQINAQUCEAANAQMCEAAIAhAABgj///8ABQYk////BQZW////BQZu////
BQZv////BQa7////BQIEAAUDAFbGDQAAFg4AABcOAACDDgAAzw4AACYPAACEDwAApA8AABkQAACd
EAAAvRAAACkRAABlEQAAmhEAAJ8RAAAUEwAAaxMAAIsTAAD6EwAAVxQAAFgUAAD6AAAAAAAAAAAA
AAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA
AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAACvAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA
AAAAAAAAAAAA+AAAAAAAAAAAAAAAAAAAAAAAAABIAAAPhNACEYTQAkMkAUXGgAAAAQCMOjqGAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAEAAAUQAAMkAQ+EAAAAFFgUAAD2FAAAXBUAAH0VAADwFQAAWhYAAH0WAACwFgAABhcAAAcX
AACXFwAA4RcAAOIXAADjFwAAHxgAADwYAABhGAAAhhgAAIcYAACmGAAAFhkAAHEZAAByGQAAfhwA
AH8cAAAaIAAAeiAAAM8gAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA7AAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAyQBMSQBDcYFAAG0AAAABAAA
AyQBMSQBAwAAMSQBAAEAAAAbFBkAACsZAAAsGQAAUxkAAFQZAABVGQAAbhkAAG8ZAABpHgAAah4A
AJoeAACbHgAAnB4AAMAeAADBHgAAFh8AABcfAABCHwAAQx8AAEQfAABhHwAAYh8AAPYfAAAZIAAA
NyAAADggAABeIAAAXyAAAGAgAAB4IAAAeSAAAIogAACLIAAAsiAAALMgAAC0IAAAzSAAAM4gAADh
IAAA4iAAAAYhAAAHIQAACCEAAB4hAAAfIQAAISEAALojAAC7IwAA6iMAAAckAAAIJAAALSQAAC4k
AAAvJAAARiQAAEckAABfJAAAYCQAAIkkAACKJAAAiyQAAKYkAACnJAAAqSQAAIUoAACJKAAApigA
AMIoAADDKAAAAPoA8vrv+gD6AOf67/oA+gDf+u/6AN0A+gDV+u/6APoAzfrv+gD6AMX67/oAwr7d
APoAtvrv+gD6AK767/oArMK+APoDaAgADwIIgQNqZAgAAAYIAVUIAQ8CCIEDao8HAAAGCAFVCAEH
NQiBQ0oUAARDShQAAA8CCIEDar4GAAAGCAFVCAEPAgiBA2rhBQAABggBVQgBDwIIgQNqCAUAAAYI
AVUIAQM1CIEPAgiBA2obBAAABggBVQgBDwIIgQNqYAMAAAYIAVUIAQQwShEAAA8CCIEDaoMCAAAG
CAFVCAEJA2oAAAAAVQgBAETPIAAAISEAALojAAC7IwAASyQAAKkkAACFKAAAhigAAKYoAAABKQAA
/QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAK8AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAAowAAAAAAAAAAAAAAAKMAAAAAAAAAAAAAAACcAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAGJAEPhNACEYQw
/QALEAAOhAAAD4QAABSkAAANxgUAAZAkAEMAAEXGgAAAAgCOQjqmAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACxAADoQAAA+EAAAN
xggAAqAFkCQAAAABAAAACcMoAADnKAAA6CgAAOkoAAD/KAAAACkAABMpAAAUKQAAPykAAEApAABB
KQAAXikAAF8pAACEKQAAhSkAALApAACxKQAAsikAAM8pAADQKQAA0ykAAJUrAACWKwAAsysAALwr
AAC9KwAA0CsAANErAAD8KwAA/SsAAP4rAAAbLAAAHCwAAB0sAAA7LAAAPCwAAGUsAABmLAAAZywA
AH0sAAB+LAAA1iwAAOgsAADELQAA9y0AABUuAAAWLgAANy4AADguAAA5LgAARy4AAEguAABgLgAA
YS4AAIwuAACNLgAAji4AAKsuAACsLgAAri4AAK8uAADELgAAxS4AAMcuAADVLgAA1i4AAP8uAAAA
9/Lv8gDyAOfy7/IA8gDf8u/yAN0A2wDbAPIA0/Lv8tsA8gDL8u/yAMkA2wDyAMHy7/IA8gC58u/y
APIAsfIA8gAAAAAAAAAAAAAAAAAAAAAAAAAAAA8CCIEDavoOAAAGCAFVCAEPAgiBA2oNDgAABggB
VQgBDwIIgQNqTg0AAAYIAVUIAQM2CIEPAgiBA2qhDAAABggBVQgBDwIIgQNqtAsAAAYIAVUIAQM1
CIEDaAgADwIIgQNqxwoAAAYIAVUIAQ8CCIEDahoKAAAGCAFVCAEEMEoRAAAJA2oAAAAAVQgBDwII
gQNqSQkAAAYIAVUIAQBCASkAAGApAADSKQAA0ykAAJUrAACWKwAAlysAALMrAAAdLAAAfywAAKos
AACrLAAAtgAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAA
ALQAAAAAAAAAAAAAAACxAAAAAAAAAAAAAAAAsQAAAAAAAAAAAAAAALEAAAAAAAAAAAAAAABnAAAA
AAAAAAAAAAAAsQAAAAAAAAAAAAAAALEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABKAAAGJAEP
hNACEYTQAkMkAUXGgAAAAQCrOzqGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAABiQBAAEAAABIAAAGJAEPhNACEYTQAkXGgAAA
AQB4QzqmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAt/LAAAqiwAAKssAADFLQAAxi0AAMctAAD4LQAASi4AAK4uAAAfLwAAIC8A
AHcwAAB4MAAAejAAAJ4wAAD8MAAAXDEAALcxAAC4MQAA7jIAAO8yAADwMgAAGDMAAIAzAADvMwAA
TzQAAFA0AACDNgAAhTYAALU2AADFNgAA7TYAAO42AAAkNwAAJTcAADw3AABQNwAAaDcAAII3AADL
NwAAzDcAAAk4AAAUOAAAFTgAAEE4AABCOAAATzgAAIA5AACBOQAAjDoAAI06AACqOgAAqzoAAN86
AADgOgAA4ToAAOI6AAD1OgAA9joAAA47AAAiOwAAOjsAAFM7AABwOwAAuDsAAMc7AADIOwAA3zsA
APk7AAAQPAAAKjwAAHc8AAB4PAAAeTwAAHo8AACTPAAApzwAAL48AADXPAAA2DwAANk8AAD1PAAA
ND0AAAD+/v7+/v7+/v7+/v7+/v7+/v7+/v4AAAD+AP4A/v7+AAAAAAAA/v7+/v7+/v7+/v7+AP4A
AAD8AAAAAAAAAAAAAAAAAAAAAAAA+fbz8Ozp5uMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAABQaI////BQak////BQal////Bwam////CQMFBr////8FBtb///8FBur///8F
AggABQcCCQMAAg0BUqssAADFLQAAxi0AAMctAAD4LQAASi4AAK4uAAAfLwAAIC8AAHcwAAB4MAAA
ejAAAJ4wAAD8MAAAXDEAALcxAAC4MQAA7jIAAO8yAADwMgAAGDMAAIAzAADvMwAA/AAAAAAAAAAA
AAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD2
AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA9AAAAAAA
AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA
AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAA
AAAAAAAAAAAAAOsAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAABSQBAAUAAA3GBQABxhsAAAEAAAAFAAAPhNAC
EYTQAgMAAAYkAQAW/y4AAAAvAAABLwAAHC8AAB0vAAB6MAAAnTAAALkwAAC6MAAA4DAAAOEwAADi
MAAA+jAAAPswAAARMQAAEjEAADsxAAA8MQAAPTEAAFgxAABZMQAAcTEAAHIxAACZMQAAmjEAAJsx
AAC0MQAAtTEAALgxAADtMgAA7jIAABczAAA4MwAAOTMAAGYzAABnMwAAaDMAAH0zAAB+MwAAfzMA
AJczAACYMwAAvTMAAL4zAAC/MwAA1jMAANczAADYMwAA6zMAAOwzAADuMwAAAjQAAAM0AAAuNAAA
LzQAAPfy7/IA7QDyAOXy7/IA8gDd8u/yAPIA1fLv8gDTAO0A8gDL8sLv8gDyALry7/Kso5KsAPIA
igAADwIIgQNqkhUAAAYIAVUIASAACIECCIEDascUAAAGCAFVCAFjSAEAZGhYQzqmZ0gAAAARAAiB
Y0gBAGRoWEM6pmdIAAAaAAiBA2oAAAAAVQgBY0gBAGRoWEM6pmdIAAAADwIIgQNqIBQAAAYIAVUI
ARA+KgFCKgJXygcBAQBUQzqmAA8CCIEDaisTAAAGCAFVCAEDaAgADwIIgQNqThIAAAYIAVUIAQ8C
CIEDamkRAAAGCAFVCAEPAgiBA2qQEAAABggBVQgBAzUIgQQwShEAAAkDagAAAABVCAEPAgiBA2qr
DwAABggBVQgBADYvNAAAMDQAAE00AABONAAAhTYAAO02AADuNgAAJDcAACU3AACBNwAAhzcAAIg3
AACvNwAAsDcAALE3AADJNwAAyjcAAMw3AAAIOAAAFTgAAC84AABBOAAATjgAAH04AAB/OAAAgjgA
AIQ4AAAyOQAAMzkAAF45AABfOQAAYDkAAH05AAB+OQAAfzkAAIE5AAAQOgAAEToAAD06AAA+OgAA
PzoAAF06AABeOgAAjDoAAI06AACbOgAAqzoAAMY6AADIOgAA3joAAN86AADhOgAA4joAAPY6AAB1
OwAAdjsAAJw7AACdOwAAnjsAALY7AAC3OwAAuDsAAMY7AADHOwAAyDsAAPr3+gD1APXz7/P6AOf6
9/rz9fP1APUA5QDlAPoA3fr3+gDZ08nTwcn3ydPZ9QD1tvO286v1APoAo/r3+gD1APUAAA8CCIED
agIZAAAGCAFVCAEUAAiBNQiBY0gBAGRogEM6pmdIAAAAFAEIgQRIAQAFaIFDOqYHSAAAaAgAAA8C
CIEDahEYAAAGCAFVCAETA2oAAAAAMEoRAD4qAEIqAFUIAQowShEAPioAQioAAAcwShEAPioADwII
gQNqJBcAAAYIAVUIAQNIKgEPAgiBA2p/FgAABggBVQgBBjUIgWgIAAADaAgAAzUIgQQwShEAAAkD
agAAAABVCAEAQO8zAABPNAAAUDQAAIM2AACFNgAAtTYAAMU2AADtNgAA7jYAACQ3AAAlNwAAPDcA
ALYAAAAAAAAAAAAAAACzAAAAAAAAAAAAAAAAswAAAAAAAAAAAAAAALEAAAAAAAAAAAAAAACsAAAA
AAAAAAAAAAAArAAAAAAAAAAAAAAAAKwAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAsQAAAAAAAAAA
AAAAAGQAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAADAAAPhGgBAEQAAEMkAUXGgAAAAQB7Qzqm
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAwAAMSQBAAQAAAMkATEkAQABAAADAAAFJAEASAAAD4TQAhGE0AJDJAFFxoAAAAEAVkM6
pgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAALPDcAAFA3AABoNwAAgjcAAMs3AADMNwAACTgAABQ4AAAVOAAAQTgAAEI4AABPOAAA
gDkAAIE5AACMOgAAjToAAKo6AACrOgAA3zoAAOA6AAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA
APsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAA
AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA
AAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD2
AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAACqAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABGAAAPhGgBQyQBRcaAAAABAIFDOqYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAxJAEPhGgBAwAAMSQBAAEAAAAD
AAAPhGgBABPgOgAA4ToAAOI6AAD1OgAA9joAAA47AAAiOwAAOjsAAFM7AABwOwAAuDsAAMc7AADI
OwAA3zsAAPk7AAAQPAAAKjwAAHc8AAB4PAAAeTwAAHo8AACTPAAApzwAAL48AADXPAAA2DwAANk8
AAD1PAAAND0AAPsAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAA
AAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA
AAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA
AAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPgA
AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQgAAwAAMSQBAAMA
AA+EaAEAHMg7AAAvPAAAMDwAAFg8AABZPAAAWjwAAHQ8AAB1PAAAejwAAJM8AADXPAAA9DwAADQ9
AAAA+gDy+u/6AO0A6QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAHNQiBQ0ogAAM1CIEEMEoRAAAPAgiBA2rdGQAABggBVQgBCQNqAAAA
AFUIAQAMJAAHUAQAHFABAB+w0C8gsOA9IbDmCiKwVAYjkBYIJJBAAiWwAAAgABxQAQAfsNAvILDg
PSGwoAUisN4DI5CuBiSQhAMlsAAAIwAJMAAcUAEAH7DQLyCw4D0hsKAFIrBGBSOQVAYkkCoDJbAA
ACcACTAAHFABAB+w0C8gsOA9IbCgBSKwRgUjkFQGJJAqAyWwAAALUAIAIwAJMAAcUAEAH7DQLyCw
4D0hsKAFIrBGBSOQVAYkkCoDJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAADlAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAcAAAAbQBhAGkAbAB0AG8A
OgBtAGkAYwBoAGEAZQBsAEAAdgBlAHIAaQBzAGkAZwBuAC4AYwBvAG0AAADgyep5+brOEYyCAKoA
S6kLOAAAAG0AYQBpAGwAdABvADoAbQBpAGMAaABhAGUAbABAAHYAZQByAGkAcwBpAGcAbgAuAGMA
bwBtAAAArQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAADAAAA4Mnqefm6zhGMggCqAEup
CzwAAABtAGEAaQBsAHQAbwA6AHMAYwBpAGUAbgBjAGUAdABlAGMAaABAAGEAYgBhAG4AZQB0AC4A
bwByAGcAAADxAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAfAAAAbQBhAGkAbAB0
AG8AOgBjAG0AZQByAHIAaQBsAGwAQABjAG8AbgBjAGUAbgB0AHIAaQBjAC4AbgBlAHQAAADgyep5
+brOEYyCAKoAS6kLPgAAAG0AYQBpAGwAdABvADoAYwBtAGUAcgByAGkAbABsAEAAYwBvAG4AYwBl
AG4AdAByAGkAYwAuAG4AZQB0AAAA3QAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAA
GgAAAG0AYQBpAGwAdABvADoAcgBzAGEAYgBlAHQAdABAAHMAcAB5AHIAdQBzAC4AYwBvAG0AAADg
yep5+brOEYyCAKoAS6kLNAAAAG0AYQBpAGwAdABvADoAcgBzAGEAYgBlAHQAdABAAHMAcAB5AHIA
dQBzAC4AYwBvAG0AAAC7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAAAMAAADgyep5+brO
EYyCAKoAS6kLSgAAAGgAdAB0AHAAOgAvAC8AZwBzAHUAbABhAHcALgBnAHMAdQAuAGUAZAB1AC8A
ZwBzAHUAZQBjAHAALwBpAHMAYwBsAGEAdwBnAAAA7QAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEup
CwIAAAAXAAAAHgAAAG0AYQBpAGwAdABvADoAdwBpAG4AYwBoAGUAbABAAG0AaQBuAGQAcwBwAHIA
aQBuAGcALgBjAG8AbQAAAODJ6nn5us4RjIIAqgBLqQs8AAAAbQBhAGkAbAB0AG8AOgB3AGkAbgBj
AGgAZQBsAEAAbQBpAG4AZABzAHAAcgBpAG4AZwAuAGMAbwBtAAAA2QAAAEQAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6
zhGMggCqAEupCwIAAAAXAAAAGQAAAG0AYQBpAGwAdABvADoAawBjAG8AbABlAG0AYQBuAEAAawBw
AG0AZwAuAGMAbwBtAAAA4Mnqefm6zhGMggCqAEupCzIAAABtAGEAaQBsAHQAbwA6AGsAYwBvAGwA
ZQBtAGEAbgBAAGsAcABtAGcALgBjAG8AbQAAAN0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsC
AAAAFwAAABoAAABtAGEAaQBsAHQAbwA6AHcAZAB6AGkAYQBkAHkAawBAAGQAbwBtAHUAcwAuAGMA
bwBtAAAA4Mnqefm6zhGMggCqAEupCzQAAABtAGEAaQBsAHQAbwA6AHcAZAB6AGkAYQBkAHkAawBA
AGQAbwBtAHUAcwAuAGMAbwBtAAAA0QAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAA
FwAAAG0AYQBpAGwAdABvADoAZwBvAHoAZwBhAHIAQABrAHAAbQBnAC4AYwBvAG0AAADgyep5+brO
EYyCAKoAS6kLLgAAAG0AYQBpAGwAdABvADoAZwBvAHoAZwBhAHIAQABrAHAAbQBnAC4AYwBvAG0A
AADVAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAYAAAAbQBhAGkAbAB0AG8AOgBz
AHcAdQBAAHYAZQByAGkAcwBpAGcAbgAuAGMAbwBtAAAA4Mnqefm6zhGMggCqAEupCzAAAABtAGEA
aQBsAHQAbwA6AHMAdwB1AEAAdgBlAHIAaQBzAGkAZwBuAC4AYwBvAG0AAADlAAAARAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQ
yep5+brOEYyCAKoAS6kLAgAAABcAAAAcAAAAbQBhAGkAbAB0AG8AOgBtAGUAbAB0AEAAcABlAHIA
awBpAG4AcwBjAG8AaQBlAC4AYwBvAG0AAADgyep5+brOEYyCAKoAS6kLOAAAAG0AYQBpAGwAdABv
ADoAbQBlAGwAdABAAHAAZQByAGsAaQBuAHMAYwBvAGkAZQAuAGMAbwBtAAAA0QAAAEQAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
0Mnqefm6zhGMggCqAEupCwIAAAAXAAAAFwAAAG0AYQBpAGwAdABvADoAYgBhAHIAYwBsAGEAeQBA
AHUAdwBpAC4AYwBvAG0AAADgyep5+brOEYyCAKoAS6kLLgAAAG0AYQBpAGwAdABvADoAYgBhAHIA
YwBsAGEAeQBAAHUAdwBpAC4AYwBvAG0AAACtAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAA
AAMAAADgyep5+brOEYyCAKoAS6kLPAAAAG0AYQBpAGwAdABvADoARABlAG4AbABlAHkALgBDAGgA
ZQB3AEAAbgB5AC4AZgByAGIALgBvAHIAZwAAAO0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsC
AAAAFwAAAB4AAABtAGEAaQBsAHQAbwA6AFcAaQBuAGMAaABlAGwAQABtAGkAbgBkAHMAcAByAGkA
bgBnAC4AYwBvAG0AAADgyep5+brOEYyCAKoAS6kLPAAAAG0AYQBpAGwAdABvADoAVwBpAG4AYwBo
AGUAbABAAG0AaQBuAGQAcwBwAHIAaQBuAGcALgBjAG8AbQAAAO0AAABEAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4R
jIIAqgBLqQsCAAAAFwAAAB4AAABtAGEAaQBsAHQAbwA6AGoAYQBsAGgAYQBkAGUAZgBAAHUAcwAu
AG8AcgBhAGMAbABlAC4AYwBvAG0AAADgyep5+brOEYyCAKoAS6kLPAAAAG0AYQBpAGwAdABvADoA
agBhAGwAaABhAGQAZQBmAEAAdQBzAC4AbwByAGEAYwBsAGUALgBjAG8AbQAAAK0AAABEAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ANDJ6nn5us4RjIIAqgBLqQsCAAAAAwAAAODJ6nn5us4RjIIAqgBLqQs8AAAAbQBhAGkAbAB0AG8A
OgBjAHAAZQByAHIAZQBhAHUAbAB0AEAAVgBQAE4AdABlAGMAaAAuAGMAbwBtAAAAvwAAAEQAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAADwAAAEoAYQBuAGoAYQBhAHAAQABiAG8AcwAuAG4A
bAAAAODJ6nn5us4RjIIAqgBLqQssAAAAbQBhAGkAbAB0AG8AOgBKAGEAbgBqAGEAYQBwAEAAYgBv
AHMALgBuAGwAAADtAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAeAAAAbQBhAGkA
bAB0AG8AOgBrAGUAbgBuAGEAaQByAEAAagBvAGgAbgB2AGUAbgBuAC4AYwBvAC4AdQBrAAAA4Mnq
efm6zhGMggCqAEupCzwAAABtAGEAaQBsAHQAbwA6AGsAZQBuAG4AYQBpAHIAQABqAG8AaABuAHYA
ZQBuAG4ALgBjAG8ALgB1AGsAAACxAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAW
AAAAdABoAGkAYgBvAGQAcwB1AEAAbgBvAHQAYQByAGkAdQBzAC4AYwBvAG0AAADgyep5+brOEYyC
AKoAS6kLEAAAAG0AYQBpAGwAdABvADoAAADlAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAA
ABcAAAAcAAAAbQBhAGkAbAB0AG8AOgBqAGYAcwBhAHUAcgBpAG8AbABAAGwAYQBiAGMAYQBsAC4A
YwBvAG0AAADgyep5+brOEYyCAKoAS6kLOAAAAG0AYQBpAGwAdABvADoAagBmAHMAYQB1AHIAaQBv
AGwAQABsAGEAYgBjAGEAbAAuAGMAbwBtAAAA2QAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIA
AAAXAAAAGQAAAG0AYQBpAGwAdABvADoAZQBtAGkAbAB5AGYAcgB5AGUAQABpAGIAbQAuAG4AZQB0
AAAA4Mnqefm6zhGMggCqAEupCzIAAABtAGEAaQBsAHQAbwA6AGUAbQBpAGwAeQBmAHIAeQBlAEAA
aQBiAG0ALgBuAGUAdAAAAOUAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAABwAAABt
AGEAaQBsAHQAbwA6AGQAbwBsAHMAbwBuAEAAZABzAGkAZQBzAGMAcgBvAHcALgBjAG8AbQAAAODJ
6nn5us4RjIIAqgBLqQs4AAAAbQBhAGkAbAB0AG8AOgBkAG8AbABzAG8AbgBAAGQAcwBpAGUAcwBj
AHIAbwB3AC4AYwBvAG0AAADdAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAaAAAA
bQBhAGkAbAB0AG8AOgByAHMAYQBiAGUAdAB0AEAAcwBwAHkAcgB1AHMALgBjAG8AbQAAAODJ6nn5
us4RjIIAqgBLqQs0AAAAbQBhAGkAbAB0AG8AOgByAHMAYQBiAGUAdAB0AEAAcwBwAHkAcgB1AHMA
LgBjAG8AbQAAAPUAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAACAAAABtAGEAaQBs
AHQAbwA6AGIAaQBsAGwAZQB0AGUAcgBAAHMAZQBjAHMAdABhAHQAZQAuAHcAYQAuAGcAbwB2AAAA
4Mnqefm6zhGMggCqAEupC0AAAABtAGEAaQBsAHQAbwA6AGIAaQBsAGwAZQB0AGUAcgBAAHMAZQBj
AHMAdABhAHQAZQAuAHcAYQAuAGcAbwB2AAAApwAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIA
AAABAAAAAwMAAAAAAADAAAAAAAAARgAAGAAAAHJzdGV3YXJ0QGJyLnN0YXRlLnV0LnVzAP//rd4A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADLAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcA
AAASAAAAcgBzAHQAZQB3AGEAcgB0AEAAdQB0AGEAaAAuAGcAbwB2AAAA4Mnqefm6zhGMggCqAEup
CzIAAABtAGEAaQBsAHQAbwA6AHIAcwB0AGUAdwBhAHIAdABAAHUAdABhAGgALgBnAG8AdgAAAO0A
AABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAAB4AAABtAGEAaQBsAHQAbwA6AGoAYQBs
AGgAYQBkAGUAZgBAAHUAcwAuAG8AcgBhAGMAbABlAC4AYwBvAG0AAADgyep5+brOEYyCAKoAS6kL
PAAAAG0AYQBpAGwAdABvADoAagBhAGwAaABhAGQAZQBmAEAAdQBzAC4AbwByAGEAYwBsAGUALgBj
AG8AbQAAAKUAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAAwAAAODJ6nn5us4RjIIAqgBL
qQs0AAAAaAB0AHQAcABzADoALwAvAHcAdwB3AC4AcgBhAGQAaQBzAHMAbwBuAC4AYwBvAG0ALwAA
AO0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAAB4AAABtAGEAaQBsAHQAbwA6AHMA
YwBpAGUAbgBjAGUAdABlAGMAaABAAGEAYgBhAG4AZQB0AC4AbwByAGcAAADgyep5+brOEYyCAKoA
S6kLPAAAAG0AYQBpAGwAdABvADoAcwBjAGkAZQBuAGMAZQB0AGUAYwBoAEAAYQBiAGEAbgBlAHQA
LgBvAHIAZwAAAPEAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAAB8AAABtAGEAaQBs
AHQAbwA6AGMAbQBlAHIAcgBpAGwAbABAAGMAbwBuAGMAZQBuAHQAcgBpAGMALgBuAGUAdAAAAODJ
6nn5us4RjIIAqgBLqQs+AAAAbQBhAGkAbAB0AG8AOgBjAG0AZQByAHIAaQBsAGwAQABjAG8AbgBj
AGUAbgB0AHIAaQBjAC4AbgBlAHQAAADbAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcA
AAAZAAAAaAB0AHQAcABzADoALwAvAHcAdwB3AC4AcgBhAGQAaQBzAHMAbwBuAC4AYwBvAG0AAADg
yep5+brOEYyCAKoAS6kLNAAAAGgAdAB0AHAAcwA6AC8ALwB3AHcAdwAuAHIAYQBkAGkAcwBzAG8A
bgAuAGMAbwBtAC8AAADjAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAbAAAAaAB0
AHQAcAA6AC8ALwB3AHcAdwAuAGQAbwB5AGwAZQAtAGgAbwB0AGUAbABzAC4AaQBlAAAA4Mnqefm6
zhGMggCqAEupCzgAAABoAHQAdABwADoALwAvAHcAdwB3AC4AZABvAHkAbABlAC0AaABvAHQAZQBs
AHMALgBpAGUALwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAVAAoAAQBb
AA8AAgAAAAAAAAA0AABA8f8CADQADAAGAE4AbwByAG0AYQBsAAAABQAAADEkAAAQAF9IAQRtSAkE
c0gJBHRICQQ4AAFAAQACADgADAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAAEAABAAYkAQ+E0AJAJgBe
hNACAwA1CIEASAACQAEAAgBIAAwACQBIAGUAYQBkAGkAbgBnACAAMgAAAA0AAgAGJAETpPAAFKQ8
AAAWADUIgTYIgUNKGABPSgIAUUoCAGtI5ARCAANAAQACAEIADAAJAEgAZQBhAGQAaQBuAGcAIAAz
AAAADQADAAYkAROk8AAUpDwAABAAQ0oYAE9KAgBRSgIAa0jkBDYABEABAAIANgAMAAkASABlAGEA
ZABpAG4AZwAgADQAAAAOAAQAAyQBBiQBQCYDYSQBAwA1CIEANgAFQAEAAgA2AAwACQBIAGUAYQBk
AGkAbgBnACAANQAAAA0ABQATpPAAFKQ8AEAmBAAEAENKFgA6AAZAAQACADoADAAJAEgAZQBhAGQA
aQBuAGcAIAA2AAAADQAGABOk8AAUpDwAQCYFAAcANgiBQ0oWAABAAAdAAQACAEAADAAJAEgAZQBh
AGQAaQBuAGcAIAA3AAAAGAAHAAYkAQ+E0AIRhNACQCYGXoTQAmCE0AIDAD4qAQA0AAhAAQACADQA
DAAJAEgAZQBhAGQAaQBuAGcAIAA4AAAACwAIAAYkATEkAUAmBwADADUIgQAAADwAQUDy/6EAPAAM
ABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAA
AAAyAFBAAQDyADIADAALAEIAbwBkAHkAIABUAGUAeAB0ACAAMgAAAAoADwAPhNACXoTQAgAARAD+
TwEAAgFEAAwACgBCAGwAbwBjAGsAcQB1AG8AdABlAAAAGgAQAA6EaAEPhGgBE6RkABSkZABdhGgB
XoRoAQQAQ0oYACgAVUCiABEBKAAMAAkASAB5AHAAZQByAGwAaQBuAGsAAAAGAD4qAUIqAkAAQ0AB
ACIBQAAMABAAQgBvAGQAeQAgAFQAZQB4AHQAIABJAG4AZABlAG4AdAAAAAoAEgAPhNACXoTQAgMA
NQiBADgAVkCiADEBOAAMABEARgBvAGwAbABvAHcAZQBkAEgAeQBwAGUAcgBsAGkAbgBrAAAABgA+
KgFCKgxMAFJAAQBCAUwADAASAEIAbwBkAHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQAIAAyAAAA
FQAUAA+E0AIRhKb/MSQBXoTQAmCEpv8AAAAAAAAAQAkAAOMTAADiNgAA2DgAADQ5AAAeAABkAAAf
AP////8eACZkAAAfAP////8eAEhkAAAfAP////8eAG1kAAAfAP////8eAJZkAAAfAP////8ABAAA
FBkAAMMoAAD/LgAALzQAAMg7AAA0PQAAIQAAACYAAAAoAAAALAAAAC0AAAAxAAAAAAQAAMYNAABY
FAAAzyAAAAEpAACrLAAA7zMAADw3AADgOgAAND0AACIAAAAkAAAAJQAAACcAAAApAAAAKwAAAC4A
AAAvAAAAMAAAAAAEAAB/LAAAND0AACMAAAAqAAAA//8DAAAABwBVAG4AawBuAG8AdwBuAA8ATQBp
AGMAaABhAGUAbAAgAFMALgAgAEIAYQB1AG0ACgBXAGUAcwB0ACAARwByAG8AdQBwAHoBAAClAQAA
wQEAAJoHAADHBwAA3gcAAMYUAAD0FAAAExUAACsVAABUFQAAbhUAAGkaAACbGgAAwBoAABYbAABD
GwAAYRsAADccAABfHAAAeBwAAIocAACzHAAAzRwAAOEcAAAHHQAAHh0AAAcgAAAuIAAARiAAAF8g
AACKIAAApiAAAMIkAADoJAAA/yQAABMlAABAJQAAXiUAAIQlAACxJQAAzyUAANAnAAD9JwAAGygA
ADsoAABmKAAAfSgAABUqAAA4KgAARyoAAGAqAACNKgAAqyoAAK4qAADFKgAAxioAANUqAAAAKwAA
HCsAALksAADhLAAA+iwAABEtAAA8LQAAWC0AAHEtAACaLQAAtC0AADgvAABnLwAAfi8AAJcvAAC+
LwAA1i8AANcvAADsLwAA7S8AAAIwAAAvMAAATTAAAIczAACwMwAAyTMAADI1AABfNQAAfTUAABA2
AAA+NgAAXTYAAHU3AACdNwAAtjcAAC84AABZOAAAdDgAADQ5AAATWBQBFYQTWBT/FYQTWBT/FYAT
WBT/FYATWJT/lYQTWBT/FYQTWBT/FYATWBT/FYATWBT/FYATWBT/FYATWBT/FYQTWBT/FYQTWBT/
FYQTWBT/FYQTWBT/FYQTWBT/FYQTWBT/FYQTWBT/FYATWBT/FYwTWBT/FYATWBT/FYATWBT/FYAT
WBT/FYATWBQBFYwTWBT/FYATWBT/FYwTWBQBFYQTWBT/FYQTWBT/FYATWBT/FYATWBT/FYATWBT/
FYD//wgAAAANAF8ASABsAHQANAA2ADQAMAAyADYAMAA2ADMADQBfAEgAbAB0ADQANgA0ADAAMQAy
ADAAMwA3AA0AXwBIAGwAdAA0ADYAMwA4ADYANAA4ADkAMgANAF8ASABsAHQANAA2ADMANwA2ADgA
MQA3ADgADQBfAEgAbAB0ADQANgAzADcANgA5ADQANwA5AA0AXwBIAGwAdAA0ADYANAAwADIANgAz
ADQAMQANAF8ASABsAHQANAA2ADMAOQAxADgAMwA2ADEADQBfAEgAbAB0ADQANgA0ADAAMgAzADEA
MAAzALsBAAD2HwAASiUAAFIlAABdJQAANCgAAPIsAAA0MAAANjkAAAAAAAABAABAAgAAAAMAAAAE
AAAABQAAAAYAAAAHAAAAvAEAAPcfAABLJQAAUyUAAF4lAAB+KAAA8ywAADUwAAA2OQAAAAAAAPoC
AAACAwAAAwMAAAoDAADOAwAA1AMAAAAHAAAIBwAAPAwAAD8MAAA/EgAAQxIAAH0TAACDEwAA2xMA
AN8TAACBHAAAiBwAANYcAADbHAAAUSAAAFggAAABJQAAByUAAGIlAABpJQAAmScAAKQnAADBJwAA
yScAACQoAAAtKAAArygAALooAAC/LwAA1i8AACUzAAAtMwAALjMAADUzAAD1NQAA/zUAADY5AAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAAAAAAQAQAAFwEAAEcBAABIAQAAZwIAAGoCAAD0
CQAA9QkAADwMAAA/DAAAcA0AAHMNAADjDQAAAA4AAEYSAABJEgAAURMAAFUTAABWEwAAXBMAANsT
AADfEwAA0yUAAJQnAAA8MwAATzMAAIIzAACFMwAAYzYAAHM2AADFNgAAzzYAAHA3AABzNwAAKjgA
AC04AAA2OQAABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA
BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwD//xQAAAAKAFcAZQBzAHQAIABHAHIAbwB1AHAAVgBD
ADoAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAEEAQgBBAFwASQBTAEMAIABNAGUAZQB0AGkA
bgBnAHMAXAAxADkAOQA5ADEAMQAwADgAIABkAGMAXABNAGUAZQB0AGkAbgBnAE4AbwB0AGkAYwBl
ADEAMQAtADkAOQAgAGQAYwAgAHYANABtAHMAYgAgADEAOQA5ADkAMQAwADAAOABhAC4AZABvAGMA
DwBNAGkAYwBoAGEAZQBsACAAUwAuACAAQgBhAHUAbQA3AEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBl
AG4AdABzAFwAQQBiAGEALQBJAFMAQwBcAE0AZQBlAHQAaQBuAGcATgBvAHQAaQBjAGUAMQAxAC0A
OQA5ACAAZABjACAAdgA1AG0AcwBiAC4AZABvAGMADwBNAGkAYwBoAGEAZQBsACAAUwAuACAAQgBh
AHUAbQA3AEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAQQBiAGEALQBJAFMAQwBcAE0A
ZQBlAHQAaQBuAGcATgBvAHQAaQBjAGUAMQAxAC0AOQA5ACAAZABjACAAdgA1AG0AcwBiAC4AZABv
AGMADwBNAGkAYwBoAGEAZQBsACAAUwAuACAAQgBhAHUAbQA3AEMAOgBcAE0AeQAgAEQAbwBjAHUA
bQBlAG4AdABzAFwAQQBiAGEALQBJAFMAQwBcAE0AZQBlAHQAaQBuAGcATgBvAHQAaQBjAGUAMQAx
AC0AOQA5ACAAZABjACAAdgA1AG0AcwBiAC4AZABvAGMADwBNAGkAYwBoAGEAZQBsACAAUwAuACAA
QgBhAHUAbQA3AEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAQQBiAGEALQBJAFMAQwBc
AE0AZQBlAHQAaQBuAGcATgBvAHQAaQBjAGUAMQAxAC0AOQA5ACAAZABjACAAdgA1AG0AcwBiAC4A
ZABvAGMADwBNAGkAYwBoAGEAZQBsACAAUwAuACAAQgBhAHUAbQA3AEMAOgBcAE0AeQAgAEQAbwBj
AHUAbQBlAG4AdABzAFwAQQBiAGEALQBJAFMAQwBcAE0AZQBlAHQAaQBuAGcATgBvAHQAaQBjAGUA
MQAxAC0AOQA5ACAAZABjACAAdgA1AG0AcwBiAC4AZABvAGMADwBNAGkAYwBoAGEAZQBsACAAUwAu
ACAAQgBhAHUAbQA3AEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAQQBiAGEALQBJAFMA
QwBcAE0AZQBlAHQAaQBuAGcATgBvAHQAaQBjAGUAMQAxAC0AOQA5ACAAZABjACAAdgA1AG0AcwBi
AC4AZABvAGMADwBNAGkAYwBoAGEAZQBsACAAUwAuACAAQgBhAHUAbQA3AEMAOgBcAE0AeQAgAEQA
bwBjAHUAbQBlAG4AdABzAFwAQQBiAGEALQBJAFMAQwBcAE0AZQBlAHQAaQBuAGcATgBvAHQAaQBj
AGUAMQAxAC0AOQA5ACAAZABjACAAdgA1AG0AcwBiAC4AZABvAGMADwBNAGkAYwBoAGEAZQBsACAA
UwAuACAAQgBhAHUAbQA3AEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAQQBiAGEALQBJ
AFMAQwBcAE0AZQBlAHQAaQBuAGcATgBvAHQAaQBjAGUAMQAxAC0AOQA5ACAAZABjACAAdgA1AG0A
cwBiAC4AZABvAGMADwBNAGkAYwBoAGEAZQBsACAAUwAuACAAQgBhAHUAbQA3AEMAOgBcAE0AeQAg
AEQAbwBjAHUAbQBlAG4AdABzAFwAQQBiAGEALQBJAFMAQwBcAE0AZQBlAHQAaQBuAGcATgBvAHQA
aQBjAGUAMQAxAC0AOQA5ACAAZABjACAAdgA1AG0AcwBiAC4AZABvAGMACgAgE3wJMhM0uv8PAAAA
AAAAAAAAAAAAAAAAAAEAFkivHg8ACQT/DwAAAAAAAAAAAAAAAAAAAAABAFgf6CcyEzS6/w8AAAAA
AAAAAAAAAAAAAAAAAQCXb4E/rqaOc/8P/w//D/8P/w//D/8P/w//DwAAdXbJQdJkMCP/DwAAAAAA
AAAAAAAAAAAAAAABAGpcQUcyEzS6/w8AAAAAAAAAAAAAAAAAAAAAAQCWLDRpHGB+YP8P/w//D/8P
/w//D/8P/w//DwEA8VKlbLRbLFH/D/8P/w//D/8P/w//D/8P/w8AABgjVm4yEzS6/w8AAAAAAAAA
AAAAAAAAAAAAAQBpD0V5MhM0uv8PAAAAAAAAAAAAAAAAAAAAAAEAAQAAABdAAAAAAAAAAAAAAAAA
AABoAQAACxAAAA+E0AIRhJj+XoTQAmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAA
AAAAAAAAAAAAGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+AgAAAC4AAQAAABdAAAAAAAAAAAAA
AAAAAABoAQAACxAAAA+E0AIRhJj+XoTQAmCEmP5PSgEAUUoBAG8oAAEAt/CKAgAAAAABAAAAAAAA
AAAAAAAAAAAAAAADGAAAD4TgEBGEIO8VxgUAAeAQBl6E4BBghCDvbygAAQAAAEIBAAAAAAEDAAAA
AAAAAAAAAAAAAAAAAAMYAAAPhEgSEYQg7xXGBQABSBIGXoRIEmCEIO9vKAADAAAALQABANIEAAAA
AAEDBQAAAAAAAAAAAAAAAAAAAAMYAAAPhLATEYQg7xXGBQABsBMGXoSwE2CEIO9vKAAFAAAALQAB
AC0AAgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAADGAAAD4QYFRGEIO8VxgUAARgVBl6EGBVghCDv
bygABwAAAC0AAQAtAAIALgADAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMYAAAPhIAWEYQg7xXG
BQABgBYGXoSAFmCEIO9vKAAJAAAALQABAC0AAgAuAAMALgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAA
AAAAAAMYAAAPhOgXEYQg7xXGBQAB6BcGXoToF2CEIO9vKAALAAAALQABAC0AAgAuAAMALgAEAC4A
BQABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAADGAAAD4RQGRGEIO8VxgUAAVAZBl6EUBlghCDvbygA
DQAAAC0AAQAtAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAAMYAAAP
hLgaEYQg7xXGBQABuBoGXoS4GmCEIO9vKAAPAAAALQABAC0AAgAuAAMALgAEAC4ABQAuAAYALgAH
AAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMYAAAPhCAcEYQg7xXGBQABIBwGXoQgHGCEIO9vKAAR
AAAALQABAC0AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAABAAAAFwAAAAAAAAAAAAAAAAAAAAAA
AAALGAAAD4RoARGE4P4VxgUAAbABBl6EaAFghOD+T0oBAFFKAQBvKAABALfwAQAAABdAAAAAAAAA
AAAAAAAAAABoAQAACxAAAA+E0AIRhJj+XoTQAmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAABAABAAAA
AAAAAAAAAAAAAAAAAAADGAAAD4QIBxGEmP4VxgUAAQgHBl6ECAdghJj+bygAAgAAAC4AigIAAAAA
AQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+EOhERhMbuFcYFAAE6EQZehDoRYITG7m8oAAEAAADtAQAA
AAABAwAAAAAAAAAAAAAAAAAAAAADGAAAD4R1EhGExu4VxgUAAXUSBl6EdRJghMbubygAAwAAAC0A
AQBAHwAAAAABAwUAAAAAAAAAAAAAAAAAAAADGAAAD4SwExGExu4VxgUAAbATBl6EsBNghMbubygA
BQAAAC0AAQAtAAIAAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAAxgAAA+E6xQRhMbuFcYFAAHrFAZe
hOsUYITG7m8oAAcAAAAtAAEALQACAC4AAwABAAAAAAABAwUHCQAAAAAAAAAAAAAAAAADGAAAD4Qm
FhGExu4VxgUAASYWBl6EJhZghMbubygACQAAAC0AAQAtAAIALgADAC4ABAABAAAAAAABAwUHCQsA
AAAAAAAAAAAAAAADGAAAD4RhFxGExu4VxgUAAWEXBl6EYRdghMbubygACwAAAC0AAQAtAAIALgAD
AC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAAxgAAA+EnBgRhMbuFcYFAAGcGAZehJwY
YITG7m8oAA0AAAAtAAEALQACAC4AAwAuAAQALgAFAC4ABgABAAAAAAABAwUHCQsNDwAAAAAAAAAA
AAADGAAAD4TXGRGExu4VxgUAAdcZBl6E1xlghMbubygADwAAAC0AAQAtAAIALgADAC4ABAAuAAUA
LgAGAC4ABwABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAADGAAAD4QSGxGExu4VxgUAARIbBl6EEhtg
hMbubygAEQAAAC0AAQAtAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgAAQAAABdAAAAAAAAAAAAA
AAAAAABoAQAACxAAAA+E0AIRhJj+XoTQAmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF0AAAAAAAAAA
AAAAAAAAAGgBAAALEAAAD4TQAhGEmP5ehNACYISY/k9KAQBRSgEAbygAAQC38AoAAACWLDRpAAAA
AAAAAAAAAAAAFkivHgAAAAAAAAAAAAAAAJdvgT8AAAAAAAAAAAAAAADxUqVsAAAAAAAAAAAAAAAA
IBN8CQAAAAAAAAAAAAAAAGkPRXkAAAAAAAAAAAAAAAAYI1ZuAAAAAAAAAAAAAAAAdXbJQQAAAAAA
AAAAAAAAAGpcQUcAAAAAAAAAAAAAAABYH+gnAAAAAAAAAAAAAAAA////////////////////////
////////////////////////////////CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/0BcXENPUlBQ
UklOVFxwZXNjaQBOZTAxOgB3aW5zcG9vbABIUCBMYXNlckpldCA4MDAwIFNlcmllcyBQUwBcXENP
UlBQUklOVFxwZXNjaQAAAAAAAAAAAAAAAAAAAAEEAAScALQAE1cBAAEAAQDqCm8IZAABAA8AWAIB
AAEAAAADAAAATGV0dGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQUklW4BAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAjQATAAAAAAIEAwEAAAD/AAAAAgAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcXENPUlBQUklO
VFxwZXNjaQAAAAAAAAAAAAAAAAAAAAEEAAScALQAE1cBAAEAAQDqCm8IZAABAA8AWAIBAAEAAAAD
AAAATGV0dGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQUklW4BAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAjQATAAAAAAIEAwEAAAD/AAAAAgAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAEA3zYAAN82AAA0ZDYC
AQAYAN82AAAAAAAA3zYAAAAAAAACEAAAAAAAAAA0OQAA4AEACABAAAADAAAARxaQAQAAAgIGAwUE
BQIDBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBu
AAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAA
MyaQAQAAAgsGBAICAgICBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAEEAcgBpAGEAbAAAACIABABB
AIgQAPDQAgAAaAEAAAAAYEI6ppNDOqaFQzqmJAA9AAAARggAACsvAAABABgAAAAEAAMQZAAAAAAA
AAAAAAAAAQABAAAAAQAAAAAAAAAhAwDwEIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAH
tAC0AIAAMjAAABAAGQBkAAAAGQAAAOw5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8SAAAAAAAAAEwAPQA9AD0A
PQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9
AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0A
PQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQAAAAAAAAADAEkAUwBHAA8ATQBpAGMAaABh
AGUAbAAgAFMALgAgAEIAYQB1AG0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEA
AADghZ/y+U9oEKuRCAArJ7PZMAAAAMwBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAAD4AAAABAAA
AAQBAAAFAAAAEAEAAAYAAAAcAQAABwAAACgBAAAIAAAAPAEAAAkAAABUAQAAEgAAAGABAAAKAAAA
fAEAAAsAAACIAQAADAAAAJQBAAANAAAAoAEAAA4AAACsAQAADwAAALQBAAAQAAAAvAEAABMAAADE
AQAAAgAAAOQEAAAeAAAATQAAAD09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0AAD0AHgAAAAEAAAAAPT09HgAA
AAQAAABJU0cAHgAAAAEAAAAAU0cAHgAAAAEAAAAAU0cAHgAAAAsAAABOb3JtYWwuZG90AD0eAAAA
EAAAAE1pY2hhZWwgUy4gQmF1bQAeAAAAAwAAADM2AGgeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDgu
MAA9QAAAAACuh4UIAAAAQAAAAABmPcjQEb8BQAAAAADA/6SqEb8BQAAAAAA667zSEb8BAwAAAAEA
AAADAAAARggAAAMAAAArLwAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1Zwu
GxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmugAEAADwBAAAMAAAAAQAAAGgAAAAPAAAAcAAA
AAUAAACEAAAABgAAAIwAAAARAAAAlAAAABcAAACcAAAACwAAAKQAAAAQAAAArAAAABMAAAC0AAAA
FgAAALwAAAANAAAAxAAAAAwAAAAdAQAAAgAAAOQEAAAeAAAACQAAAFZlcmlTaWduAABjAAMAAABk
AAAAAwAAABgAAAADAAAA7DkAAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAA
AAAeEAAAAQAAAE0AAAA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09AAwQAAACAAAAHgAAAAYAAABUaXRsZQAD
AAAAAQAAAAAcDgAABAAAAAAAAAAoAAAAAQAAAFIAAAACAAAAWgAAAAMAAACyAAAAAgAAAAIAAAAK
AAAAX1BJRF9HVUlEAAMAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQEAABBAAAATgAAAHsANwA4ADgA
NgA1AEEANQAxAC0ANwBEADkARAAtADEAMQBEADMALQA4ADUAQwA4AC0AMAAwADEAMAA0AEIARgA1
ADEAQQA1ADIAfQAAAAAAQQAAAGANAADAAAAAAwAAAG4AaAADAAAAXQAAAAMAAAAAAAAAAwAAAAUA
AAAfAAAAHAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBkAG8AeQBsAGUALQBoAG8AdABlAGwAcwAu
AGkAZQAvAAAAHwAAAAEAAAAAAAAAAwAAAAsAUwADAAAAWgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAA
GgAAAGgAdAB0AHAAcwA6AC8ALwB3AHcAdwAuAHIAYQBkAGkAcwBzAG8AbgAuAGMAbwBtAC8AAAAf
AAAAAQAAAAAAAAADAAAAbgBTAAMAAABXAAAAAwAAAAAAAAADAAAABQAAAB8AAAAfAAAAbQBhAGkA
bAB0AG8AOgBjAG0AZQByAHIAaQBsAGwAQABjAG8AbgBjAGUAbgB0AHIAaQBjAC4AbgBlAHQAAAAA
AB8AAAABAAAAAAAAAAMAAABvAEcAAwAAAFQAAAADAAAAAAAAAAMAAAAFAAAAHwAAAB4AAABtAGEA
aQBsAHQAbwA6AHMAYwBpAGUAbgBjAGUAdABlAGMAaABAAGEAYgBhAG4AZQB0AC4AbwByAGcAAAAf
AAAAAQAAAAAAAAADAAAACwBTAAMAAABRAAAAAwAAAAAAAAADAAAABQAAAB8AAAAaAAAAaAB0AHQA
cABzADoALwAvAHcAdwB3AC4AcgBhAGQAaQBzAHMAbwBuAC4AYwBvAG0ALwAAAB8AAAABAAAAAAAA
AAMAAAANAHAAAwAAAE4AAAADAAAAAAAAAAMAAAAFAAAAHwAAAB4AAABtAGEAaQBsAHQAbwA6AGoA
YQBsAGgAYQBkAGUAZgBAAHUAcwAuAG8AcgBhAGMAbABlAC4AYwBvAG0AAAAfAAAAAQAAAAAAAAAD
AAAAHAAsAAMAAABLAAAAAwAAAAAAAAADAAAABQAAAB8AAAAZAAAAbQBhAGkAbAB0AG8AOgByAHMA
dABlAHcAYQByAHQAQAB1AHQAYQBoAC4AZwBvAHYAAAAAAB8AAAABAAAAAAAAAAMAAAAdAGAAAwAA
AEgAAAADAAAAAAAAAAMAAAAFAAAAHwAAABgAAAByAHMAdABlAHcAYQByAHQAQABiAHIALgBzAHQA
YQB0AGUALgB1AHQALgB1AHMAAAAfAAAAAQAAAAAAAAADAAAAcQAIAAMAAABFAAAAAwAAAAAAAAAD
AAAABQAAAB8AAAAgAAAAbQBhAGkAbAB0AG8AOgBiAGkAbABsAGUAdABlAHIAQABzAGUAYwBzAHQA
YQB0AGUALgB3AGEALgBnAG8AdgAAAB8AAAABAAAAAAAAAAMAAAB9AF4AAwAAAEIAAAADAAAAAAAA
AAMAAAAFAAAAHwAAABoAAABtAGEAaQBsAHQAbwA6AHIAcwBhAGIAZQB0AHQAQABzAHAAeQByAHUA
cwAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAwAAACAAHgADAAAAPwAAAAMAAAAAAAAAAwAAAAUAAAAf
AAAAHAAAAG0AYQBpAGwAdABvADoAZABvAGwAcwBvAG4AQABkAHMAaQBlAHMAYwByAG8AdwAuAGMA
bwBtAAAAHwAAAAEAAAAAAAAAAwAAAD0AHgADAAAAPAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGQAA
AG0AYQBpAGwAdABvADoAZQBtAGkAbAB5AGYAcgB5AGUAQABpAGIAbQAuAG4AZQB0AAAAAAAfAAAA
AQAAAAAAAAADAAAAHQAlAAMAAAA5AAAAAwAAAAAAAAADAAAABQAAAB8AAAAcAAAAbQBhAGkAbAB0
AG8AOgBqAGYAcwBhAHUAcgBpAG8AbABAAGwAYQBiAGMAYQBsAC4AYwBvAG0AAAAfAAAAAQAAAAAA
AAADAAAAcABiAAMAAAA2AAAAAwAAAAAAAAADAAAABQAAAB8AAAAIAAAAbQBhAGkAbAB0AG8AOgAA
AB8AAAABAAAAAAAAAAMAAAAvAFoAAwAAADMAAAADAAAAAAAAAAMAAAAFAAAAHwAAAB4AAABtAGEA
aQBsAHQAbwA6AGsAZQBuAG4AYQBpAHIAQABqAG8AaABuAHYAZQBuAG4ALgBjAG8ALgB1AGsAAAAf
AAAAAQAAAAAAAAADAAAAIQAIAAMAAAAwAAAAAwAAAAAAAAADAAAABQAAAB8AAAAWAAAAbQBhAGkA
bAB0AG8AOgBKAGEAbgBqAGEAYQBwAEAAYgBvAHMALgBuAGwAAAAfAAAAAQAAAAAAAAADAAAAWgB9
AAMAAAAtAAAAAwAAAAAAAAADAAAABQAAAB8AAAAeAAAAbQBhAGkAbAB0AG8AOgBjAHAAZQByAHIA
ZQBhAHUAbAB0AEAAVgBQAE4AdABlAGMAaAAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAwAAAA0AcAAD
AAAAKgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAHgAAAG0AYQBpAGwAdABvADoAagBhAGwAaABhAGQA
ZQBmAEAAdQBzAC4AbwByAGEAYwBsAGUALgBjAG8AbQAAAB8AAAABAAAAAAAAAAMAAAB1AFIAAwAA
ACcAAAADAAAAAAAAAAMAAAAFAAAAHwAAAB4AAABtAGEAaQBsAHQAbwA6AFcAaQBuAGMAaABlAGwA
QABtAGkAbgBkAHMAcAByAGkAbgBnAC4AYwBvAG0AAAAfAAAAAQAAAAAAAAADAAAAbgBSAAMAAAAk
AAAAAwAAAAAAAAADAAAABQAAAB8AAAAeAAAAbQBhAGkAbAB0AG8AOgBEAGUAbgBsAGUAeQAuAEMA
aABlAHcAQABuAHkALgBmAHIAYgAuAG8AcgBnAAAAHwAAAAEAAAAAAAAAAwAAAF8AdQADAAAAIQAA
AAMAAAAAAAAAAwAAAAUAAAAfAAAAFwAAAG0AYQBpAGwAdABvADoAYgBhAHIAYwBsAGEAeQBAAHUA
dwBpAC4AYwBvAG0AAAAAAB8AAAABAAAAAAAAAAMAAAAqAAgAAwAAAB4AAAADAAAAAAAAAAMAAAAF
AAAAHwAAABwAAABtAGEAaQBsAHQAbwA6AG0AZQBsAHQAQABwAGUAcgBrAGkAbgBzAGMAbwBpAGUA
LgBjAG8AbQAAAB8AAAABAAAAAAAAAAMAAAAVADUAAwAAABsAAAADAAAAAAAAAAMAAAAFAAAAHwAA
ABgAAABtAGEAaQBsAHQAbwA6AHMAdwB1AEAAdgBlAHIAaQBzAGkAZwBuAC4AYwBvAG0AAAAfAAAA
AQAAAAAAAAADAAAAdwBHAAMAAAAYAAAAAwAAAAAAAAADAAAABQAAAB8AAAAXAAAAbQBhAGkAbAB0
AG8AOgBnAG8AegBnAGEAcgBAAGsAcABtAGcALgBjAG8AbQAAAAAAHwAAAAEAAAAAAAAAAwAAAFEA
bAADAAAAFQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGgAAAG0AYQBpAGwAdABvADoAdwBkAHoAaQBh
AGQAeQBrAEAAZABvAG0AdQBzAC4AYwBvAG0AAAAfAAAAAQAAAAAAAAADAAAAAQA7AAMAAAASAAAA
AwAAAAAAAAADAAAABQAAAB8AAAAZAAAAbQBhAGkAbAB0AG8AOgBrAGMAbwBsAGUAbQBhAG4AQABr
AHAAbQBnAC4AYwBvAG0AAAAAAB8AAAABAAAAAAAAAAMAAAB1AFIAAwAAAA8AAAADAAAAAAAAAAMA
AAAFAAAAHwAAAB4AAABtAGEAaQBsAHQAbwA6AHcAaQBuAGMAaABlAGwAQABtAGkAbgBkAHMAcABy
AGkAbgBnAC4AYwBvAG0AAAAfAAAAAQAAAAAAAAADAAAAVQAKAAMAAAAMAAAAAwAAAAAAAAADAAAA
BQAAAB8AAAAlAAAAaAB0AHQAcAA6AC8ALwBnAHMAdQBsAGEAdwAuAGcAcwB1AC4AZQBkAHUALwBn
AHMAdQBlAGMAcAAvAGkAcwBjAGwAYQB3AGcAAAAAAB8AAAABAAAAAAAAAAMAAAB9AF4AAwAAAAkA
AAADAAAAAAAAAAMAAAAFAAAAHwAAABoAAABtAGEAaQBsAHQAbwA6AHIAcwBhAGIAZQB0AHQAQABz
AHAAeQByAHUAcwAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAwAAAG4AUwADAAAABgAAAAMAAAAAAAAA
AwAAAAUAAAAfAAAAHwAAAG0AYQBpAGwAdABvADoAYwBtAGUAcgByAGkAbABsAEAAYwBvAG4AYwBl
AG4AdAByAGkAYwAuAG4AZQB0AAAAAAAfAAAAAQAAAAAAAAADAAAAbwBHAAMAAAADAAAAAwAAAAAA
AAADAAAABQAAAB8AAAAeAAAAbQBhAGkAbAB0AG8AOgBzAGMAaQBlAG4AYwBlAHQAZQBjAGgAQABh
AGIAYQBuAGUAdAAuAG8AcgBnAAAAHwAAAAEAAAAAAAAAAwAAAAYAMAADAAAAAAAAAAMAAAAAAAAA
AwAAAAUAAAAfAAAAHAAAAG0AYQBpAGwAdABvADoAbQBpAGMAaABhAGUAbABAAHYAZQByAGkAcwBp
AGcAbgAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsA
AAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAA
ABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAA
KAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAD+////NAAAADUAAAA2
AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAP7///9CAAAAQwAAAEQA
AABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAA/v//
/1MAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAAD+////WwAAAFwAAABdAAAAXgAAAF8AAABgAAAA
YQAAAP7////9////ZAAAAP7////+/////v//////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAA
gEV/paoRvwHgJpbM0hG/AWYAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABUAFQAMQAKAAIB////////////////AAAAAAAA
AADixsgAAAAAABBqGQAAAAAAAgKQAAAAEADoIBsAMwAAAMAaAADY+b4BMQBUAGEAYgBsAGUAAAC+
AUBDP9bY+b4BAAAAAAAAAAAAAAAAAAAAACAAAAAWAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgABAAAA
//////////9EAEYARgA4AEIANwAuAHQAbQBwAAAAAAB4AAAAAAAAAKCJOL9BAAAAQiAAAM0RvwFX
AG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAACAAAAAWAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAGgACAQYAAAAFAAAA/////zIANAAuAHQAbQBwAKwRvwF4AAAAAAAAAHCEEOoCD78BIK42
5gAAAAC7ZAAAcw+/AQUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAfgAoAAIB////////////////bQBwAM4RvwF4AAAAAAAAAMCTCFTf
+b4BwJMIVN/5vgHAkwhUUgAAAAAQAADf+b4BBQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIA
eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAABEAEYARgBFADgAAgEEAAAA//////////94AAAAAAAA
AABMe3SZ8b4BkMCFQxb9vgGQtN1XxvG+AZC03VdaAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfgBEAEYARgBGADgANwAuAHQAEgACAQIAAAAH
AAAA/////zAL9jRJ+L4B4HKQQxb9vgHQifA1AAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8A
YgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAfgBXAFIAQQAwADgANgA0AC4AdwBi
AGsAvgEWAAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAADgJpbM0hG/AeAmlszSEb8B
AAAAACAAAAAYAAAAAQAAAP7/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3Jk
IERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAA==

------_=_NextPart_000_01BF197E.83B898C0--


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA24260 for <[e-mail]>; Mon, 18 Oct 1999 03:50:48 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27040; Mon, 18 Oct 1999 06:53:10 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dcs-03.txt
Date: Mon, 18 Oct 1999 06:53:09 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Data  
                          Validation and Certification Server Protocols
	Author(s)	: C. Adams, P. Sylvester,  M. Zolotarev, R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-03.txt
	Pages		: 26
	Date		: 15-Oct-99
	
This document describes a general data validation and certification
service and the protocols to be used when communicating with it.  The
Data Validation and Certification Server is a Trusted Third Party
(TTP) that can be used as one component in building reliable non-
repudiation services (see [ISONR]).
Useful Data Validation and Certification Server responsibilities in a
PKI are to validate signed documents and to assert the validity of
public key certificates at a given time.
We give examples of how to use the Data Certification Server to
extend the lifetime of a signature beyond key expiry or revocation
and to query the Data Certification Server regarding the status of a
public key certificate.
<draft>Note: The initial drafts of this protocol used the
abbreviation DCS instead of DVCS.</draft>

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from irwell.zetnet.co.uk ([e-mail] [194.247.47.48]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA23845 for <[e-mail]>; Mon, 18 Oct 1999 03:25:59 -0700 (PDT)
Received: from black (man-172.dialup.zetnet.co.uk [194.247.40.218]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA04899 for <[e-mail]>; Mon, 18 Oct 1999 11:28:20 +0100
Message-Id: <[e-mail]>
From: "Suzanne" <[e-mail]>
To: [e-mail]
Date: Mon, 18 Oct 1999 11:28:08 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: remove
Reply-to: [e-mail]
Priority: normal

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suzanne Carr
Tel: [phone]
Email: [e-mail]
Email: [e-mail]
WWW:   http://www.oubliette.zetnet.co.uk



Received: from mailhost.msc.es (mailhost.msc.es [195.53.79.2]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA18952 for <[e-mail]>; Mon, 18 Oct 1999 00:16:42 -0700 (PDT)
From: [e-mail]
Received: from mmsc00003.msc.es ([10.15.5.26]) by mailhost.msc.es (Netscape Mail Server v2.02) with ESMTP id AAA25547 for <[e-mail]>; Mon, 18 Oct 1999 09:20:51 +0200
Received: by MMSC00003 with Internet Mail Service (5.5.2448.0) id <475HYDVN>; Mon, 18 Oct 1999 09:17:46 +0200
Message-ID: <[e-mail]>
To: [e-mail]
Subject: remove
Date: Mon, 18 Oct 1999 09:17:07 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA03619 for <[e-mail]>; Fri, 15 Oct 1999 12:26:50 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id IAA31292 for <[e-mail]>; Sat, 16 Oct 1999 08:28:58 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94001573812688>; Sat, 16 Oct 1999 08:28:58 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: DisplayText for Verisign Certificate
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 16 Oct 1999 08:28:58 (NZDT)
Message-ID: <[e-mail]>

"Amit Kapoor" <[e-mail]> writes:

>While working with Bob Jueneman on some S/MIME certificate issues we ran 
>into the following with a Verisign issued certificate:
>
>The portion of ASN.1 dump showing the problem:
>
>Verisign is encoding the DisplayText as IA5 whereas according to 2459 it can 
>be one of Visible, BMP or UTF8 string.
>
>Should we add IA5String to the choice list of DisplayText or treat this as a 
>error and not support the Verisign certificates?

This was quietly changed between the final draft and the RFC, as a result of 
this some implementations expect one and some expect the other.  The 
workaround I've got in my code is:

/* All draft versions of the PKIX profile had the organization as an
   IA5String, but the final RFC changed it to a VisibleString, in order
   to kludge around this for the certs which use an IA5String (which in
   practice means only Verisign, since noone else uses seems to use policy
   qualifiers), we allow both types but put the VisibleString option
   first which means it'll get used preferentially when encoding */

The code comment explains why it appears to be a Verisign bug (but isn't), 
noone else seems to use qualifiers so you won't see it anywhere else, and 
what Verisign were doing was correct at the time they did it.  I should 
really put this in the style guide.

Peter.



Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA03198 for <[e-mail]>; Fri, 15 Oct 1999 12:05:10 -0700 (PDT)
Received: from mobile (mobile [192.168.42.7]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id MAA15742; Fri, 15 Oct 1999 12:07:19 -0700
From: "Amit Kapoor" <[e-mail]>
To: "PKIX" <[e-mail]>
Cc: <[e-mail]>
Subject: DisplayText for Verisign Certificate
Date: Fri, 15 Oct 1999 12:04:36 -0700
MIME-Version: 1.0
Message-ID: <001401bf1740$1fd7ded0$[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-Type: multipart/signed; micalg=SHA-1; boundary="----=_NextPart_000_000F_01BF1705.72CDD2B0"; protocol="application/x-pkcs7-signature"
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01BF1705.72CDD2B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


	While working with Bob Jueneman on some S/MIME
	certificate issues we ran into the following with
	a Verisign issued certificate:

	The portion of ASN.1 dump showing the problem:

     766 06   11:                   OBJECT IDENTIFIER
		:                     Verisign certificatePolicy (2 16 840 1 113733 1 7
1 1)
     779 30  142:                   SEQUENCE {
     782 30   40:                     SEQUENCE {
     784 06    8:                       OBJECT IDENTIFIER cps (1 3 6 1 5 5
7 2 1)
     794 16   28:                       IA5String
'https://www.verisign.com/CPS'
		:                       }
     824 30   98:                     SEQUENCE {
     826 06    8:                       OBJECT IDENTIFIER
		:                         unotice (1 3 6 1 5 5 7 2 2)
     836 30   86:                       SEQUENCE {
     838 30   21:                         SEQUENCE {
     840 16   14:                           IA5String 'VeriSign, Inc.'
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^
     856 30    3:                           SEQUENCE {
     858 02    1:                             INTEGER 1
		:                             }
		:                           }
     861 1A   61:                         VisibleString
		:                   'VeriSign's CPS incorp. by reference liab. ltd. ('
		:                   'c)97 VeriSign'
		:                         }
		:                       }
		:                     }


	Verisign is encoding the DisplayText as IA5 whereas according to
	2459 it can be one of Visible, BMP or UTF8 string.

	Should we add IA5String to the choice list of DisplayText or treat
	this as a error and not support the Verisign certificates?

	regards

Amit


------------------------------------------------------
Certificate Authority: http://www.smeme.com
CA root : http://www.smeme.com/faq_operational.html#16
------------------------------------------------------


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIID1DCCA9Aw
ggM7oAMCAQICFEQ41iugpRpD1VzRmFQZQnkJUk6OMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1T
TWVtZSBSb290IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwNjI4MDAzMDE3
WhcNMDQwNjI4MDAzMDE3WjBPMRMwEQYDVQQKEwpUcnVzdHBvaW50MRQwEgYDVQQDEwtBbWl0IEth
cG9vcjEiMCAGCSqGSIb3DQEJARYTYW1pdEB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAs/M5RIk9+UTqdrpG/UaFOjxTfCs7S9kCJtHroRgDS3Ss+eKt+Re+6NLnxm3S
+pszODOrglLwn19+Zbp3yeVXMsaYLy9+9Jwcm0l+wQGDk8Kh8xUA1MQssVaW9rWamtAvQY+Mje4S
HBjXayCIPyIMJ29Ypk49P1vKbuqgLB/ZQFECAwEAAaOCAcUwggHBMB0GA1UdDgQWBBRo1B8wQ8Kj
E90aF8xiyBKsdXMc3zAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB
/wQEAwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG
+EIBAQQEAwIAsDAeBgNVHREEFzAVgRNhbWl0QHRydXN0cG9pbnQuY29tME8GA1UdIARIMEYwRAYI
KwYEAZhUHgEwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5zbWVtZS5jb20vc2VydmljZWFncmVl
bWVudC5odG1sMEMGCWCGSAGG+EIBAwQ2FjRodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0cy9z
bWVtZV9jYS9jaGVja19yZXZva2VkMEAGCWCGSAGG+EIBBwQzFjFodHRwOi8vd3d3LnNtZW1lLmNv
bS9zZXJ2bGV0cy9zbWVtZV9jYS9yZW5ld19jZXJ0MDkGCWCGSAGG+EIBCAQsFipodHRwOi8vd3d3
LnNtZW1lLmNvbS9zZXJ2aWNlYWdyZWVtZW50Lmh0bWwwCwYJKoZIhvcNAQEFA4GBAFS76N1D2ogo
AEAUBV8b6/skJBuju82MnaKh9RlJ7elFikwwPGe9SEblPtbp/+QbDtAVIiwmOIE1XPEZi0cWfLTi
P8pa0BRBl5H419aoIfeoZTsZz4R7E7eGd7rsK37dyBzKbnqio2nzJNhx7FJJDkA7VajJbhk8tdkW
RL6IjymQMYIB/TCCAfkCAQEwTTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT
TWVtZTELMAkGA1UEBhMCVVMCFEQ41iugpRpD1VzRmFQZQnkJUk6OMAkGBSsOAwIaBQCgggEGMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAxNTE5MDQzNVowIwYJ
KoZIhvcNAQkEMRYEFEoe7hq0yyoZEWUp7gAtHSoHY/rfMEkGCSqGSIb3DQEJDzE8MDowCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcGBSsOAwIaMAoGCCqGSIb3DQIFMFwGCSsG
AQQBgjcQBDFPME0wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJ
BgNVBAYTAlVTAhREONYroKUaQ9Vc0ZhUGUJ5CVJOjjANBgkqhkiG9w0BAQEFAASBgCrawFMLEsU3
gEOGt7d4danW24erNwr+kaauKKfcd4+jmf+5AFLT91b7e+L+KXoOPloWMJGcN2mY+vTkQultV1/0
oHrxToWR0ZbRqctlE/IVmp1/EQmbVUOaiuqtkb/nTdvroSq7F79wOoQ+QVSl8p774QeU7Cnv8akF
xI5z0pabAAAAAAAA

------=_NextPart_000_000F_01BF1705.72CDD2B0--



Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA00361 for <[e-mail]>; Fri, 15 Oct 1999 09:12:32 -0700 (PDT)
From: [e-mail]
Received: by relay1.trustworks.com (8.8.5/1.4) id UAA28277; Fri, 15 Oct 1999 20:14:24 +0400 (MSD)
Message-Id: <[e-mail]>
Received: from tws123(212.114.5.15) by zuka via smap (V2.0) id xma028256; Fri, 15 Oct 99 20:13:38 +0400
To: [e-mail], Sean Mullan <[e-mail]>
Date: Fri, 15 Oct 1999 20:16:43 +0400
MIME-Version: 1.0
Content-type: text/enriched; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Processing CRLs without Issuing Distribution Points
Reply-to: [e-mail]
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.11)

<color><param>0100,0100,0100</param>On 15 Oct 99, at 11:21, Sean Mullan wrote:


<color><param>7F00,0000,0000</param>> 

> RFC 2459 does not require that CRLs contain an Issuing

> Distribution Point extension.

> 

> Does this mean that a CA may issue *partial* CRLs without

> including an Issuing Distribution Point Extension?


</color>How I understand, if CRL doesn't contain IDP, that means the CRL

is complete.


X.509 (08/97):

"<color><param>0100,0100,0100</param><FontFamily><param>Times New Roman</param>The particular CA responsible for each entry is as indicated by the certificate 

issuer CRL entry extension in that entry or in accordance with the defaulting

rules described in 12.6.3.2. In such a CRL, it is the responsibility of the CRL 

issuer to ensure that the CRL is complete in that it contains all revocation entries, 

consistent with <bold><smaller>onlyContainsUserCerts</bold><bigger>, <bold><smaller>onlyContainsCACerts</bold><bigger>, and <bold><smaller>onlySomeReasons</bold><bigger> 

indicators, from all CAs that identify this CRL issuer in their certificates."


<smaller>So, the content of CRL is on CRL issuer responsibility.</color><FontFamily><param>Arial CYR</param><bigger>


<color><param>7F00,0000,0000</param>> 

> If the answer is yes, it is not possible for a relying party to 

> safely determine if a certificate has not been revoked by inspecting

> a CRL without an Issuing Distribution Point extension. It cannot

> assume that a single CRL is an exhaustive list and it also cannot

> assume a sequence of CRLs when taken as one is an exhaustive list.

> Therefore a relying party cannot safely determine that the certificate in 

> question has not been revoked.

> 

> RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial 

> CRLs containing revoked CA certs only in the authorityRevocationList 

> attribute, but makes no mention as to whether or not those CRLs should 

> contain an Issuing Distribution Point extension. We claim they must in 

> order for a relying party to be sure that the CRL is a partial CRL 

> containing an exhaustive list of revoked CA certs only.

> 

> Have there been any partial CRLs deployed w/o Issuing Distribution

> Point extensions?

> 

> We think that RFC 2459 should be changed (or made more clear) to make 

> the Issuing Distribution Point extension mandatory for CAs which split CRLs

> according to reason codes or user/CA type, and that relying parties

> should treat CRLs without an Issuing Distribution Point

> extension as complete (exhaustive) CRLs.


</color>I think, you don't have another choices in the case, when you have

CRL with full reasons ( or without IDP at all ).


<color><param>7F00,0000,0000</param>> 

> -- 

> Sean Mullan			Email: [e-mail]

> Sun Microsystems Laboratories	Tel:   [phone]	

> One Network Drive		Fax:   [phone]

> Burlington, MA 01803-0902

> 



<nofill>
____________
Pavel Krylov


Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA29063 for <[e-mail]>; Fri, 15 Oct 1999 08:19:02 -0700 (PDT)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12809 for <[e-mail]>; Fri, 15 Oct 1999 08:21:10 -0700 (PDT)
Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA28789; Fri, 15 Oct 1999 11:21:05 -0400 (EDT)
Received: from sun.com (bubinga [129.148.75.129]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id LAA29899; Fri, 15 Oct 1999 11:21:04 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 15 Oct 1999 11:21:01 -0400
From: Sean Mullan <[e-mail]>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Processing CRLs without Issuing Distribution Points
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

RFC 2459 does not require that CRLs contain an Issuing
Distribution Point extension.

Does this mean that a CA may issue *partial* CRLs without
including an Issuing Distribution Point Extension?

If the answer is yes, it is not possible for a relying party to 
safely determine if a certificate has not been revoked by inspecting
a CRL without an Issuing Distribution Point extension. It cannot
assume that a single CRL is an exhaustive list and it also cannot
assume a sequence of CRLs when taken as one is an exhaustive list.
Therefore a relying party cannot safely determine that the certificate in 
question has not been revoked.

RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial 
CRLs containing revoked CA certs only in the authorityRevocationList 
attribute, but makes no mention as to whether or not those CRLs should 
contain an Issuing Distribution Point extension. We claim they must in 
order for a relying party to be sure that the CRL is a partial CRL 
containing an exhaustive list of revoked CA certs only.

Have there been any partial CRLs deployed w/o Issuing Distribution
Point extensions?

We think that RFC 2459 should be changed (or made more clear) to make 
the Issuing Distribution Point extension mandatory for CAs which split CRLs
according to reason codes or user/CA type, and that relying parties
should treat CRLs without an Issuing Distribution Point
extension as complete (exhaustive) CRLs.

-- 
Sean Mullan			Email: [e-mail]
Sun Microsystems Laboratories	Tel:   [phone]	
One Network Drive		Fax:   [phone]
Burlington, MA 01803-0902


Received: from Default (ip12.proper.com [165.227.249.12]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA28262; Thu, 14 Oct 1999 14:28:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 14 Oct 1999 14:31:07 -0700
To: Robert Moskowitz <[e-mail]>, Tim Polk <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: updated path validation text
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:02 PM 10/14/99 -0400, Robert Moskowitz wrote:
>here is it mostly cleaned up..

That is *not* clean, *nor* is it complete. The beginning of the file you 
sent reads:

                Upon completion of all steps, path processing has
                succeeded if the value of explicit_policy variable is
                greater than zero, or the valid_policy_tree is not NULL.


             6
              .1

                .
                 6
                   O

                    ut
                      p
                       u
                        t


                         s

Could people who have alternative formats for documents pass those files to 
the document authors and let those authors turn them in? If you want to 
help Tim, send the file to Tim, not the whole list. He can decide whether 
or not to make this a list thing.

Also, as the maintainer of the web site, I'm happy to take a file from you 
and put it on the web site so you can just send a pointer. That way, the 
subset of the 1170 people on this mailing list who can't read your format 
don't have to waste their time with downloading a file they can't read.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.imc.org (8.9.3/8.9.3) with SMTP id OAA27636 for <[e-mail]>; Thu, 14 Oct 1999 14:03:53 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Thu, 14 Oct 1999 17:05:29 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 14 Oct 1999 17:02:16 -0400
To: Tim Polk <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: updated path validation text
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_64037881==_"

--=====================_64037881==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:36 PM 10/13/1999 -0400, Tim Polk wrote:

>P.S.  Sorry about the Word attachment.  The straightforward conversion to
>text lost all the formatting/indenting , and I think that really helps the
>readers' comprehension.  If anyone asks, I will convert it to a nice UNIX
>text file and repost.  Otherwise, it will get fixed when I convert to
>nroff...

here is it mostly cleaned up..


--=====================_64037881==_
Content-Type: text/plain; name="2459-61.txt";
 x-mac-type="42494E41"; x-mac-creator="74747874"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="2459-61.txt"

DQoNCg0KDQoNCiAgICAgICAgICAgICAgIFVwb24gY29tcGxldGlvbiBvZiBhbGwgc3RlcHMsIHBh
dGggcHJvY2Vzc2luZyBoYXMNCiAgICAgICAgICAgICAgIHN1Y2NlZWRlZCBpZiB0aGUgdmFsdWUg
b2YgZXhwbGljaXRfcG9saWN5IHZhcmlhYmxlIGlzDQogICAgICAgICAgICAgICBncmVhdGVyIHRo
YW4gemVybywgb3IgdGhlIHZhbGlkX3BvbGljeV90cmVlIGlzIG5vdCBOVUxMLg0KDQogICAgICAg
ICAgICAgDSAgICAgICAgICAgIDYgDSAgICAgICAgICAgICAuMQ0gICAgICAgICAgICAgICAgDSAg
ICAgICAgICAgICAgIC4gDSAgICAgICAgICAgICAgICA2IA0gICAgICAgICAgICAgICAgICBPDSAg
ICAgICAgICAgICAgICAgICAgDSAgICAgICAgICAgICAgICAgICB1dA0gICAgICAgICAgICAgICAg
ICAgICBwDSAgICAgICAgICAgICAgICAgICAgICB1DSAgICAgICAgICAgICAgICAgICAgICAgdA0g
ICAgICAgICAgICAgICAgICAgICAgICANICAgICAgICAgICAgICAgICAgICAgICAgIA0gICAgICAg
ICAgICAgICAgICAgICAgICBzDQoNCiAgICAgICAgICAgIElmIHBhdGggcHJvY2Vzc2luZyBzdWNj
ZWVkcywgdGhlIHByb2NlZHVyZSB0ZXJtaW5hdGVzLA0KICAgICAgICAgICAgcmV0dXJuaW5nIGEg
c3VjY2VzcyBpbmRpY2F0aW9uIHRvZ2V0aGVyIHdpdGggZmluYWwgdmFsdWUgb2YNCiAgICAgICAg
ICAgIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSwgdGhlIHdvcmtpbmdfcHVibGljX2tleSwgdGhlDQog
ICAgICAgICAgICB3b3JraW5nX3B1YmxpY19rZXlfYWxnb3JpdGhtLCBhbmQgdGhlDQogICAgICAg
ICAgICB3b3JraW5nX3B1YmxpY19rZXlfcGFyYW1ldGVycy4NCgwNCg0KDQoNCg0KDQogICAgICAg
ICAgICBJZiAoYSksIChrKSwgKGwpLCAobikgYW5kIChvKSBoYXZlIGNvbXBsZXRlZCBzdWNjZXNz
ZnVsbHksDQogICAgICAgICAgICBpbmNyZW1lbnQgaSBhbmQgcGVyZm9ybSB0aGUgYmFzaWMgY2Vy
dGlmaWNhdGUgcHJvY2Vzc2luZw0KICAgICAgICAgICAgc3BlY2lmaWVkIGluIDYuMS4yLg0KDQog
ICAgICAgICAgICAgDSAgICAgICAgICAgIDYgDSAgICAgICAgICAgICAuMQ0gICAgICAgICAgICAg
ICAgDSAgICAgICAgICAgICAgIC4gDSAgICAgICAgICAgICAgICA1IA0gICAgICAgICAgICAgICAg
ICBXDSAgICAgICAgICAgICAgICAgICAgDSAgICAgICAgICAgICAgICAgICByIA0gICAgICAgICAg
ICAgICAgICAgIGEgDSAgICAgICAgICAgICAgICAgICAgIHAgDSAgICAgICAgICAgICAgICAgICAg
ICAtdQ0gICAgICAgICAgICAgICAgICAgICAgICBwDSAgICAgICAgICAgICAgICAgICAgICAgICAg
DSAgICAgICAgICAgICAgICAgICAgICAgICAgcA0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
DSAgICAgICAgICAgICAgICAgICAgICAgICAgIHIgDSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBvYw0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGVkDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdQ0gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHINICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGUNCg0KICAgICAgICAgICAgKGEpIElmIGNlcnRpZmljYXRlIG4gd2Fz
IG5vdCBzZWxmLWlzc3VlZCBhbmQgZXhwbGljaXRfcG9saWN5DQogICAgICAgICAgICBpcyBub3Qg
MCwgZGVjcmVtZW50IGV4cGxpY2l0X3BvbGljeSBieSAxLg0KDQogICAgICAgICAgICAoYikgSWYg
YSBwb2xpY3kgY29uc3RyYWludHMgZXh0ZW5zaW9uIGlzIGluY2x1ZGVkIGluIHRoZQ0KICAgICAg
ICAgICAgY2VydGlmaWNhdGUgYW5kIHJlcXVpcmVFeHBsaWNpdFBvbGljeSBpcyBwcmVzZW50IGFu
ZCBoYXMgYQ0KICAgICAgICAgICAgdmFsdWUgb2YgMCwgc2V0IHRoZSBleHBsaWNpdF9wb2xpY3kg
c3RhdGUgdmFyaWFibGUgdG8gMC4NCg0KICAgICAgICAgICAgKGMpIEFzc2lnbiB0aGUgY2VydGlm
aWNhdGUgc3ViamVjdFB1YmxpY0tleSB0bw0KICAgICAgICAgICAgd29ya2luZ19wdWJsaWNfa2V5
Lg0KDQogICAgICAgICAgICAoZCkgSWYgdGhlIHN1YmplY3RQdWJsaWNLZXlJbmZvIGZpZWxkIG9m
IHRoZSBjZXJ0aWZpY2F0ZQ0KICAgICAgICAgICAgY29udGFpbnMgYW4gYWxnb3JpdGhtIGZpZWxk
IHdpdGggbm9uLW51bGwgcGFyYW1ldGVycywgYXNzaWduDQogICAgICAgICAgICB0aGUgcGFyYW1l
dGVycyB0byB0aGUgd29ya2luZ19wdWJsaWNfa2V5X3BhcmFtZXRlcnMNCiAgICAgICAgICAgIHZh
cmlhYmxlLg0KDQogICAgICAgICAgICAoZSkgQXNzaWduIHRoZSBjZXJ0aWZpY2F0ZSBzdWJqZWN0
UHVibGljS2V5IGFsZ29yaXRobSB0byB0aGUNCiAgICAgICAgICAgIHdvcmtpbmdfcHVibGljX2tl
eV9hbGdvcml0aG0gdmFyaWFibGUuDQoNCiAgICAgICAgICAgIChmKSBSZWNvZ25pemUgYW5kIHBy
b2Nlc3MgYW55IG90aGVyIGNyaXRpY2FsIGV4dGVuc2lvbg0KICAgICAgICAgICAgcHJlc2VudCBp
biB0aGUgY2VydGlmaWNhdGUgbi4NCg0KICAgICAgICAgICAgKGcpIENhbGN1bGF0ZSB0aGUgaW50
ZXJzZWN0aW9uIG9mIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSBhbmQNCiAgICAgICAgICAgIHRoZSB1
c2VyX2luaXRpYWxfcG9saWN5X3NldCwgYXMgZm9sbG93czoNCg0KICAgICAgICAgICAgICAgICAo
aSkgSWYgdGhlIHZhbGlkX3BvbGljeV90cmVlIGlzIE5VTEwsIHRoZSBpbnRlcnNlY3Rpb24NCiAg
ICAgICAgICAgICAgICAgaXMgTlVMTC4NCg0KICAgICAgICAgICAgICAgICAoaWkpIElmIHRoZSB2
YWxpZF9wb2xpY3lfdHJlZSBpcyBub3QgTlVMTCBhbmQgdGhlDQogICAgICAgICAgICAgICAgIHVz
ZXJfaW5pdGlhbF9wb2xpY3lfc2V0IGlzIJNhbnktcG9saWN5lCwgdGhlDQogICAgICAgICAgICAg
ICAgIGludGVyc2VjdGlvbiBpcyB0aGUgZW50aXJlIHZhbGlkX3BvbGljeV90cmVlLg0KDQogICAg
ICAgICAgICAgICAgIChpaWkpIElmIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSBpcyBub3QgTlVMTCBh
bmQgdGhlDQogICAgICAgICAgICAgICAgIHVzZXJfaW5pdGlhbF9wb2xpY3lfc2V0IGlzIG5vdCCT
YW55LXBvbGljeZQsIGNhbGN1bGF0ZQ0KICAgICAgICAgICAgICAgICB0aGUgaW50ZXJzZWN0aW9u
IG9mIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSBhbmQgdGhlDQogICAgICAgICAgICAgICAgIHVzZXJf
aW5pdGlhbF9wb2xpY3lfc2V0IGFzIGZvbGxvd3M6DQoNCiAgICAgICAgICAgICAgICAgICAgICAx
LiBkZXRlcm1pbmUgdGhlIHNldCBvZiBwb2xpY3kgbm9kZXMgd2hvc2UgcGFyZW50DQogICAgICAg
ICAgICAgICAgICAgICAgbm9kZXMgaGF2ZSBhIHZhbGlkX3BvbGljeSBvZiCTYW55LXBvbGljeZQu
ICBUaGlzDQogICAgICAgICAgICAgICAgICAgICAgaXMgdGhlIHZhbGlkX3BvbGljeV9ub2RlX3Nl
dC4NCiAgICAgICAgICAgICAgICAgICAgICAyLiBpZiB0aGUgdmFsaWRfcG9saWN5IG9mIGFueSBu
b2RlIGluIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgIHZhbGlkX3BvbGljeV9ub2RlX3NldCBp
cyBub3QgaW4gdGhlDQogICAgICAgICAgICAgICAgICAgICAgdXNlcl9pbml0aWFsX3BvbGljeV9z
ZXQgYW5kIGlzIG5vdCCTYW55LXBvbGljeZQsDQogICAgICAgICAgICAgICAgICAgICAgZGVsZXRl
IHRoaXMgbm9kZSBhbmQgYWxsIGl0cyBjaGlsZHJlbi4NCiAgICAgICAgICAgICAgICAgICAgICAz
LiBpZiB0aGVyZSBpcyBhIG5vZGUgaW4gdGhlIHZhbGlkX3BvbGljeV90cmVlIG9mDQogICAgICAg
ICAgICAgICAgICAgICAgZGVwdGggbi0xIG9yIGxlc3Mgd2l0aG91dCBhbnkgY2hpbGQgbm9kZXMs
IGRlbGV0ZQ0KICAgICAgICAgICAgICAgICAgICAgIHRoYXQgbm9kZS4gUmVwZWF0IHRoaXMgc3Rl
cCB1bnRpbCB0aGVyZSBhcmUgbm8NCiAgICAgICAgICAgICAgICAgICAgICBub2RlcyBvZiBkZXB0
aCBuLTEgb3IgbGVzcyB3aXRob3V0IGNoaWxkcmVuLg0KDA0KDQoNCg0KDQoNCiAgICAgICAgICAg
ICAgICAgICAgICB2YXJpYWJsZSB0byB0aGUgdW5pb24gb2YgaXRzIHByZXZpb3VzIHZhbHVlIGFu
ZA0KICAgICAgICAgICAgICAgICAgICAgIHRoZSB2YWx1ZSBpbmRpY2F0ZWQgaW4gdGhlIGV4dGVu
c2lvbiBmaWVsZC4gSWYNCiAgICAgICAgICAgICAgICAgICAgICBleGNsdWRlZFN1YnRyZWVzIGRv
ZXMgbm90IGluY2x1ZGUgYSBwYXJ0aWN1bGFyDQogICAgICAgICAgICAgICAgICAgICAgbmFtZSB0
eXBlLCB0aGUgZXhjbHVkZWRfc3VidHJlZXMgc3RhdGUgdmFyaWFibGUgaXMNCiAgICAgICAgICAg
ICAgICAgICAgICB1bmNoYW5nZWQgZm9yIHRoYXQgbmFtZSB0eXBlLg0KDQogICAgICAgICAgICAg
ICAgIChoKSBpZiB0aGUgaXNzdWVyIGFuZCBzdWJqZWN0IG5hbWVzIGFyZSBub3QgaWRlbnRpY2Fs
Og0KDQogICAgICAgICAgICAgICAgICAgICAgKDEpIGlmIGV4cGxpY2l0X3BvbGljeSBpcyBub3Qg
MCwgZGVjcmVtZW50DQogICAgICAgICAgICAgICAgICAgICAgZXhwbGljaXRfcG9saWN5IGJ5IDEu
DQogICAgICAgICAgICAgICAgICAgICAgKDIpIGlmIHBvbGljeV9tYXBwaW5nIGlzIG5vdCAwLCBk
ZWNyZW1lbnQNCiAgICAgICAgICAgICAgICAgICAgICBwb2xpY3lfbWFwcGluZyBieSAxLg0KICAg
ICAgICAgICAgICAgICAgICAgICgzKSBpZiBpbmhpYml0X2FueS1wb2xpY3kgaXMgbm90IDAsIGRl
Y3JlbWVudA0KICAgICAgICAgICAgICAgICAgICAgIGluaGliaXRfYW55LXBvbGljeSBieSAxLg0K
DQogICAgICAgICAgICAgICAgIChpKSBJZiBhIHBvbGljeSBjb25zdHJhaW50cyBleHRlbnNpb24g
aXMgaW5jbHVkZWQgaW4NCiAgICAgICAgICAgICAgICAgdGhlIGNlcnRpZmljYXRlLCBtb2RpZnkg
dGhlIGV4cGxpY2l0X3BvbGljeSBhbmQNCiAgICAgICAgICAgICAgICAgcG9saWN5X21hcHBpbmcg
c3RhdGUgdmFyaWFibGVzIGFzIGZvbGxvd3M6DQoNCiAgICAgICAgICAgICAgICAgICAgICAoMSkg
SWYgcmVxdWlyZUV4cGxpY2l0UG9saWN5IGlzIHByZXNlbnQgYW5kIGlzDQogICAgICAgICAgICAg
ICAgICAgICAgbGVzcyB0aGFuIGV4cGxpY2l0X3BvbGljeSwgc2V0IGV4cGxpY2l0X3BvbGljeSB0
bw0KICAgICAgICAgICAgICAgICAgICAgIHRoZSB2YWx1ZSBvZiByZXF1aXJlRXhwbGljaXRQb2xp
Y3kuDQoNCiAgICAgICAgICAgICAgICAgICAgICAoMikgSWYgaW5oaWJpdFBvbGljeU1hcHBpbmcg
aXMgcHJlc2VudCBhbmQgaXMgbGVzcw0KICAgICAgICAgICAgICAgICAgICAgIHRoYW4gcG9saWN5
X21hcHBpbmcsIHNldCBwb2xpY3lfbWFwcGluZyB0byB0aGUNCiAgICAgICAgICAgICAgICAgICAg
ICB2YWx1ZSBvZiBpbmhpYml0UG9saWN5TWFwcGluZy4NCg0KICAgICAgICAgICAgICAgICAoaikg
SWYgdGhlIGluaGliaXRBbnlQb2xpY3kgZXh0ZW5zaW9uIGlzIGluY2x1ZGVkIGluDQogICAgICAg
ICAgICAgICAgIHRoZSBjZXJ0aWZpY2F0ZSBhbmQgaXMgbGVzcyB0aGFuIGluaGliaXRfYW55LXBv
bGljeSwNCiAgICAgICAgICAgICAgICAgc2V0IGluaGliaXRfYW55LXBvbGljeSB0byB0aGUgdmFs
dWUgb2YNCiAgICAgICAgICAgICAgICAgaW5oaWJpdEFueVBvbGljeS4NCg0KICAgICAgICAgICAg
ICAgICAoaykgVmVyaWZ5IHRoYXQgdGhlIGNlcnRpZmljYXRlIGlzIGEgQ0EgY2VydGlmaWNhdGUg
KGFzDQogICAgICAgICAgICAgICAgIHNwZWNpZmllZCBpbiBhIGJhc2ljQ29uc3RyYWludHMgZXh0
ZW5zaW9uIG9yIGFzDQogICAgICAgICAgICAgICAgIHZlcmlmaWVkIG91dC1vZi1iYW5kKS4NCg0K
ICAgICAgICAgICAgICAgICAobCkgSWYgdGhlIGNlcnRpZmljYXRlIHdhcyBub3Qgc2VsZi1pc3N1
ZWQsIHZlcmlmeSB0aGF0DQogICAgICAgICAgICAgICAgIG1heF9wYXRoX2xlbmd0aCBpcyBncmVh
dGVyIHRoYW4gemVybyBhbmQgZGVjcmVtZW50DQogICAgICAgICAgICAgICAgIG1heF9wYXRoX2xl
bmd0aCBieSAxLg0KDQogICAgICAgICAgICAgICAgIChtKSBJZiBwYXRoTGVuZ3RoQ29uc3RyYWlu
dCBpcyBwcmVzZW50IGluIHRoZQ0KICAgICAgICAgICAgICAgICBjZXJ0aWZpY2F0ZSBhbmQgaXMg
bGVzcyB0aGFuIG1heF9wYXRoX2xlbmd0aCwgc2V0DQogICAgICAgICAgICAgICAgIG1heF9wYXRo
X2xlbmd0aCB0byB0aGUgdmFsdWUgb2YgcGF0aExlbmd0aENvbnN0cmFpbnQuDQoNCiAgICAgICAg
ICAgICAgICAgKG4pIElmIGEga2V5IHVzYWdlIGV4dGVuc2lvbiBpcyBwcmVzZW50IGFuZCBtYXJr
ZWQNCiAgICAgICAgICAgICAgICAgY3JpdGljYWwsIHZlcmlmeSB0aGF0IHRoZSBrZXlDZXJ0U2ln
biBiaXQgaXMgc2V0Lg0KDQogICAgICAgICAgICAgICAgIChvKSBSZWNvZ25pemUgYW5kIHByb2Nl
c3MgYW55IG90aGVyIGNyaXRpY2FsIGV4dGVuc2lvbg0KICAgICAgICAgICAgICAgICBwcmVzZW50
IGluIHRoZSBjZXJ0aWZpY2F0ZS4NCg0KICAgICAgICAgICAgSWYgY2hlY2sgKGEpLCAoayksIChs
KSwgKG4pIG9yIChvKSBmYWlscywgdGhlIHByb2NlZHVyZQ0KICAgICAgICAgICAgdGVybWluYXRl
cywgcmV0dXJuaW5nIGEgZmFpbHVyZSBpbmRpY2F0aW9uIGFuZCBhbg0KICAgICAgICAgICAgYXBw
cm9wcmlhdGUgcmVhc29uLg0KDA0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICBpIHdo
ZXJlIElELVAgaXMgdGhlIHZhbGlkX3BvbGljeSwgc2V0DQogICAgICAgICAgICAgICAgICAgICAg
ZXhwZWN0ZWRfcG9saWN5X3NldCB0byB0aGUgc2V0IG9mDQogICAgICAgICAgICAgICAgICAgICAg
c3ViamVjdERvbWFpblBvbGljeSB2YWx1ZXMgdGhhdCBhcmUgc3BlY2lmaWVkIGFzDQogICAgICAg
ICAgICAgICAgICAgICAgZXF1aXZhbGVudCB0byBJRC1QIGJ5IHRoZSBwb2xpY3kgbWFwcGluZw0K
ICAgICAgICAgICAgICAgICAgICAgIGV4dGVuc2lvbi4NCg0KICAgICAgICAgICAgICAgICAgICAg
ICgyKSBpZiB0aGUgcG9saWN5X21hcHBpbmcgdmFyaWFibGUgaXMgZXF1YWwgdG8gMDoNCg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgKGkpIGRlbGV0ZSBlYWNoIG5vZGUgb2YgZGVwdGggaSBp
biB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHZhbGlkX3BvbGljeV90cmVlIHdoZXJl
IElELVAgaXMgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICB2YWxpZF9wb2xpY3kuDQoN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgIChpaSkgaWYgdGhlcmUgaXMgYSBub2RlIGluIHRo
ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsaWRfcG9saWN5X3RyZWUgb2YgZGVwdGgg
aS0xIG9yIGxlc3MNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGhvdXQgYW55IGNoaWxk
IG5vZGVzLCBkZWxldGUgdGhhdCBub2RlLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVw
ZWF0IHRoaXMgc3RlcCB1bnRpbCB0aGVyZSBhcmUgbm8gbm9kZXMgb2YNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGRlcHRoIGktMSBvciBsZXNzIHdpdGhvdXQgY2hpbGRyZW4uDQoNCiAgICAg
ICAgICAgICAgICAgKGMpIEFzc2lnbiB0aGUgY2VydGlmaWNhdGUgc3ViamVjdCBuYW1lIHRvDQog
ICAgICAgICAgICAgICAgIHdvcmtpbmdfaXNzdWVyX25hbWUuDQoNCiAgICAgICAgICAgICAgICAg
KGQpIEFzc2lnbiB0aGUgY2VydGlmaWNhdGUgc3ViamVjdFB1YmxpY0tleSB0bw0KICAgICAgICAg
ICAgICAgICB3b3JraW5nX3B1YmxpY19rZXkuDQoNCiAgICAgICAgICAgICAgICAgKGUpIElmIHRo
ZSBzdWJqZWN0UHVibGljS2V5SW5mbyBmaWVsZCBvZiB0aGUNCiAgICAgICAgICAgICAgICAgY2Vy
dGlmaWNhdGUgY29udGFpbnMgYW4gYWxnb3JpdGhtIGZpZWxkIHdpdGggbm9uLW51bGwNCiAgICAg
ICAgICAgICAgICAgcGFyYW1ldGVycywgYXNzaWduIHRoZSBwYXJhbWV0ZXJzIHRvIHRoZQ0KICAg
ICAgICAgICAgICAgICB3b3JraW5nX3B1YmxpY19rZXlfcGFyYW1ldGVycyB2YXJpYWJsZS4NCg0K
ICAgICAgICAgICAgICAgICBJZiB0aGUgc3ViamVjdFB1YmxpY0tleUluZm8gZmllbGQgb2YgdGhl
IGNlcnRpZmljYXRlDQogICAgICAgICAgICAgICAgIGNvbnRhaW5zIGFuIGFsZ29yaXRobSBmaWVs
ZCB3aXRoIG51bGwgcGFyYW1ldGVycywNCiAgICAgICAgICAgICAgICAgY29tcGFyZSB0aGUgY2Vy
dGlmaWNhdGUgc3ViamVjdFB1YmxpY0tleSBhbGdvcml0aG0gdG8NCiAgICAgICAgICAgICAgICAg
dGhlIHdvcmtpbmdfcHVibGljX2tleV9hbGdvcml0aG0uDQogICAgICAgICAgICAgICAgIElmIHRo
ZSBjZXJ0aWZpY2F0ZSBzdWJqZWN0UHVibGljS2V5IGFsZ29yaXRobSBhbmQgdGhlDQogICAgICAg
ICAgICAgICAgIHdvcmtpbmdfcHVibGljX2tleV9hbGdvcml0aG0gYXJlIGRpZmZlcmVudCwgc2V0
IHRoZQ0KICAgICAgICAgICAgICAgICB3b3JraW5nX3B1YmxpY19rZXlfcGFyYW1ldGVycyB0byBu
dWxsLg0KDQogICAgICAgICAgICAgICAgIChmKSBBc3NpZ24gdGhlIGNlcnRpZmljYXRlIHN1Ympl
Y3RQdWJsaWNLZXkgYWxnb3JpdGhtDQogICAgICAgICAgICAgICAgIHRvIHRoZSB3b3JraW5nX3B1
YmxpY19rZXlfYWxnb3JpdGhtIHZhcmlhYmxlLg0KDQogICAgICAgICAgICAgICAgIChnKSBJZiBh
IG5hbWUgY29uc3RyYWludHMgZXh0ZW5zaW9uIGlzIGluY2x1ZGVkIGluIHRoZQ0KICAgICAgICAg
ICAgICAgICBjZXJ0aWZpY2F0ZSwgbW9kaWZ5IHRoZSBwZXJtaXR0ZWRfc3VidHJlZXMgYW5kDQog
ICAgICAgICAgICAgICAgIGV4Y2x1ZGVkX3N1YnRyZWVzIHN0YXRlIHZhcmlhYmxlcyBhcyBmb2xs
b3dzOg0KDQogICAgICAgICAgICAgICAgICAgICAgKDEpIGlmIHBlcm1pdHRlZFN1YnRyZWVzIGlz
IHByZXNlbnQgaW4gdGhlDQogICAgICAgICAgICAgICAgICAgICAgY2VydGlmaWNhdGUsIHNldCB0
aGUgcGVybWl0dGVkX3N1YnRyZWVzIHN0YXRlDQogICAgICAgICAgICAgICAgICAgICAgdmFyaWFi
bGUgdG8gdGhlIGludGVyc2VjdGlvbiBvZiBpdHMgcHJldmlvdXMgdmFsdWUNCiAgICAgICAgICAg
ICAgICAgICAgICBhbmQgdGhlIHZhbHVlIGluZGljYXRlZCBpbiB0aGUgZXh0ZW5zaW9uIGZpZWxk
Lg0KICAgICAgICAgICAgICAgICAgICAgIElmIHBlcm1pdHRlZFN1YnRyZWVzIGRvZXMgbm90IGlu
Y2x1ZGUgYSBwYXJ0aWN1bGFyDQogICAgICAgICAgICAgICAgICAgICAgbmFtZSB0eXBlLCB0aGUg
cGVybWl0dGVkX3N1YnRyZWVzIHN0YXRlIHZhcmlhYmxlDQogICAgICAgICAgICAgICAgICAgICAg
aXMgdW5jaGFuZ2VkIGZvciB0aGF0IG5hbWUgdHlwZS4NCg0KICAgICAgICAgICAgICAgICAgICAg
ICgyKSBJZiBleGNsdWRlZFN1YnRyZWVzIGlzIHByZXNlbnQgaW4gdGhlDQogICAgICAgICAgICAg
ICAgICAgICAgY2VydGlmaWNhdGUsIHNldCB0aGUgZXhjbHVkZWRfc3VidHJlZXMgc3RhdGUNCgwN
Cg0KDQoNCg0KDQogICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgfCAgICAgWCAgICAgfCAg
fCAgICAgICAgICAgfCAgfCAgIFgNCiAgICAgICAgICAgICAgICAgfCAgZGVwdGgNCiAgICAgICAg
ICAgICAgICAgfC0tLS0tLS0tLS0tfCB8LS0tLS0tLS0tLS18ICB8LS0tLS0tLS0tLS18ICB8LS0t
LS0tLS0tLQ0KICAgICAgICAgICAgICAgICAtfCAgIGktMQ0KICAgICAgICAgICAgICAgICAgICAg
ICB8ICAgICAgICAgICAgICAgICAgICAgIC8gICAgIHwgICAgIFwNCiAgICAgICAgICAgICAgICAg
ICAgICAgfCAgICAgICAgICAgICAgICAgICAgIC8gICAgICB8ICAgICAgXA0KICAgICAgICAgICAg
ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAvICAgICAgIHwgICAgICAgXA0KICAgICAg
ICAgICAgICAgICB8LS0tLS0tLS0tLS18IHwtLS0tLS0tLS0tLXwgIHwtLS0tLS0tLS0tLXwgIHwt
LS0tLS0tLS0tDQogICAgICAgICAgICAgICAgIC18IG5vZGVzIG9mDQogICAgICAgICAgICAgICAg
IHwgICAgICAgICAgIHwgfCAgICAgICAgICAgfCAgfCAgICAgICAgICAgfCAgfA0KICAgICAgICAg
ICAgICAgICB8ICBkZXB0aA0KICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS18IHwtLS0tLS0t
LS0tLXwgIHwtLS0tLS0tLS0tLXwgIHwtLS0tLS0tLS0tDQogICAgICAgICAgICAgICAgIC18ICAg
aQ0KDQogICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNy4gIFBydW5pbmcgdGhlIHZhbGlk
X3BvbGljeV90cmVlDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICg0KSBpZiB0aGUgY2VydGlm
aWNhdGUgcG9saWNpZXMgZXh0ZW5zaW9uIHdhcw0KICAgICAgICAgICAgICAgICAgICAgIG1hcmtl
ZCBhcyBjcml0aWNhbCwgc2V0IHRoZSBjcml0aWNhbGl0eV9pbmRpY2F0b3INCiAgICAgICAgICAg
ICAgICAgICAgICBpbiBhbGwgbm9kZXMgb2YgZGVwdGggaSB0byBUUlVFLiBJZiB0aGUNCiAgICAg
ICAgICAgICAgICAgICAgICBjZXJ0aWZpY2F0ZSBwb2xpY2llcyBleHRlbnNpb24gd2FzIG5vdCBt
YXJrZWQNCiAgICAgICAgICAgICAgICAgICAgICBjcml0aWNhbCwgc2V0IHRoZSBjcml0aWNhbGl0
eV9pbmRpY2F0b3IgaW4gYWxsDQogICAgICAgICAgICAgICAgICAgICAgbm9kZXMgb2YgZGVwdGgg
aSB0byBGQUxTRS4NCg0KICAgICAgICAgICAgICAgICAoZSkgaWYgdGhlIGNlcnRpZmljYXRlIHBv
bGljaWVzIGV4dGVuc2lvbiBpcyBub3QNCiAgICAgICAgICAgICAgICAgcHJlc2VudCwgc2V0IHRo
ZSB2YWxpZF9wb2xpY3lfdHJlZSB0byBOVUxMLg0KDQogICAgICAgICAgICAgICAgIChmKSB2ZXJp
ZnkgdGhhdCBlaXRoZXIgZXhwbGljaXRfcG9saWN5IGlzIGdyZWF0ZXIgdGhhbg0KICAgICAgICAg
ICAgICAgICAwIG9yIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSBpcyBub3QgZXF1YWwgdG8gTlVMTDsN
Cg0KICAgICAgICAgICAgSWYgYW55IG9mIHN0ZXBzIChhKSwgKGIpLCAoYyksIG9yIChmKSBmYWls
cywgdGhlIHByb2NlZHVyZQ0KICAgICAgICAgICAgdGVybWluYXRlcywgcmV0dXJuaW5nIGEgZmFp
bHVyZSBpbmRpY2F0aW9uIGFuZCBhbg0KICAgICAgICAgICAgYXBwcm9wcmlhdGUgcmVhc29uLg0K
DQogICAgICAgICAgICBJZiBpIGlzIG5vdCBlcXVhbCB0byBuLCBjb250aW51ZSBieSBwZXJmb3Jt
aW5nIHRoZQ0KICAgICAgICAgICAgcHJlcGFyYXRvcnkgc3RlcHMgbGlzdGVkIGluIDYuMS40LiAg
SWYgaSBpcyBlcXVhbCB0byBuLA0KICAgICAgICAgICAgcGVyZm9ybSB0aGUgd3JhcC11cCBzdGVw
cyBsaXN0ZWQgaW4gNi4xLjUuDQoNCiAgICAgICAgICAgICANICAgICAgICAgICAgNiANICAgICAg
ICAgICAgIC4xDSAgICAgICAgICAgICAgICANICAgICAgICAgICAgICAgLiANICAgICAgICAgICAg
ICAgIDQgDSAgICAgICAgICAgICAgICAgIFANICAgICAgICAgICAgICAgICAgICANICAgICAgICAg
ICAgICAgICAgIHIgDSAgICAgICAgICAgICAgICAgICAgZSANICAgICAgICAgICAgICAgICAgICAg
cCANICAgICAgICAgICAgICAgICAgICAgIGFyDSAgICAgICAgICAgICAgICAgICAgICAgIGENICAg
ICAgICAgICAgICAgICAgICAgICAgICANICAgICAgICAgICAgICAgICAgICAgICAgIHRpDSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICANICAgICAgICAgICAgICAgICAgICAgICAgICAgbyANICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIG4gDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGYNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIG9yDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGMNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBlDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHINICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHQNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBpDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZiANICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGkgDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgY2ENICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRlDSAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGkrDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIA0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDENCg0KICAg
ICAgICAgICAgVG8gcHJlcGFyZSBmb3IgcHJvY2Vzc2luZyBvZiBjZXJ0aWZpY2F0ZSBpKzEsIHBl
cmZvcm0gdGhlDQogICAgICAgICAgICBmb2xsb3dpbmcgc3RlcHMgZm9yIGNlcnRpZmljYXRlIGk6
DQoNCiAgICAgICAgICAgICAgICAgKGEpIGlmIGEgcG9saWN5IG1hcHBpbmcgZXh0ZW5zaW9uIGlz
IHByZXNlbnQsIHZlcmlmeQ0KICAgICAgICAgICAgICAgICB0aGF0IHRoZSBzcGVjaWFsIHZhbHVl
IJNhbnktcG9saWN5lCBkb2VzIG5vdCBhcHBlYXIgYXMNCiAgICAgICAgICAgICAgICAgYW4gaXNz
dWVyRG9tYWluUG9saWN5IG9yIGEgc3ViamVjdERvbWFpblBvbGljeS4NCg0KICAgICAgICAgICAg
ICAgICAoYikgaWYgYSBwb2xpY3kgbWFwcGluZyBleHRlbnNpb24gaXMgcHJlc2VudCwgdGhlbiBm
b3INCiAgICAgICAgICAgICAgICAgZWFjaCBpc3N1ZXJEb21haW5Qb2xpY3kgSUQtUCBpbiB0aGUg
cG9saWN5IG1hcHBpbmcNCiAgICAgICAgICAgICAgICAgZXh0ZW5zaW9uOg0KDQoNCiAgICAgICAg
ICAgICAgICAgICAgICAoMSkgaWYgdGhlIHBvbGljeV9tYXBwaW5nIHZhcmlhYmxlIGlzIGdyZWF0
ZXIgdGhhbg0KICAgICAgICAgICAgICAgICAgICAgIDAsIGZvciBlYWNoIG5vZGUgaW4gdGhlIHZh
bGlkX3BvbGljeV90cmVlIG9mIGRlcHRoDQoMDQoNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB8ICB7R29sZCwgU2lsdmVyfSB8DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIC8gICAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC8gICAgICAgICAgICAgXA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAvICAgICAgICAgICAgICAgXA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIC8gICAgICAgICAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAg
ICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18DQog
ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICBHb2xkICAgICAgIHwgICAgICAgICAgfCAgICAg
U2lsdmVyICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18
ICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwNCiAgICAgICAgICAgICAgICAgICAgICAgfCAg
ICAgICB7fSAgICAgICAgfCAgICAgICAgICB8ICAgICAgIHt9ICAgICAgICB8DQogICAgICAgICAg
ICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwgbm9kZXMgb2YgfC0tLS0tLS0tLS0tLS0t
LS0tfA0KICAgICAgICAgICAgICAgICAgICAgICB8IHVuaW5pdGlhbGl6ZWQgICB8IGRlcHRoIGkg
IHwgdW5pbml0aWFsaXplZCAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0t
LS0tLS0tfCAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18DQogICAgICAgICAgICAgICAgICAg
ICAgIHwgICAgIHtHb2xkfSAgICAgIHwgICAgICAgICAgfCAgICB7U2lsdmVyfSAgICAgfA0KICAg
ICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgIHwtLS0tLS0t
LS0tLS0tLS0tLXwNCg0KDQogICAgICAgICAgICAgICAgIEZpZ3VyZSA2LiBQcm9jZXNzaW5nIHVu
bWF0Y2hlZCBwb2xpY2llcyB3aGVuIHRoZQ0KICAgICAgICAgICAgICAgICBjZXJ0aWZpY2F0ZSBw
b2xpY2llcyBleHRlbnNpb24gc3BlY2lmaWVzIJNhbnktcG9saWN5lA0KDQoNCiAgICAgICAgICAg
ICAgICAgICAgICAoMykgaWYgdGhlcmUgaXMgYSBub2RlIGluIHRoZSB2YWxpZF9wb2xpY3lfdHJl
ZSBvZg0KICAgICAgICAgICAgICAgICAgICAgIGRlcHRoIGktMSBvciBsZXNzIHdpdGhvdXQgYW55
IGNoaWxkIG5vZGVzLCBkZWxldGUNCiAgICAgICAgICAgICAgICAgICAgICB0aGF0IG5vZGUuIFJl
cGVhdCB0aGlzIHN0ZXAgdW50aWwgdGhlcmUgYXJlIG5vDQogICAgICAgICAgICAgICAgICAgICAg
bm9kZXMgb2YgZGVwdGggaS0xIG9yIGxlc3Mgd2l0aG91dCBjaGlsZHJlbi4NCg0KICAgICAgICAg
ICAgICAgICAgICAgIFtGb3IgZXhhbXBsZSwgY29uc2lkZXIgdGhlIHZhbGlkX3BvbGljeV90cmVl
IHNob3duDQogICAgICAgICAgICAgICAgICAgICAgaW4gRmlndXJlIDcgYmVsb3cuICBUaGUgdHdv
IG5vZGVzIGF0IGRlcHRoIGktMQ0KICAgICAgICAgICAgICAgICAgICAgIHRoYXQgYXJlIG1hcmtl
ZCB3aXRoIGFuIJFYkiBoYXZlIG5vIGNoaWxkcmVuLCBhbmQNCiAgICAgICAgICAgICAgICAgICAg
ICBhcmUgZGVsZXRlZC4gIEFwcGx5aW5nIHRoaXMgcnVsZSB0byB0aGUgcmVzdWx0aW5nDQogICAg
ICAgICAgICAgICAgICAgICAgdHJlZSB3aWxsIGNhdXNlIHRoZSBub2RlIGF0IGRlcHRoIGktMiB0
aGF0IGlzDQogICAgICAgICAgICAgICAgICAgICAgbWFya2VkIHdpdGggYW4gkVmSIHRvIGJlIGRl
bGV0ZWQuICBUaGUgZm9sbG93aW5nDQogICAgICAgICAgICAgICAgICAgICAgYXBwbGljYXRpb24g
b2YgdGhlIHJ1bGUgZG9lcyBub3QgY2F1c2UgYW55IG5vZGVzDQogICAgICAgICAgICAgICAgICAg
ICAgdG8gYmUgZGVsZXRlZCwgYW5kIHRoaXMgc3RlcCBpcyBjb21wbGV0ZS5dDQoNCg0KDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tfA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgbm9kZSBvZiBkZXB0aCBp
LTMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS18DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyAgICAgfCAgICAgXA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyAgICAgIHwgICAgICBcDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIC8gICAgICAgfCAgICAgICBcDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgLyAgICAgICAgfCAgICAgICAgXA0KICAgICAgICAgICAgICAg
ICAgICAgICAgfC0tLS0tLS0tLS0tfCB8LS0tLS0tLS0tLS18ICB8LS0tLS0tLS0tLS18DQogICAg
ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8IHwgICAgICAgICAgIHwgIHwgICAgIFkg
ICAgIHwgbm9kZXMNCiAgICAgICAgICAgICAgICAgb2YNCiAgICAgICAgICAgICAgICAgICAgICAg
ICB8LS0tLS0tLS0tLS18IHwtLS0tLS0tLS0tLXwgIHwtLS0tLS0tLS0tLXwNCiAgICAgICAgICAg
IGRlcHRoIGktMg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvICAgXCAgICAgICAgICAg
ICAgIFwgICAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAvICAgICBcICAg
ICAgICAgICAgICAgXCAgICAgICAgICAgXA0KICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS18
IHwtLS0tLS0tLS0tLXwgIHwtLS0tLS0tLS0tLXwgIHwtLS0tLS0tLS0tDQogICAgICAgICAgICAg
ICAgIC18IG5vZGVzIG9mDQoMDQoNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwgICAgICBGQUxTRSAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfCAge5NhbnktcG9saWN5lH0gfA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAvICAgICAgICAgICBcDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAvICAgICAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgLyAgICAgICAgICAgICAgIFwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAvICAgICAgICAgICAgICAgICBcDQogICAgICAgICAgICAgICAgICAgICAgIHwt
LS0tLS0tLS0tLS0tLS0tLXwgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfA0KICAgICAgICAg
ICAgICAgICAgICAgICB8ICAgICAgR29sZCAgICAgICB8ICAgICAgICAgIHwgICAgIFNpbHZlciAg
ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAg
ICB8LS0tLS0tLS0tLS0tLS0tLS18DQogICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAge30g
ICAgICAgIHwgICAgICAgICAgfCAgIHtRLVNpbHZlcn0gICAgfA0KICAgICAgICAgICAgICAgICAg
ICAgICB8LS0tLS0tLS0tLS0tLS0tLS18IG5vZGVzIG9mIHwtLS0tLS0tLS0tLS0tLS0tLXwNCiAg
ICAgICAgICAgICAgICAgICAgICAgfCB1bmluaXRpYWxpemVkICAgfCBkZXB0aCBpICB8IHVuaW5p
dGlhbGl6ZWQgICB8DQogICAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwg
ICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfA0KICAgICAgICAgICAgICAgICAgICAgICB8ICAg
ICB7R29sZH0gICAgICB8ICAgICAgICAgIHwgICAge1NpbHZlcn0gICAgIHwNCiAgICAgICAgICAg
ICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0t
LS18DQoNCg0KICAgICAgICAgICAgICAgICBGaWd1cmUgNS4gUHJvY2Vzc2luZyB1bm1hdGNoZWQg
cG9saWNpZXMgd2hlbiBhIGxlYWYNCiAgICAgICAgICAgICAgICAgbm9kZSBzcGVjaWZpZXMgk2Fu
eS1wb2xpY3mUDQoNCiAgICAgICAgICAgICAgICAgICAgICAoMikgaWYgdGhlIGNlcnRpZmljYXRl
IHBvbGljaWVzIGV4dGVuc2lvbiBpbmNsdWRlcw0KICAgICAgICAgICAgICAgICAgICAgIHRoZSBw
b2xpY3kgk2FueS1wb2xpY3mUIHdpdGggdGhlIHF1YWxpZmllciBzZXQgQVAtDQogICAgICAgICAg
ICAgICAgICAgICAgUSBhbmQgaW5oaWJpdF9hbnktcG9saWN5IGlzIGdyZWF0ZXIgdGhhbiAwOg0K
DQogICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgZWFjaCBub2RlIGluIHRoZSB2YWxpZF9w
b2xpY3lfdHJlZSBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVwdGggaS0xLCBmb3Ig
ZWFjaCB2YWx1ZSBpbiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4cGVjdGVkX3Bv
bGljeV9zZXQgKGluY2x1ZGluZyCTYW55LXBvbGljeZQpDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICB0aGF0IGRvZXMgbm90IGFwcGVhciBpbiBhIGNoaWxkIG5vZGUsIGNyZWF0ZQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgYSBjaGlsZCBub2RlIHdpdGggdGhlIGZvbGxvd2luZyB2YWx1
ZXM6IHNldA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHZhbGlkX3BvbGljeSB0byB0
aGUgdmFsdWUgZnJvbSB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4cGVjdGVkX3Bv
bGljeV9zZXQgaW4gdGhlIHBhcmVudCBub2RlOyBzZXQNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHRoZSBxdWFsaWZpZXJfc2V0IHRvIEFQLVEsIGFuZCBzZXQgdGhlDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICBleHBlY3RlZF9wb2xpY3lfc2V0IHRvIHRoZSB2YWx1ZSBpbiB0aGUNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHZhbGlkX3BvbGljeSBmcm9tIHRoaXMgbm9kZS4NCg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgW0ZvciBleGFtcGxlLCBjb25zaWRlciBhIHZhbGlk
X3BvbGljeV90cmVlDQogICAgICAgICAgICAgICAgICAgICAgICAgICB3aXRoIGEgbm9kZSBvZiBk
ZXB0aCBpLTEgd2hlcmUgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICBleHBlY3RlZF9w
b2xpY3lfc2V0ID0ge0dvbGQsIFNpbHZlcn0uICBBc3N1bWUNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgIJNhbnktcG9saWN5lCBhcHBlYXJzIGluIHRoZSBjZXJ0aWZpY2F0ZQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgcG9saWNpZXMgZXh0ZW5zaW9uIG9mIGNlcnRpZmljYXRlIGksIGJ1
dCBHb2xkDQogICAgICAgICAgICAgICAgICAgICAgICAgICBhbmQgU2lsdmVyIGRvIG5vdC4gIFRo
aXMgcnVsZSB3aWxsIGdlbmVyYXRlDQogICAgICAgICAgICAgICAgICAgICAgICAgICB0d28gY2hp
bGQgbm9kZXMgb2YgZGVwdGggaSwgb25lIGZvciBlYWNoDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICBwb2xpY3kuICBUaGUgcmVzdWx0IGlzIHNob3duIGJlbG93IGFzIEZpZ3VyZQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgNi5dDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfCAgICAgIFJlZCAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB8ICAgICAgIHt9ICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfCBub2RlIG9mIGRlcHRoDQogICAgICAgICAg
ICAgICAgIGktMQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICBG
QUxTRSAgICAgIHwNCgwNCg0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHwgICAgICAgUmVkICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfCAgICAgICB7fSAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwgICBub2RlIG9mIGRlcHRoDQogICAgICAgICAg
ICAgICAgIGktMQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICBG
QUxTRSAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8LS0tLS0t
LS0tLS0tLS0tLS18DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAge0dv
bGQsIFdoaXRlfSAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS0t
LS0tLS0tLS0tLS0tLXwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICBHb2xkICAgICAgIHwNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB7fSAgICAgICAgfA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwgbm9kZSBvZiBkZXB0
aCBpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgdW5pbml0aWFsaXpl
ZCAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0t
LS0tLXwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICB7R29sZH0g
ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0t
LS0tLS0tfA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA0LiBQcm9jZXNz
aW5nIGFuIGV4YWN0IG1hdGNoDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIChpaSkgaWYg
dGhlcmUgd2FzIG5vIG1hdGNoIGluIHN0ZXAgKGkpIGFuZA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdGhlICB2YWxpZF9wb2xpY3lfdHJlZSBpbmNsdWRlcyBhIG5vZGUgb2YNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGRlcHRoIGktMSB3aXRoIHRoZSB2YWxpZCBwb2xpY3kgk2FueS1w
b2xpY3mULA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgZ2VuZXJhdGUgYSBjaGlsZCBub2Rl
IHdpdGggdGhlIGZvbGxvd2luZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsdWVzOiBz
ZXQgdGhlIHZhbGlkX3BvbGljeSB0byBPSUQtUDsgc2V0DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICB0aGUgcXVhbGlmaWVyX3NldCB0byBQLVEsIGFuZCBzZXQgdGhlDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICBleHBlY3RlZF9wb2xpY3lfc2V0IHRvIHtPSUQtUH0uDQoNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFtGb3IgZXhhbXBsZSwgY29uc2lkZXIgYSB2YWxpZF9wb2xpY3lf
dHJlZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgd2l0aCBhIG5vZGUgb2YgZGVwdGggaS0x
IHdoZXJlIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsaWRfcG9saWN5IGlzIJNh
bnktcG9saWN5lC4gIEFzc3VtZSB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGNlcnRp
ZmljYXRlIHBvbGljaWVzIEdvbGQgYW5kIFNpbHZlciBhcHBlYXINCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGluIHRoZSBjZXJ0aWZpY2F0ZSBwb2xpY2llcyBleHRlbnNpb24gb2YNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGNlcnRpZmljYXRlIGkuICBUaGUgR29sZCBwb2xpY3kgZG9l
cyBub3QgaGF2ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgYSBxdWFsaWZpZXIsIGJ1dCB0
aGUgU2lsdmVyIHBvbGljeSBoYXMgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICBxdWFs
aWZpZXIgUS1TaWx2ZXIuICBJZiBHb2xkIGFuZCBTaWx2ZXIgd2VyZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgbm90IG1hdGNoZWQgaW4gKGkpIGFib3ZlLCB0aGlzIHJ1bGUgd2lsbA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgZ2VuZXJhdGUgdHdvIGNoaWxkIG5vZGVzIG9mIGRlcHRo
IGksIG9uZSBmb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGVhY2ggcG9saWN5LiAgVGhl
IHJlc3VsdCBpcyBzaG93biBhcyBGaWd1cmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIDUu
XQ0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0t
LS0tLS18DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgk2FueS1wb2xp
Y3mUICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0t
LS0tLS0tLXwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHt9
ICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0t
LS0tLS0tLS0tfCBub2RlIG9mIGRlcHRoDQogICAgICAgICAgICAgICAgIGktMQ0KDA0KDQoNCg0K
DQoNCg0KICAgICAgICAgICAgICAgICAgICAgICg0KSB0aGUgY2VydGlmaWNhdGUgaXNzdWVyIG5h
bWUgaXMgdGhlDQogICAgICAgICAgICAgICAgICAgICAgd29ya2luZ19pc3N1ZXJfbmFtZSwgYW5k
DQoNCiAgICAgICAgICAgICAgICAgICAgICAoNSkgdGhlIGNlcnRpZmljYXRlIGlzc3VlciB1bmlx
dWUgaWRlbnRpZmllciBpcw0KICAgICAgICAgICAgICAgICAgICAgIHRoZSB3b3JraW5nX2lzc3Vl
cl9VSUQsIG1lYW5pbmc6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAoaSkgd29ya2luZ19p
c3N1ZXJfVUlEIGlzIG5vbi1udWxsIGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgbWF0
Y2hlcyB0aGUgdmFsdWUgaW4gdGhlIGlzc3VlclVJRCBmaWVsZCwgb3INCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIChpaSkgd29ya2luZ19pc3N1ZXJfVUlEIGlzIG51bGwgYW5kIHRoZQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgaXNzdWVyVUlEIGZpZWxkIGlzIG5vdCBwcmVzZW50Lg0K
DQogICAgICAgICAgICAgICAgIChiKSBJZiBjZXJ0aWZpY2F0ZSBpIGlzIG5vdCBzZWxmLWlzc3Vl
ZCwgdmVyaWZ5IHRoYXQNCiAgICAgICAgICAgICAgICAgdGhlIHN1YmplY3QgbmFtZSBpcyB3aXRo
aW4gb25lIG9mIHRoZQ0KICAgICAgICAgICAgICAgICBwZXJtaXR0ZWRfc3VidHJlZXMgZm9yIFgu
NTAwIGRpc3Rpbmd1aXNoZWQgbmFtZXMsIGFuZA0KICAgICAgICAgICAgICAgICB2ZXJpZnkgdGhh
dCBlYWNoIG9mIHRoZSBhbHRlcm5hdGl2ZSBuYW1lcyBpbiB0aGUNCiAgICAgICAgICAgICAgICAg
c3ViamVjdEFsdE5hbWUgZXh0ZW5zaW9uIChjcml0aWNhbCBvciBub25jcml0aWNhbCkgaXMNCiAg
ICAgICAgICAgICAgICAgd2l0aGluIG9uZSBvZiB0aGUgcGVybWl0dGVkX3N1YnRyZWVzIGZvciB0
aGF0IG5hbWUNCiAgICAgICAgICAgICAgICAgdHlwZS4NCg0KICAgICAgICAgICAgICAgICAoYykg
SWYgY2VydGlmaWNhdGUgaSBpcyBub3Qgc2VsZi1pc3N1ZWQsIHZlcmlmeSB0aGF0DQogICAgICAg
ICAgICAgICAgIHRoZSBzdWJqZWN0IG5hbWUgaXMgbm90IHdpdGhpbiBvbmUgb2YgdGhlDQogICAg
ICAgICAgICAgICAgIGV4Y2x1ZGVkX3N1YnRyZWVzIGZvciBYLjUwMCBkaXN0aW5ndWlzaGVkIG5h
bWVzLCBhbmQNCiAgICAgICAgICAgICAgICAgdmVyaWZ5IHRoYXQgZWFjaCBvZiB0aGUgYWx0ZXJu
YXRpdmUgbmFtZXMgaW4gdGhlDQogICAgICAgICAgICAgICAgIHN1YmplY3RBbHROYW1lIGV4dGVu
c2lvbiAoY3JpdGljYWwgb3Igbm9uY3JpdGljYWwpIGlzDQogICAgICAgICAgICAgICAgIG5vdCB3
aXRoaW4gb25lIG9mIHRoZSBleGNsdWRlZF9zdWJ0cmVlcyBmb3IgdGhhdCBuYW1lDQogICAgICAg
ICAgICAgICAgIHR5cGUuDQoNCiAgICAgICAgICAgICAgICAgKGQpIGlmIHRoZSBjZXJ0aWZpY2F0
ZSBwb2xpY2llcyBleHRlbnNpb24gaXMgcHJlc2VudCBpbg0KICAgICAgICAgICAgICAgICB0aGUg
Y2VydGlmaWNpYXRlIGFuZCB0aGUgdmFsaWRfcG9saWN5X3RyZWUgaXMgbm90IE5VTEwsDQogICAg
ICAgICAgICAgICAgIHByb2Nlc3MgdGhlIHBvbGljeSBpbmZvcm1hdGlvbiBieSBwZXJmb3JtaW5n
IHRoZQ0KICAgICAgICAgICAgICAgICBmb2xsb3dpbmcgc3RlcHMgaW4gb3JkZXI6DQoNCiAgICAg
ICAgICAgICAgICAgICAgICAoMSkgZm9yIGVhY2ggcG9saWN5IFAgbm90IGVxdWFsIHRvIJNhbnkt
cG9saWN5lA0KICAgICAgICAgICAgICAgICAgICAgIHdpdGggdGhlIE9JRCB3aG9zZSB2YWx1ZSBp
cyBPSUQtUCBhbmQgdGhlDQogICAgICAgICAgICAgICAgICAgICAgcXVhbGlmaWVyIHNldCBkZW5v
dGVkIFAtUSBpbiB0aGUgY2VydGlmaWNhdGUNCiAgICAgICAgICAgICAgICAgICAgICBwb2xpY2ll
cyBleHRlbnNpb246DQogICAgICAgICAgICAgICAgICAgICAgICAgICAoaSkgaWYgdGhlIHZhbGlk
X3BvbGljeV90cmVlIGluY2x1ZGVzIGEgbm9kZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
b2YgZGVwdGggaS0xIHdoZXJlIE9JRC1QIGlzIGluIHRoZQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgZXhwZWN0ZWRfcG9saWN5X3NldCwgY3JlYXRlIGEgY2hpbGQgbm9kZSBhcw0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZm9sbG93czogc2V0IHRoZSB2YWxpZF9wb2xpY3kgdG8gT0lE
LVA7IHNldA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHF1YWxpZmllcl9zZXQgdG8g
UC1RLCBhbmQgc2V0IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgZXhwZWN0ZWRfcG9s
aWN5X3NldCB0byB7T0lELVB9Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICBbRm9yIGV4
YW1wbGUsIGNvbnNpZGVyIGEgdmFsaWRfcG9saWN5X3RyZWUNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHdpdGggYSBub2RlIG9mIGRlcHRoIGktMSB3aGVyZSB0aGUNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGV4cGVjdGVkX3BvbGljeV9zZXQgaXMge0dvbGQsIFdoaXRlfS4gIEFzc3Vt
ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGNlcnRpZmljYXRlIHBvbGljaWVzIEdv
bGQgYW5kIFNpbHZlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgYXBwZWFyIGluIHRoZSBj
ZXJ0aWZpY2F0ZSBwb2xpY2llcyBleHRlbnNpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
IG9mIGNlcnRpZmljYXRlIGkuICBUaGUgR29sZCBwb2xpY3kgaXMgbWF0Y2hlZA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgYnV0IHRoZSBTaWx2ZXIgcG9saWN5IGlzIG5vdC4gIFRoaXMgcnVs
ZSB3aWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICBnZW5lcmF0ZSBhIGNoaWxkIG5vZGUg
b2YgZGVwdGggaSBmb3IgdGhlIEdvbGQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHBvbGlj
eS4gVGhlIHJlc3VsdCBpcyBzaG93biBhcyBGaWd1cmUgNC5dDQoMDQoNCg0KDQoNCg0KICAgICAg
ICAgICAgICAgICBpcyBpbml0aWFsaXplZCBmcm9tIHRoZSB0cnVzdGVkIHB1YmxpYyBrZXkgcHJv
dmlkZWQgaW4NCiAgICAgICAgICAgICAgICAgdGhlIHRydXN0IGFuY2hvciBpbmZvcm1hdGlvbi4N
Cg0KICAgICAgICAgICAgICAgICAoaSkgd29ya2luZ19wdWJsaWNfa2V5X3BhcmFtZXRlcnM6ICBw
YXJhbWV0ZXJzDQogICAgICAgICAgICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgY3VycmVudCBw
dWJsaWMga2V5LCB0aGF0IG1heQ0KICAgICAgICAgICAgICAgICByZXF1aXJlZCB0byB2ZXJpZnkg
YSBzaWduYXR1cmUgKGRlcGVuZGluZyB1cG9uIHRoZQ0KICAgICAgICAgICAgICAgICBhbGdvcml0
aG0pLiAgVGhlIHdvcmtpbmdfcHVibGljX2tleV9wYXJhbWV0ZXJzIHZhcmlhYmxlDQogICAgICAg
ICAgICAgICAgIGlzIGluaXRpYWxpemVkIGZyb20gdGhlIHRydXN0ZWQgcHVibGljIGtleSBwYXJh
bWV0ZXJzDQogICAgICAgICAgICAgICAgIHByb3ZpZGVkIGluIHRoZSB0cnVzdCBhbmNob3IgaW5m
b3JtYXRpb24uICBJZg0KICAgICAgICAgICAgICAgICBwcm9jZXNzaW5nIGlzIGluaXRpYWxpemVk
IGZyb20gYSBzZWxmLXNpZ25lZA0KICAgICAgICAgICAgICAgICBjZXJ0aWZpY2F0ZSwgdGhlIHdv
cmtpbmdfcHVibGljX2tleV9wYXJhbWV0ZXJzIHZhcmlhYmxlDQogICAgICAgICAgICAgICAgIGlz
IGluaXRpYWxpemVkIGZyb20gdGhlIHBhcmFtZXRlcnMgZmllbGQgb2YgdGhlIHN1YmplY3QNCiAg
ICAgICAgICAgICAgICAgcHVibGljIGtleS4NCg0KICAgICAgICAgICAgICAgICAoaikgd29ya2lu
Z19pc3N1ZXJfbmFtZTogIHRoZSBpc3N1ZXIgZGlzdGluZ3Vpc2hlZCBuYW1lDQogICAgICAgICAg
ICAgICAgIGV4cGVjdGVkIGluIHRoZSBuZXh0IGNlcnRpZmljYXRlIGluIHRoZSBjaGFpbi4gIFRo
ZQ0KICAgICAgICAgICAgICAgICB3b3JraW5nX2lzc3Vlcl9uYW1lIGlzIGluaXRpYWxpemVkIHRv
IHRoZSB0cnVzdGVkDQogICAgICAgICAgICAgICAgIGlzc3VlciBwcm92aWRlZCBpbiB0aGUgdHJ1
c3QgYW5jaG9yIGluZm9ybWF0aW9uLg0KDQogICAgICAgICAgICAgICAgIChrKSB3b3JraW5nX2lz
c3Vlcl9VSUQ6IGEgZGlzdGluZ3Vpc2hlZCBuYW1lIG1heSBiZQ0KICAgICAgICAgICAgICAgICBh
c3NvY2lhdGVkIHdpdGggYW4gb3B0aW9uYWwgdW5pcXVlIGlkZW50aWZpZXIuICBUaGUNCiAgICAg
ICAgICAgICAgICAgd29ya2luZ19pc3N1ZXJfVUlEIGlzIHRoZSB1bmlxdWUgaWRlbnRpZmllciB0
aGF0IGlzDQogICAgICAgICAgICAgICAgIGV4cGVjdGVkIGluIHRoZSBuZXh0IGNlcnRpZmljYXRl
LCBvciB0aGUgdmFsdWUgTlVMTC4NCiAgICAgICAgICAgICAgICAgVGhlIHdvcmtpbmdfaXNzdWVy
X1VJRCBpcyBpbml0aWFsaXplZCB0byB0aGUgdHJ1c3RlZA0KICAgICAgICAgICAgICAgICBpc3N1
ZXKScyB1bmlxdWUgaWRlbnRpZmllciBwcm92aWRlZCBpbiB0aGUgdHJ1c3QgYW5jaG9yDQogICAg
ICAgICAgICAgICAgIGluZm9ybWF0aW9uLg0KDQogICAgICAgICAgICAgICAgIChsKSBtYXhfcGF0
aF9sZW5ndGg6ICB0aGlzIGludGVnZXIgaXMgaW5pdGlhbGl6ZWQgdG8gbiwNCiAgICAgICAgICAg
ICAgICAgYW5kIGlzIHJlc2V0IGJ5IHRoZSBwYXRoIGxlbmd0aCBjb25zdHJhaW50IGZpZWxkIG9m
IGENCiAgICAgICAgICAgICAgICAgQ0EgY2VydGlmaWNhdGUuDQoNCiAgICAgICAgICAgIFVwb24g
Y29tcGxldGlvbiBvZiB0aGUgaW5pdGlhbGl6YXRpb24gc3RlcHMsIHBlcmZvcm0gdGhlDQogICAg
ICAgICAgICBiYXNpYyBjZXJ0aWZpY2F0ZSBwcm9jZXNzaW5nIHN0ZXBzIHNwZWNpZmllZCBpbiA2
LjEuMy4NCg0KICAgICAgICAgICAgIA0gICAgICAgICAgICA2IA0gICAgICAgICAgICAgLjENICAg
ICAgICAgICAgICAgIA0gICAgICAgICAgICAgICAuIA0gICAgICAgICAgICAgICAgMyANICAgICAg
ICAgICAgICAgICAgQg0gICAgICAgICAgICAgICAgICAgIA0gICAgICAgICAgICAgICAgICAgYSAN
ICAgICAgICAgICAgICAgICAgICBzIA0gICAgICAgICAgICAgICAgICAgICBpIA0gICAgICAgICAg
ICAgICAgICAgICAgYyANICAgICAgICAgICAgICAgICAgICAgICAgQw0gICAgICAgICAgICAgICAg
ICAgICAgICAgIA0gICAgICAgICAgICAgICAgICAgICAgICAgZXINICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIA0gICAgICAgICAgICAgICAgICAgICAgICAgICB0IA0gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgaWYNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaQ0gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgYw0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhdA0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIA0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZSANICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUA0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIA0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgciANICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvYw0gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcw0gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgaW4NICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZw0K
DQogICAgICAgICAgICBUaGUgYmFzaWMgcGF0aCBwcm9jZXNzaW5nIGFjdGlvbnMgdG8gYmUgcGVy
Zm9ybWVkIGZvcg0KICAgICAgICAgICAgY2VydGlmaWNhdGUgaSBhcmUgbGlzdGVkIGJlbG93Lg0K
DQogICAgICAgICAgICAgICAgIChhKSBWZXJpZnkgdGhlIGJhc2ljIGNlcnRpZmljYXRlIGluZm9y
bWF0aW9uLA0KICAgICAgICAgICAgICAgICBpbmNsdWRpbmc6DQoNCiAgICAgICAgICAgICAgICAg
ICAgICAoMSkgdGhlIGNlcnRpZmljYXRlIHdhcyBzaWduZWQgd2l0aCB0aGUNCiAgICAgICAgICAg
ICAgICAgICAgICB3b3JraW5nX3B1YmxpY19rZXlfYWxnb3JpdGhtIHVzaW5nIHRoZQ0KICAgICAg
ICAgICAgICAgICAgICAgIHdvcmtpbmdfcHVibGljX2tleSBhbmQgdGhlDQogICAgICAgICAgICAg
ICAgICAgICAgd29ya2luZ19wdWJsaWNfa2V5X3BhcmFtZXRlcnMsDQoNCiAgICAgICAgICAgICAg
ICAgICAgICAoMikgdGhlIGNlcnRpZmljYXRlIHZhbGlkaXR5IHBlcmlvZCBpbmNsdWRlcyB0aW1l
DQogICAgICAgICAgICAgICAgICAgICAgVCwNCg0KICAgICAgICAgICAgICAgICAgICAgICgzKSBB
dCB0aW1lIFQsIHRoZSBjZXJ0aWZpY2F0ZSBpcyBub3QgcmV2b2tlZCBhbmQNCiAgICAgICAgICAg
ICAgICAgICAgICBpcyBub3Qgb24gaG9sZCBzdGF0dXMsICh0aGlzIG1heSBiZSBkZXRlcm1pbmVk
IGJ5DQogICAgICAgICAgICAgICAgICAgICAgb2J0YWluaW5nIHRoZSBhcHByb3ByaWF0ZSBDUkwg
W3NlZSBzZWN0aW9uIDYuWF0gb3INCiAgICAgICAgICAgICAgICAgICAgICBzdGF0dXMgaW5mb3Jt
YXRpb24sIG9yIGJ5IG91dC1vZi1iYW5kIG1lY2hhbmlzbXMpLA0KDA0KDQoNCg0KDQoNCiAgICAg
ICAgICAgICAgICAgYWxsIERpc3Rpbmd1aXNoZWQgbmFtZXM7IHRoZSBpbml0aWFsIHZhbHVlIGZv
ciB0aGUgc2V0DQogICAgICAgICAgICAgICAgIG9mIFJGQzgyMiBuYW1lcyBpcyB0aGUgc2V0IG9m
IGFsbCBSRkM4MjIgbmFtZXMsIGV0Yy4NCg0KICAgICAgICAgICAgICAgICAoYykgZXhjbHVkZWRf
c3VidHJlZXM6ICBBIHNldCBvZiByb290IG5hbWVzIGZvciBlYWNoDQogICAgICAgICAgICAgICAg
IG5hbWUgdHlwZSAgKGUuZy4sIFguNTAwIGRpc3Rpbmd1aXNoZWQgbmFtZXMsIGVtYWlsDQogICAg
ICAgICAgICAgICAgIGFkZHJlc3Nlcywgb3IgaXAgYWRkcmVzc2VzKSBkZWZpbmluZyBhIHNldCBv
ZiBzdWJ0cmVlcw0KICAgICAgICAgICAgICAgICB3aXRoaW4gd2hpY2ggbm8gc3ViamVjdCBuYW1l
IGluIHN1YnNlcXVlbnQgY2VydGlmaWNhdGVzDQogICAgICAgICAgICAgICAgIGluIHRoZSBjZXJ0
aWZpY2F0aW9uIHBhdGggbWF5IGZhbGwuIFRoaXMgdmFyaWFibGUNCiAgICAgICAgICAgICAgICAg
aW5jbHVkZXMgYSBzZXQgZm9yIGVhY2ggbmFtZSB0eXBlLCBhbmQgaXRzIGluaXRpYWwNCiAgICAg
ICAgICAgICAgICAgdmFsdWUgaXMgImVtcHR5Ii4NCg0KICAgICAgICAgICAgICAgICAoZCkgZXhw
bGljaXRfcG9saWN5OiBhbiBpbnRlZ2VyIHdoaWNoIGluZGljYXRlcyBpZiBhDQogICAgICAgICAg
ICAgICAgIG5vbi1OVUxMIHZhbGlkX3BvbGljeV90cmVlIGlzIHJlcXVpcmVkLiBUaGUgaW50ZWdl
cg0KICAgICAgICAgICAgICAgICBpbmRpY2F0ZXMgdGhlIG51bWJlciBvZiBub24tc2VsZi1pc3N1
ZWQgY2VydGlmaWNhdGVzIHRvDQogICAgICAgICAgICAgICAgIGJlIHByb2Nlc3NlZCBiZWZvcmUg
dGhpcyByZXF1aXJlbWVudCBpcyBpbXBvc2VkLiBPbmNlDQogICAgICAgICAgICAgICAgIHNldCwg
dGhpcyB2YXJpYWJsZSBtYXkgYmUgZGVjcmVhc2VkLCBidXQgbWF5IG5vdCBiZQ0KICAgICAgICAg
ICAgICAgICBpbmNyZWFzZWQuIChUaGF0IGlzLCBpZiBhIGNlcnRpZmljYXRlIGluIHRoZSBwYXRo
DQogICAgICAgICAgICAgICAgIHJlcXVpcmVzIGEgbm9uLU5VTEwgdmFsaWRfcG9saWN5X3RyZWUs
IGEgbGF0ZXINCiAgICAgICAgICAgICAgICAgY2VydGlmaWNhdGUgY2FuIG5vdCByZW1vdmUgdGhp
cyByZXF1aXJlbWVudC4pIElmDQogICAgICAgICAgICAgICAgIGluaXRpYWwtZXhwbGljaXQtcG9s
aWN5IGlzIHNldCB0aGVuIHRoZSBpbml0aWFsIHZhbHVlDQogICAgICAgICAgICAgICAgIGlzIDAs
IG90aGVyd2lzZSB0aGUgaW5pdGlhbCB2YWx1ZSBpcyBuKzEuDQoNCiAgICAgICAgICAgICAgICAg
KGUpIGluaGliaXRfYW55LXBvbGljeTogYW4gaW50ZWdlciB3aGljaCBpbmRpY2F0ZXMNCiAgICAg
ICAgICAgICAgICAgd2hldGhlciB0aGUgk2FueS1wb2xpY3mUIHBvbGljeSBpZGVudGlmaWVyIGlz
DQogICAgICAgICAgICAgICAgIGNvbnNpZGVyZWQgYSBtYXRjaC4gVGhlIGludGVnZXIgaW5kaWNh
dGVzIHRoZSBudW1iZXIgb2YNCiAgICAgICAgICAgICAgICAgbm9uLXNlbGYtaXNzdWVkIGNlcnRp
ZmljYXRlcyB0byBiZSBwcm9jZXNzZWQgYmVmb3JlIHRoZQ0KICAgICAgICAgICAgICAgICCTYW55
LXBvbGljeZQgT0lELCBpZiBhc3NlcnRlZCBpbiBhIGNlcnRpZmljYXRlLCBpcw0KICAgICAgICAg
ICAgICAgICBpZ25vcmVkLiBPbmNlIHNldCwgdGhpcyB2YXJpYWJsZSBtYXkgYmUgZGVjcmVhc2Vk
LCBidXQNCiAgICAgICAgICAgICAgICAgbWF5IG5vdCBiZSBpbmNyZWFzZWQuIChUaGF0IGlzLCBp
ZiBhIGNlcnRpZmljYXRlIGluIHRoZQ0KICAgICAgICAgICAgICAgICBwYXRoIGluaGliaXRzIHBy
b2Nlc3Npbmcgb2Ygk2FueS1wb2xpY3mULCBhIGxhdGVyDQogICAgICAgICAgICAgICAgIGNlcnRp
ZmljYXRlIGNhbiBub3QgcGVybWl0IGl0LikgSWYgaW5pdGlhbC1hbnktcG9saWN5LQ0KICAgICAg
ICAgICAgICAgICBpbmhpYml0IGlzIHNldCB0aGVuIHRoZSBpbml0aWFsIHZhbHVlIGlzIDAsIG90
aGVyd2lzZQ0KICAgICAgICAgICAgICAgICB0aGUgaW5pdGlhbCB2YWx1ZSBpcyBuKzEuDQoNCiAg
ICAgICAgICAgICAgICAgKGYpIHBvbGljeV9tYXBwaW5nOiBhbiBpbnRlZ2VyIHdoaWNoIGluZGlj
YXRlcyBpZg0KICAgICAgICAgICAgICAgICBwb2xpY3kgbWFwcGluZyBpcyBwZXJtaXR0ZWQuICBU
aGUgaW50ZWdlciBpbmRpY2F0ZXMgdGhlDQogICAgICAgICAgICAgICAgIG51bWJlciBvZiBub24t
c2VsZi1pc3N1ZWQgY2VydGlmaWNhdGVzIHRvIGJlIHByb2Nlc3NlZA0KICAgICAgICAgICAgICAg
ICBiZWZvcmUgcG9saWN5IG1hcHBpbmcgaXMgaW5oaWJpdGVkLiAgT25jZSBzZXQsIHRoaXMNCiAg
ICAgICAgICAgICAgICAgdmFyaWFibGUgbWF5IGJlIGRlY3JlYXNlZCwgYnV0IG1heSBub3QgYmUg
aW5jcmVhc2VkLg0KICAgICAgICAgICAgICAgICAoVGhhdCBpcywgaWYgYSBjZXJ0aWZpY2F0ZSBp
biB0aGUgcGF0aCBzcGVjaWZpZXMgcG9saWN5DQogICAgICAgICAgICAgICAgIG1hcHBpbmcgaXMg
bm90IHBlcm1pdHRlZCwgaXQgY2FuIG5vdCBiZSBvdmVycmlkZGVuIGJ5IGENCiAgICAgICAgICAg
ICAgICAgbGF0ZXIgY2VydGlmaWNhdGUuKSBJZiBpbml0aWFsLXBvbGljeS1tYXBwaW5nLWluaGli
aXQNCiAgICAgICAgICAgICAgICAgaXMgc2V0IHRoZW4gdGhlIGluaXRpYWwgdmFsdWUgaXMgMCwg
b3RoZXJ3aXNlIHRoZQ0KICAgICAgICAgICAgICAgICBpbml0aWFsIHZhbHVlIGlzIG4rMS4NCg0K
ICAgICAgICAgICAgICAgICAoZykgd29ya2luZ19wdWJsaWNfa2V5X2FsZ29yaXRobTogdGhlIGRp
Z2l0YWwgc2lnbmF0dXJlDQogICAgICAgICAgICAgICAgIGFsZ29yaXRobSB1c2VkIHRvIHZlcmlm
eSB0aGUgc2lnbmF0dXJlIG9mIGENCiAgICAgICAgICAgICAgICAgY2VydGlmaWNhdGUuICBUaGUg
d29ya2luZ19wdWJsaWNfa2V5X2FsZ29yaXRobSBpcw0KICAgICAgICAgICAgICAgICBpbml0aWFs
aXplZCBmcm9tIHRoZSB0cnVzdGVkIHB1YmxpYyBrZXkgYWxnb3JpdGhtDQogICAgICAgICAgICAg
ICAgIHByb3ZpZGVkIGluIHRoZSB0cnVzdCBhbmNob3IgaW5mb3JtYXRpb24uDQoNCiAgICAgICAg
ICAgICAgICAgKGgpIHdvcmtpbmdfcHVibGljX2tleTogdGhlIHB1YmxpYyBrZXkgdXNlZCB0byB2
ZXJpZnkNCiAgICAgICAgICAgICAgICAgdGhlIHNpZ25hdHVyZSBvZiBhIGNlcnRpZmljYXRlLiAg
VGhlIHdvcmtpbmdfcHVibGljX2tleQ0KDA0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgY2Vy
dGlmaWNhdGlvbiBwYXRoIHZhbGlkYXRpb24sIHRoZSB0cmVlIGlzIHNldCB0byBOVUxMLg0KICAg
ICAgICAgICAgICAgICBPbmNlIHRoZSB0cmVlIGlzIHNldCB0byBOVUxMLCBwb2xpY3kgcHJvY2Vz
c2luZyBjZWFzZXMuDQoNCiAgICAgICAgICAgICAgICAgRWFjaCBub2RlIGluIHRoZSB2YWxpZF9w
b2xpY3lfdHJlZSBpbmNsdWRlcyBmb3VyIGRhdGENCiAgICAgICAgICAgICAgICAgb2JqZWN0czog
dGhlIHZhbGlkIHBvbGljeSwgYSBzZXQgb2YgYXNzb2NpYXRlZCBwb2xpY3kNCiAgICAgICAgICAg
ICAgICAgcXVhbGlmaWVycywgYSBzZXQgb2Ygb25lIG9yIG1vcmUgZXhwZWN0ZWQgcG9saWN5DQog
ICAgICAgICAgICAgICAgIHZhbHVlcywgYW5kIGEgY3JpdGljYWxpdHkgaW5kaWNhdG9yLiAgSWYg
dGhlIG5vZGUgaXMgYXQNCiAgICAgICAgICAgICAgICAgZGVwdGggeCwgdGhlIGNvbXBvbmVudHMg
b2YgdGhlIG5vZGUgaGF2ZSB0aGUgZm9sbG93aW5nDQogICAgICAgICAgICAgICAgIHNlbWFudGlj
czoNCiAgICAgICAgICAgICAgICAgICAgICAoaSkgVGhlIHZhbGlkX3BvbGljeSBpcyBhIHNpbmds
ZSBwb2xpY3kgT0lEDQogICAgICAgICAgICAgICAgICAgICAgcmVwcmVzZW50aW5nIGEgdmFsaWQg
cG9saWN5IGZvciB0aGUgcGF0aCBvZiBsZW5ndGgNCiAgICAgICAgICAgICAgICAgICAgICB4Lg0K
ICAgICAgICAgICAgICAgICAgICAgIChpaSkgVGhlIHF1YWxpZmllcl9zZXQgaXMgYSBzZXQgb2Yg
cG9saWN5DQogICAgICAgICAgICAgICAgICAgICAgcXVhbGlmaWVycyBhc3NvY2lhdGVkIHdpdGgg
dGhlIHZhbGlkIHBvbGljeSBpbg0KICAgICAgICAgICAgICAgICAgICAgIGNlcnRpZmljYXRlIHgu
DQogICAgICAgICAgICAgICAgICAgICAgKGlpaSkgVGhlIGNyaXRpY2FsaXR5X2luZGljYXRvciBp
bmRpY2F0ZXMgd2hldGhlcg0KICAgICAgICAgICAgICAgICAgICAgIHRoZSBjZXJ0aWZpY2F0ZSBw
b2xpY3kgZXh0ZW5zaW9uIGluIGNlcnRpZmljYXRlIHgNCiAgICAgICAgICAgICAgICAgICAgICB3
YXMgbWFya2VkIGFzIGNyaXRpY2FsLg0KICAgICAgICAgICAgICAgICAgICAgIChpdikgVGhlIGV4
cGVjdGVkX3BvbGljeV9zZXQgY29udGFpbnMgb25lIG9yIG1vcmUNCiAgICAgICAgICAgICAgICAg
ICAgICBwb2xpY3kgT0lEcyB0aGF0IHdvdWxkIHNhdGlzZnkgdGhpcyBwb2xpY3kgaW4gdGhlDQog
ICAgICAgICAgICAgICAgICAgICAgY2VydGlmaWNhdGUgeCsxLg0KDQogICAgICAgICAgICAgICAg
IFRoZSBpbml0aWFsIHZhbHVlIG9mIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSBpcyBhIHNpbmdsZQ0K
ICAgICAgICAgICAgICAgICBub2RlIHdpdGggdmFsaWRfcG9saWN5IJNhbnktcG9saWN5lCwgYW4g
ZW1wdHkNCiAgICAgICAgICAgICAgICAgcXVhbGlmaWVyX3NldCwgYW4gZXhwZWN0ZWRfcG9saWN5
X3NldCB3aXRoIHRoZSBzaW5nbGUNCiAgICAgICAgICAgICAgICAgdmFsdWUgk2FueS1wb2xpY3mU
LCBhbmQgYSBjcml0aWNhbGl0eV9pbmRpY2F0b3Igb2YNCiAgICAgICAgICAgICAgICAgRkFMU0Uu
ICBUaGlzIG5vZGUgaXMgY29uc2lkZXJlZCB0byBiZSBhdCBkZXB0aCB6ZXJvLg0KDQogICAgICAg
ICAgICAgICAgIEZpZ3VyZSAzIGlzIGEgZ3JhcGhpYyByZXByZXNlbnRhdGlvbiBvZiB0aGUgaW5p
dGlhbA0KICAgICAgICAgICAgICAgICBzdGF0ZSBvZiB0aGUgdmFsaWRfcG9saWN5X3RyZWUuICBB
ZGRpdGlvbmFsIGZpZ3VyZXMNCiAgICAgICAgICAgICAgICAgd2lsbCB1c2UgdGhpcyBmb3JtYXQg
dG8gZGVzY3JpYmUgY2hhbmdlcyBpbiB0aGUNCiAgICAgICAgICAgICAgICAgdmFsaWRfcG9saWN5
X3RyZWUgZHVyaW5nIHBhdGggcHJvY2Vzc2luZy4NCg0KICAgICAgICAgICAgICAgICAgIHwtLS0t
LS0tLS0tLS0tLS0tLXwNCiAgICAgICAgICAgICAgICAgICB8ICCTYW55LXBvbGljeZQgICB8ICAg
PC0tLS0gdmFsaWRfcG9saWN5DQogICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0t
fA0KICAgICAgICAgICAgICAgICAgIHwgICAgICAge30gICAgICAgIHwgICA8LS0tLSBxdWFsaWZp
ZXJfc2V0DQogICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfA0KICAgICAgICAg
ICAgICAgICAgIHwgICAgICBGQUxTRSAgICAgIHwgICA8LS0tLSBjcml0aWNhbGl0eV9pbmRpY2F0
b3INCiAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18DQogICAgICAgICAgICAg
ICAgICAgfCAge5NhbnktcG9saWN5lH0gfCAgIDwtLS0tIGV4cGVjdGVkX3BvbGljeV9zZXQNCiAg
ICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18DQoNCiAgICAgICAgICAgICAgICAg
RmlndXJlIDMuIEluaXRpYWwgdmFsdWUgb2YgdGhlIHZhbGlkX3BvbGljeV90cmVlIHN0YXRlDQog
ICAgICAgICAgICAgICAgIHZhcmlhYmxlDQoNCiAgICAgICAgICAgICAgICAgKGIpIHBlcm1pdHRl
ZF9zdWJ0cmVlczogIEEgc2V0IG9mIHJvb3QgbmFtZXMgZm9yIGVhY2gNCiAgICAgICAgICAgICAg
ICAgbmFtZSB0eXBlIChlLmcuLCBYLjUwMCBkaXN0aW5ndWlzaGVkIG5hbWVzLCBlbWFpbA0KICAg
ICAgICAgICAgICAgICBhZGRyZXNzZXMsIG9yIGlwIGFkZHJlc3NlcykgZGVmaW5pbmcgYSBzZXQg
b2Ygc3VidHJlZXMNCiAgICAgICAgICAgICAgICAgd2l0aGluIHdoaWNoIGFsbCBzdWJqZWN0IG5h
bWVzIGluIHN1YnNlcXVlbnQNCiAgICAgICAgICAgICAgICAgY2VydGlmaWNhdGVzIGluIHRoZSBj
ZXJ0aWZpY2F0aW9uIHBhdGggc2hhbGwgZmFsbC4gVGhpcw0KICAgICAgICAgICAgICAgICB2YXJp
YWJsZSBpbmNsdWRlcyBhIHNldCBmb3IgZWFjaCBuYW1lIHR5cGU6IHRoZSBpbml0aWFsDQogICAg
ICAgICAgICAgICAgIHZhbHVlIGZvciB0aGUgc2V0IGZvciBEaXN0aW5ndWlzaGVkIE5hbWVzIGlz
IHRoZSBzZXQgb2YNCgwNCg0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgKGMpIHVzZXJfaW5p
dGlhbF9wb2xpY3lfc2V0OiAgQSBzZXQgb2YgY2VydGlmaWNhdGUNCiAgICAgICAgICAgICAgICAg
cG9saWN5IGlkZW50aWZpZXJzIG5hbWluZyB0aGUgcG9saWNpZXMgdGhhdCBhcmUNCiAgICAgICAg
ICAgICAgICAgYWNjZXB0YWJsZSB0byB0aGUgY2VydGlmaWNhdGUgdXNlci4gVGhlDQogICAgICAg
ICAgICAgICAgIHVzZXJfaW5pdGlhbF9wb2xpY3lfc2V0IGhhcyB0aGUgc3BlY2lhbCB2YWx1ZSAi
YW55LQ0KICAgICAgICAgICAgICAgICBwb2xpY3kiIGlmIHRoZSB1c2VyIGlzIG5vdCBjb25jZXJu
ZWQgYWJvdXQgY2VydGlmaWNhdGUNCiAgICAgICAgICAgICAgICAgcG9saWN5Lg0KDQogICAgICAg
ICAgICAgICAgIChkKSB0cnVzdCBhbmNob3IgaW5mb3JtYXRpb24sIGRlc2NyaWJpbmcgYSBDQSB0
aGF0DQogICAgICAgICAgICAgICAgIHNlcnZlcyBhcyBhICJ0cnVzdCBhbmNob3IiIGZvciB0aGUg
Y2VydGlmaWNhdGlvbiBwYXRoLg0KICAgICAgICAgICAgICAgICBUaGUgdHJ1c3QgYW5jaG9yIGRl
c2NyaWJlcyB0aGUgY2VydGlmaWNhdGUgdXNlcpJzDQogICAgICAgICAgICAgICAgIJNtb3N0LXRy
dXN0ZWQgQ0GULiAgVGhlIHRydXN0IGFuY2hvciBpbmZvcm1hdGlvbg0KICAgICAgICAgICAgICAg
ICBpbmNsdWRlczoNCiAgICAgICAgICAgICAgICAgICAgICAoMSkgdGhlIHRydXN0ZWQgaXNzdWVy
IG5hbWUsDQogICAgICAgICAgICAgICAgICAgICAgKDIpIG9wdGlvbmFsbHksIHRoZSB0cnVzdGVk
IGlzc3VlciB1bmlxdWUNCiAgICAgICAgICAgICAgICAgICAgICBpZGVudGlmaWVyLA0KICAgICAg
ICAgICAgICAgICAgICAgICgzKSB0aGUgdHJ1c3RlZCBwdWJsaWMga2V5IGFsZ29yaXRobSwNCiAg
ICAgICAgICAgICAgICAgICAgICAoNCkgdGhlIHRydXN0ZWQgcHVibGljIGtleSwgYW5kDQogICAg
ICAgICAgICAgICAgICAgICAgKDUpIG9wdGlvbmFsbHksIHRoZSB0cnVzdGVkIHB1YmxpYyBrZXkg
cGFyYW1ldGVycw0KICAgICAgICAgICAgICAgICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgcHVi
bGljIGtleS4NCg0KICAgICAgICAgICAgICAgICBUaGUgdHJ1c3QgYW5jaG9yIGluZm9ybWF0aW9u
IG1heSBiZSBwcm92aWRlZCB0byB0aGUNCiAgICAgICAgICAgICAgICAgcGF0aCBwcm9jZXNzaW5n
IHByb2NlZHVyZSBpbiB0aGUgZm9ybSBvZiBhICJzZWxmLXNpZ25lZA0KICAgICAgICAgICAgICAg
ICBjZXJ0aWZpY2F0ZSIuICBUaGUgdHJ1c3RlZCBhbmNob3IgaW5mb3JtYXRpb24gaXMNCiAgICAg
ICAgICAgICAgICAgdHJ1c3RlZCBiZWNhdXNlIGl0IHdhcyBkZWxpdmVyZWQgdG8gdGhlIHBhdGgg
cHJvY2Vzc2luZw0KICAgICAgICAgICAgICAgICBwcm9jZWR1cmUgYnkgc29tZSB0cnVzdHdvcnRo
eSAib3V0LW9mLWJhbmQiIHByb2NlZHVyZS4NCiAgICAgICAgICAgICAgICAgSWYgdGhlIHRydXN0
ZWQgcHVibGljIGtleSBhbGdvcml0aG0gcmVxdWlyZXMNCiAgICAgICAgICAgICAgICAgcGFyYW1l
dGVycywgdGhlbiB0aGUgcGFyYW1ldGVycyBhcmUgcHJvdmlkZWQgYWxvbmcgd2l0aA0KICAgICAg
ICAgICAgICAgICB0aGUgdHJ1c3RlZCBwdWJsaWMga2V5Lg0KDQogICAgICAgICAgICAgICAgIChl
KSBpbml0aWFsLXBvbGljeS1tYXBwaW5nLWluaGliaXQsIHdoaWNoIGluZGljYXRlcyBpZg0KICAg
ICAgICAgICAgICAgICBwb2xpY3kgbWFwcGluZyBpcyBhbGxvd2VkIGluIHRoZSBjZXJ0aWZpY2F0
aW9uIHBhdGguDQoNCiAgICAgICAgICAgICAgICAgKGYpIGluaXRpYWwtZXhwbGljaXQtcG9saWN5
LCB3aGljaCBpbmRpY2F0ZXMgaWYgdGhlDQogICAgICAgICAgICAgICAgIHBhdGggbXVzdCBiZSB2
YWxpZCBmb3IgYXQgbGVhc3Qgb25lIG9mIHRoZSBjZXJ0aWZpY2F0ZQ0KICAgICAgICAgICAgICAg
ICBwb2xpY2llcyBpbiB0aGUgdXNlcl9pbml0aWFsX3BvbGljeV9zZXQuDQoNCiAgICAgICAgICAg
ICAgICAgKGcpIGluaXRpYWwtYW55LXBvbGljeS1pbmhpYml0LCB3aGljaCBpbmRpY2F0ZXMgd2hl
dGhlcg0KICAgICAgICAgICAgICAgICB0aGUgYW55LXBvbGljeSBPSUQgc2hvdWxkIGJlIHByb2Nl
c3NlZCBpZiBpdCBpcw0KICAgICAgICAgICAgICAgICBpbmNsdWRlZCBpbiBhIGNlcnRpZmljYXRl
Lg0KDQogICAgICAgICAgICAgDSAgICAgICAgICAgIDYgDSAgICAgICAgICAgICAuMQ0gICAgICAg
ICAgICAgICAgDSAgICAgICAgICAgICAgIC4gDSAgICAgICAgICAgICAgICAyIA0gICAgICAgICAg
ICAgICAgICBJDSAgICAgICAgICAgICAgICAgICAgDSAgICAgICAgICAgICAgICAgICBuaQ0gICAg
ICAgICAgICAgICAgICAgICB0DSAgICAgICAgICAgICAgICAgICAgICAgDSAgICAgICAgICAgICAg
ICAgICAgICBpIA0gICAgICAgICAgICAgICAgICAgICAgIGEgDSAgICAgICAgICAgICAgICAgICAg
ICAgIGwgDSAgICAgICAgICAgICAgICAgICAgICAgICBpeg0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgDSAgICAgICAgICAgICAgICAgICAgICAgICAgIGF0DSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgaQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvDSAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIG4NCg0KICAgICAgICAgICAgVGhlIGluaXRpYWxpemF0
aW9uIHBoYXNlIGVzdGFibGlzaGVzIHR3ZWx2ZSBzdGF0ZSB2YXJpYWJsZXMNCiAgICAgICAgICAg
IGJhc2VkIHVwb24gdGhlIHNldmVuIGlucHV0czoNCg0KICAgICAgICAgICAgICAgICAoYSkgdmFs
aWRfcG9saWN5X3RyZWU6ICBBIHRyZWUgb2YgY2VydGlmaWNhdGUgcG9saWNpZXMNCiAgICAgICAg
ICAgICAgICAgd2l0aCB0aGVpciBvcHRpb25hbCBxdWFsaWZpZXJzOyBlYWNoIG9mIHRoZSBsZWF2
ZXMgb2YNCiAgICAgICAgICAgICAgICAgdGhlIHRyZWUgcmVwcmVzZW50cyBhIHZhbGlkIHBvbGlj
eSBhdCB0aGlzIHN0YWdlIGluIHRoZQ0KICAgICAgICAgICAgICAgICBjZXJ0aWZpY2F0aW9uIHBh
dGggdmFsaWRhdGlvbi4gSWYgdmFsaWQgcG9saWNpZXMgZXhpc3QNCiAgICAgICAgICAgICAgICAg
YXQgdGhpcyBzdGFnZSBpbiB0aGUgY2VydGlmaWNhdGlvbiBwYXRoIHZhbGlkYXRpb24sIHRoZQ0K
ICAgICAgICAgICAgICAgICBkZXB0aCBvZiB0aGUgdHJlZSBpcyBlcXVhbCB0byB0aGUgbnVtYmVy
IG9mDQogICAgICAgICAgICAgICAgIGNlcnRpZmljYXRlcyBpbiB0aGUgY2hhaW4gdGhhdCBoYXZl
IGJlZW4gcHJvY2Vzc2VkLiBJZg0KICAgICAgICAgICAgICAgICB2YWxpZCBwb2xpY2llcyBkbyBu
b3QgZXhpc3QgYXQgdGhpcyBzdGFnZSBpbiB0aGUNCgwNCg0KDQoNCg0KDQoNCiAgICAgICAgICAg
IFRoaXMgc2VjdGlvbiBwcmVzZW50cyB0aGUgYWxnb3JpdGhtIGluIGZvdXIgYmFzaWMgc3RlcHM6
ICgxKQ0KICAgICAgICAgICAgaW5pdGlhbGl6YXRpb24sICgyKSBiYXNpYyBjZXJ0aWZpY2F0ZSBw
cm9jZXNzaW5nLCAoMykNCiAgICAgICAgICAgIHByZXBhcmF0aW9uIGZvciB0aGUgbmV4dCBjZXJ0
aWZpY2F0ZSwgYW5kICg0KSB3cmFwLXVwLg0KICAgICAgICAgICAgU3RlcHMgKDEpIGFuZCAoNCkg
YXJlIHBlcmZvcm1lZCBleGFjdGx5IG9uY2UuICBTdGVwICgyKSBpcw0KICAgICAgICAgICAgcGVy
Zm9ybWVkIGZvciBhbGwgY2VydGlmaWNhdGVzIGluIHRoZSBwYXRoLiAgU3RlcCAoMykgaXMNCiAg
ICAgICAgICAgIHBlcmZvcm1lZCBmb3IgYWxsIGNlcnRpZmljYXRlcyBpbiB0aGUgcGF0aCBleGNl
cHQgdGhlIGZpbmFsDQogICAgICAgICAgICBjZXJ0aWZpY2F0ZS4gIEZpZ3VyZSAyIHByb3ZpZGVz
IGEgaGlnaC1sZXZlbCBmbG93Y2hhcnQgb2YNCiAgICAgICAgICAgIHRoaXMgYWxnb3JpdGhtLg0K
DQogICAgICAgICAgICAgICAgICAgICAgICAgLy0tLS0tLS1cDQogICAgICAgICAgICAgICAgICAg
ICAgICAgfCBTVEFSVCB8DQogICAgICAgICAgICAgICAgICAgICAgICAgXC0tLS0tLS0vDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Vg0KICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAg
ICAgICAgICB8IEluaXRpYWxpemF0aW9uIHwNCiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t
LS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICs8LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAr
LS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICB8ICBQ
cm9jZXNzIENlcnQgIHwgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICArLS0tLS0t
LS0tLS0tLS0tLSsgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
ICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIFYgICAg
ICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICArPT09PT09PT09PT09PT09
PSsgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICB8ICBJRiBMYXN0IENlcnQgIHwg
ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICB8ICAgIGluIFBhdGggICAgIHwgICAg
ICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICArPT09PT09PT09PT09PT09PSsgICAgICAg
ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAg
ICB8DQogICAgICAgICAgICAgICAgICBUSEVOIHwgICAgICAgICAgICB8IEVMU0UgICAgICAgICB8
DQogICAgICAgICAgICAgICAgICAgICAgIFYgICAgICAgICAgICBWICAgICAgICAgICAgICB8DQog
ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgKy0tLS0tLS0tLS0tLS0tLS0rICB8DQogICAg
ICAgICAgICB8ICAgIFdyYXAgdXAgICAgIHwgfCAgUHJlcGFyZSBmb3IgICB8ICB8DQogICAgICAg
ICAgICArLS0tLS0tLS0tLS0tLS0tLSsgfCAgIE5leHQgQ2VydCAgICB8ICB8DQogICAgICAgICAg
ICAgICAgICAgIHwgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICB8DQogICAgICAgICAgICAg
ICAgICAgIFYgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAg
Ly0tLS0tLS1cICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgfCBT
VE9QICB8DQogICAgICAgICAgICAgICAgXC0tLS0tLS0vDQoNCiAgICAgICAgICAgIEZpZ3VyZSAy
LiAgUGF0aCBQcm9jZXNzaW5nIEZsb3djaGFydA0KDQogICAgICAgICAgICAgDSAgICAgICAgICAg
IDYgDSAgICAgICAgICAgICAuMQ0gICAgICAgICAgICAgICAgDSAgICAgICAgICAgICAgIC4gDSAg
ICAgICAgICAgICAgICAxIA0gICAgICAgICAgICAgICAgICBJDSAgICAgICAgICAgICAgICAgICAg
DSAgICAgICAgICAgICAgICAgICBucA0gICAgICAgICAgICAgICAgICAgICAgDSAgICAgICAgICAg
ICAgICAgICAgIHV0DSAgICAgICAgICAgICAgICAgICAgICAgDSAgICAgICAgICAgICAgICAgICAg
ICAgIA0gICAgICAgICAgICAgICAgICAgICAgIHMNCiAgICAgICAgICAgIFRoaXMgYWxnb3JpdGht
IGFzc3VtZXMgdGhlIGZvbGxvd2luZyBzZXZlbiBpbnB1dHMgYXJlDQogICAgICAgICAgICBwcm92
aWRlZCB0byB0aGUgcGF0aCBwcm9jZXNzaW5nIGxvZ2ljOg0KDQogICAgICAgICAgICAgICAgIChh
KSBhIHByb3NwZWN0aXZlIGNlcnRpZmljYXRpb24gcGF0aCBvZiBsZW5ndGggbjsNCg0KICAgICAg
ICAgICAgICAgICAoYikgdGhlIHRpbWUsIFQsIGZvciB3aGljaCB0aGUgdmFsaWRpdHkgb2YgdGhl
IHBhdGgNCiAgICAgICAgICAgICAgICAgc2hvdWxkIGJlIGRldGVybWluZWQuICAoVGhpcyBtYXkg
YmUgdGhlIGN1cnJlbnQNCiAgICAgICAgICAgICAgICAgZGF0ZS90aW1lLCBvciBzb21lIHBvaW50
IGluIHRoZSBwYXN0LikNCgwNCg0KDQoNCg0KDQoNCiAgICAgICAgICAgIDYuMSBCYXNpYyBQYXRo
IFZhbGlkYXRpb24NCg0KICAgICAgICAgICAgVGhpcyB0ZXh0IGRlc2NyaWJlcyBhbiBhbGdvcml0
aG0gZm9yIFguNTA5IHBhdGggcHJvY2Vzc2luZy4NCiAgICAgICAgICAgIEEgY29uZm9ybWFudCBp
bXBsZW1lbnRhdGlvbiBTSEFMTCBpbmNsdWRlIGFuIFguNTA5IHBhdGgNCiAgICAgICAgICAgIHBy
b2Nlc3NpbmcgcHJvY2VkdXJlIHRoYXQgaXMgZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQgdG8gdGhl
DQogICAgICAgICAgICBleHRlcm5hbCBiZWhhdmlvciBvZiB0aGlzIGFsZ29yaXRobS4NCg0KICAg
ICAgICAgICAgVGhpcyB0ZXh0IGFzc3VtZXMgdGhhdCB0aGVyZSBpcyBhIHNpbmdsZSB0cnVzdCBh
bmNob3IgZm9yDQogICAgICAgICAgICBjZXJ0aWZpY2F0aW9uIHBhdGggcHJvY2Vzc2luZywgd2hp
Y2ggc2ltcGxpZmllcyB0aGUNCiAgICAgICAgICAgIGRlc2NyaXB0aW9uIG9mIHRoZSBwYXRoIHBy
b2Nlc3NpbmcgcHJvY2VkdXJlLiBBcyBub3RlZA0KICAgICAgICAgICAgYWJvdmUsIHRoaXMgcHJv
Y2VkdXJlIGNhbiBiZSBleHRlbmRlZCB0byBhZGRyZXNzIG11bHRpcGxlDQogICAgICAgICAgICB0
cnVzdCBhbmNob3JzLiBUaGlzIGlzIGRpc2N1c3NlZCBmdXJ0aGVyIGluIFNlY3Rpb24gNi4yLg0K
DQogICAgICAgICAgICBBIGNlcnRpZmljYXRpb24gcGF0aCBpcyBhIHNlcXVlbmNlIG9mIG4gY2Vy
dGlmaWNhdGVzIHdoZXJlOg0KDQogICAgICAgICAgICAgICAgIGZvciBhbGwgeCBpbiB7MSwgLi4u
LCBuLTF9LCB0aGUgc3ViamVjdCBvZiBjZXJ0aWZpY2F0ZQ0KICAgICAgICAgICAgICAgICB4IGlz
IHRoZSBpc3N1ZXIgb2YgY2VydGlmaWNhdGUgeCsxOw0KDQogICAgICAgICAgICAgICAgIGNlcnRp
ZmljYXRlIDEgaXMgaXNzdWVkIGJ5IHRoZSB0cnVzdCBhbmNob3I7IGFuZA0KDQogICAgICAgICAg
ICAgICAgIGNlcnRpZmljYXRlIG4gaXMgdGhlIGVuZCBlbnRpdHkgY2VydGlmaWNhdGUuDQoNCiAg
ICAgICAgICAgIFRoZSBwcmltYXJ5IGdvYWwgb2YgcGF0aCB2YWxpZGF0aW9uIGlzIHRvIHZlcmlm
eSB0aGUgYmluZGluZw0KICAgICAgICAgICAgYmV0d2VlbiBhIHN1YmplY3QgZGlzdGluZ3Vpc2hl
ZCBuYW1lIG9yIHN1YmplY3QgYWx0ZXJuYXRpdmUNCiAgICAgICAgICAgIG5hbWUgYW5kIHN1Ympl
Y3QgcHVibGljIGtleSwgYXMgcmVwcmVzZW50ZWQgaW4gdGhlICJlbmQNCiAgICAgICAgICAgIGVu
dGl0eSIgY2VydGlmaWNhdGUsIGJhc2VkIG9uIHRoZSBwdWJsaWMga2V5IG9mIHRoZSAibW9zdC0N
CiAgICAgICAgICAgIHRydXN0ZWQgQ0EiLiAgVGhpcyByZXF1aXJlcyBvYnRhaW5pbmcgYSBzZXF1
ZW5jZSBvZg0KICAgICAgICAgICAgY2VydGlmaWNhdGVzIHRoYXQgc3VwcG9ydCB0aGF0IGJpbmRp
bmcuICBUaGUgcHJvY2VkdXJlDQogICAgICAgICAgICBwZXJmb3JtZWQgdG8gb2J0YWluIHRoaXMg
c2VxdWVuY2UgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YNCiAgICAgICAgICAgIHRoaXMgc2VjdGlv
bi4NCg0KICAgICAgICAgICAgVG8gbWVldCB0aGlzIGdvYWwsIHRoZSBwYXRoIHZhbGlkYXRpb24g
cHJvY2VzcyB2ZXJpZmllcywNCiAgICAgICAgICAgIGFtb25nIG90aGVyIHRoaW5ncywgdGhhdCBh
IHByb3NwZWN0aXZlIGNlcnRpZmljYXRpb24gcGF0aCAoYQ0KICAgICAgICAgICAgc2VxdWVuY2Ug
b2YgbiBjZXJ0aWZpY2F0ZXMpIHNhdGlzZmllcyB0aGUgZm9sbG93aW5nDQogICAgICAgICAgICBj
b25kaXRpb25zOg0KICAgICAgICAgICAgICAgICAoaSkgZm9yIGFsbCB4IGluIHsxLCAuLi4sIG4t
MX0sIHRoZSBzdWJqZWN0IG9mDQogICAgICAgICAgICAgICAgIGNlcnRpZmljYXRlIHggaXMgdGhl
IGlzc3VlciBvZiBjZXJ0aWZpY2F0ZSB4KzE7DQogICAgICAgICAgICAgICAgIChpaSkgY2VydGlm
aWNhdGUgMSBpcyBpc3N1ZWQgYnkgdGhlIHRydXN0IGFuY2hvcjsNCiAgICAgICAgICAgICAgICAg
KGlpaSkgY2VydGlmaWNhdGUgbiBpcyB0aGUgZW5kIGVudGl0eSBjZXJ0aWZpY2F0ZTsgYW5kDQog
ICAgICAgICAgICAgICAgIChpdikgZm9yIGFsbCB4IGluIHsxLCAuLi4sIG59LCB0aGUgY2VydGlm
aWNhdGUgd2FzDQogICAgICAgICAgICAgICAgIHZhbGlkIGF0IHRoZSB0aW1lIGluIHF1ZXN0aW9u
Lg0KDQogICAgICAgICAgICBBIHBhcnRpY3VsYXIgY2VydGlmaWNhdGlvbiBwYXRoIG1heSBub3Qs
IGhvd2V2ZXIsIGJlDQogICAgICAgICAgICBhcHByb3ByaWF0ZSBmb3IgYWxsIGFwcGxpY2F0aW9u
cy4gIFRoZSBwYXRoIHZhbGlkYXRpb24NCiAgICAgICAgICAgIHByb2Nlc3MgYWxzbyBkZXRlcm1p
bmVzIHRoZSBzZXQgb2YgY2VydGlmaWNhdGUgcG9saWNpZXMgdGhhdA0KICAgICAgICAgICAgYXJl
IHZhbGlkIGZvciB0aGlzIHBhdGgsIGJhc2VkIG9uIHRoZSBjZXJ0aWZpY2F0ZSBwb2xpY2llcw0K
ICAgICAgICAgICAgZXh0ZW5zaW9uLCBwb2xpY3kgbWFwcGluZyBleHRlbnNpb24sIHBvbGljeSBj
b25zdHJhaW50cw0KICAgICAgICAgICAgZXh0ZW5zaW9uLCBhbmQgaW5oaWJpdCBhbnktcG9saWN5
IGV4dGVuc2lvbi4gVG8gYWNoaWV2ZQ0KICAgICAgICAgICAgdGhpcywgdGhlIHBhdGggdmFsaWRh
dGlvbiBhbGdvcml0aG0gY29uc3RydWN0cyBhIJN2YWxpZA0KICAgICAgICAgICAgcG9saWN5IHRy
ZWWULiAgSWYgdGhlIHNldCBvZiBjZXJ0aWZpY2F0ZSBwb2xpY2llcyB0aGF0IGFyZQ0KICAgICAg
ICAgICAgdmFsaWQgZm9yIHRoaXMgcGF0aCBpcyBub3QgZW1wdHkgdGhlIHJlc3VsdCB3aWxsIGJl
IGEgdmFsaWQNCiAgICAgICAgICAgIHBvbGljeSB0cmVlIG9mIGRlcHRoIG4sIG90aGVyd2lzZSB0
aGUgcmVzdWx0IHdpbGwgYmUgYSBOVUxMDQogICAgICAgICAgICB2YWxpZCBwb2xpY3kgdHJlZS4N
Cgw=
--=====================_64037881==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

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



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA26695 for <[e-mail]>; Thu, 14 Oct 1999 13:10:42 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA25299; Thu, 14 Oct 1999 13:04:51 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 14 Oct 1999 16:08:13 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Y2K and Digital Certificates Article
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Bob:

Here is the first paragraph from an article you wrote:

You'd think that a new Internet standard would be free of Y2K problems. But 
if it has a legacy component, think again. Digital certificates have been 
around for a dozen years and in that time they've gone through three 
versions. We finally have an Internet Standard Profile (RFC 2459, Internet 
X.509 PKI Certificate, and Certificate Revocation List, collectively known 
as PKIX). But this new standard has a Y2K bomb that could go off 40 years 
from now--when it is well entrenched in our businesses.

I do not consider this a Y2K-like situation.  RFC 2459 clearly tells 
developers how to handle UTCTime and GeneralizedTime.  There is no ambiguity.

Russ




Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA25141 for <[e-mail]>; Thu, 14 Oct 1999 11:38:42 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id LAA14027; Thu, 14 Oct 1999 11:38:26 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA22569; Thu, 14 Oct 1999 11:40:13 -0700 (PDT)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SF5S3QZ8; Thu, 14 Oct 1999 11:40:16 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Scope of OCSP
Date: Thu, 14 Oct 1999 14:41:39 -0400
Message-ID: <004e01bf1673$c0b068e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

All,

	To give some explanation for the proposed scope of OCSPX.
As I see it there are two potential models for deployment of
PKI functionality.

1)	Fat PKIX aware Client supported by minimal server
		bringing together a data set.

2)	Thin client, PK aware but not PKI aware, supported by
		PKIX aware server.

	As members of the group are probably aware, my personal
prejudice is for approach (1). This is however a prejudice and
not an argument. There are many applications in which the
second approcah is more appropriate. These include wireless
applications and interactions with legacy mainframes.

	[I find the references to "Mobile IP" and such irrelevant.
It is taken as a given that in any situation in which a client
is relying on a server for trust decisions that an appropriately
secure protocol will be employed and that the client will ensure
that the data supplied is authentic, this requires only mutual
authentication however and not a PK INFRASTRUCTURE. I will make 
this more explicit in the security issues section of next draft.]

	I believe there are applications which will mandate 
particular approaches. My hypothesis is that there is _NO_ middle
ground. Whenever there is a need for a thin authentication client
a fat authorization client will be unacceptable.

	As I specifically state in the draft, there is a security
risk in delegation of trust path dicovery to a remote server. There
is an additional risk in delegation of trust path validation. There
is however no ADDITIONAL risk in then adding the authorization since
an attacker who can spoof authentication can spoof authorization by
simply spoofing the identity of a sufficiently priviledged individual.

	[Equally the 'risk' introduced by delegating trust path 
discovery is not that great since regardless of where the data is 
analyzed it must come from an outside source.]


	Issues of timing and venue are important, so much so that
I would hope to see a little more explanation of opinions than
"I don't believe the time is right". The time is never right in 
the IETF, there is always another group. 

	I don't think that the IETF process progresses at such a 
reckless pace that we need be affraid of putting out proposals
for fear that it is 'too soon'. I have customers who have expressed
a clear demand for the functionality described. If the problem
is complex and needs time to be worked on then the time to start 
is now. The only reason to wait would be if there was insufficient
experience of PKI deployment to understand the problems at this
point. This is certainly not the case where I sit.


	That said, if there is a clear consensus that there is
a clear need etc. for one subset of the OCSP-X functionality and
no consensus for the remainder it may be appropriate to write
two drafts, one on the proposed standard track and another on the
experimental. I would like to see reasons other than "thats not
the way I want to do it" and I would like to see specific references
to the draft before taking this approach however.


		Phill



Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4-ext.email.verio.net [129.250.36.44]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA23679 for <[e-mail]>; Thu, 14 Oct 1999 10:21:57 -0700 (PDT)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout4.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FJLSC200.AJP for <[e-mail]>; Thu, 14 Oct 1999 17:24:02 +0000 
Received: from nma.com ([209.21.28.85]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FJLSBO00.SRP; Thu, 14 Oct 1999 17:23:48 +0000 
Message-ID: <[e-mail]>
Date: Thu, 14 Oct 1999 10:24:01 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Phillip M Hallam-Baker <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Sentient applications, was Re: FW: OCSP-X  Internet Draft:  Extensions to OCSP
References: <003c01bf1659$c47eadc0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phillip M Hallam-Baker wrote:

> Ed,
>
>         The ability to use knowledge is not generally considered a
> sufficient requirement for sentience. Knowledge is simply information
> that can be used.

Not knowledge, but reasoning without data.

>         The language used would be appropriate if a human were
> performing the task, it is therefore appropriate if a machine replaces
> the human.

If what you say is true, then I move for us to apply it immediately to all
laws and get rid of all lawyers, now substituted by computers.

So, since that is not possible (yet?) your document would be better
appreciated, IMO, if it would allow the reader to use today's tools --
where one needs to replace vague human-based reasonings such as

 "For an application to make an informed decision as to whether it trusts a
  digital certificate"

with programmable assertions such as

 "For an application to decide whether a digital certificate is trusted, the
 application must be programmed with a trust metric, defined here to
  include, exclusively,"

which MUST include the trust metrics used for the decision, not only the
trust-points (certificate, signing key, etc.).  To do otherwise is to require
reasoning without data.

Also, I don't find it useful to remind us of the Church-Turing hypothesis as
explicit in your second paragraph, unless you also note that time and
memory space were not factors in that hypothesis.

Thus, exactly because I valued your text, I would suggest it should not require
infinite time and memory in order to be implemented.

Cheers,

Ed Gerck




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA23384 for <[e-mail]>; Thu, 14 Oct 1999 10:16:01 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA27432; Thu, 14 Oct 1999 13:18:31 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA27428; Thu, 14 Oct 1999 13:18:30 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA29305; Thu, 14 Oct 1999 13:17:48 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id NAA01046; Thu, 14 Oct 1999 13:14:43 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 14 Oct 1999 13:14:43 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: updated path validation text
To: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: MULTIPART/mixed; BOUNDARY=Singular_of_Boars_835_000
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

--Singular_of_Boars_835_000
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 94DPisCJhRl2F2K7b/xgiw==


Tim,

  Posting PDF is, I believe, a lesser sin than posting native Word  :-).
Attached is a portable version of the document.



> P.S.  Sorry about the Word attachment.  The straightforward conversion to
> text lost all the formatting/indenting , and I think that really helps the
> readers' comprehension.  If anyone asks, I will convert it to a nice UNIX
> text file and repost.  Otherwise, it will get fixed when I convert to
> nroff...

--Singular_of_Boars_835_000
Content-Type: APPLICATION/pdf; name="RevisedPathproc6c.pdf"; x-unix-mode=0644
Content-Transfer-Encoding: BASE64
Content-Description: RevisedPathproc6c.pdf
Content-MD5: BgSt2spDGrumJ85EMQG94g==

JVBERi0xLjIKJeLjz9MNCjIgMCBvYmoKPDwKL0xlbmd0aCAxMjk0Ci9GaWx0
ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSImkVk2T20QQvftXdO3JAVlr
eTe7bHJygABVKYpiBcXBl7E0siZIGqEZ2WsI/53XM5Isr5WkUtj7YWu6X3e/
/pqIIryb3ez6h8eIdmYW3dLiju6iFd0/rKiRs2z2Jp5dv11BLM5m0TJcfkNL
vP2nB/f3fhmFq/t7isvZ0h0CcIGT5UuKEzyKD7P5XRjRG2FUQr8Im9PvolCp
sEpXL+L3EFmswuh29UDxd7N5nCtDVj5ZSqVJGrWVhkRFotjpRtm8pEw39Ef4
cvlANWPVjU6kMarahUTrDi8Kl/cIhvESXUGjFJUlVdaFLGVlnWl6/HH97h2p
KinaVLKNSVRGjL+azd2TtG0k2VwAy1DWVgkDiaI4kvyrVXtRAJyshogkhCAb
HNJW5mKv4LXOejDLQQ4hhZ9iQRjTluDAWQUuHGBdYt8KONO0BkJVksMAU5PI
xqpMJWN6R3Q8iy6gQ66SHGjgBmrOkOyorx1NOnOPPkdLSGtDlbYyJbHVexmQ
C/JEWwKGt56WKoUUaBJp2gCuxyrbwqr6WVAmJEcGflJlktYY6GZtw1QgefQo
XRLoLlxN8Lg+58NH4flDxmSVSI6vGkmBgQOz/IrBbsKXTNwYkTlGxumJjf8T
BRSGYUDVIvo3cDyZdvseLjHsCJTFHbWXGVFIsGwu5L+OXl+GM5aIyLEC5ZS2
R2d7zNtr/E97Zsd6VecJIQ34tcoex5YdiYuJwGMugkaVojnSTqOu4bGjcz90
s0PWtJeNyrxHW1WlqBYk3h6kRBtfxt8ThuxaiLbK5IioEiVS0wx0isJ1k1V7
6c8QXX841GK7LTBi/pTHAG2D+VWjuhAh4JArdufqFPPVOOiAtoLrSld9js7x
+ia4KrWxC0czpL9dX2HmuOpsuP9hjfTWClVxyKcS6/HOU9y1tGnrWjfWf+no
cqhy1Du1bHiIua4Z0Jwl32VDMeOzbq1RqfTFmOhaeuedlGuVqXGjqZTSejFO
bnDq+VF6u/b3CcasAM2lRqiam/Eys0CrdibwoQnWNjW7gBROdOVm/qwpJ4rX
bF6QgY4ZJlWmi0IfmG8M+lQxnDlr3ZE/m7mC/v9o4NP4lvTptmUpmGN7X9Kz
Y9Xnup/p27N+h/7+46F2gY7BD+gXl2jyW2aIVKHVoIy0mKF2pqbDGkkEXNIW
opnKbimOvB0CyvVBon4C3gWiRk1gprAHna+XVQShooMyfWN8pC5FYTR2FyZF
qaquQIy0o8U7jrnWwFV9Hwq0mWeAPfG7C2amJ8MkjNtsBv4E/tkRQdc1l+bF
yYCDmGyDNrZn6jzbVJWrreLKOC46uEECKxHLM8kVmBxfKaa79nR18ubaxPIC
3KxWNz7gDt42UuLhbdhD/pSNGKQvpo7rFSnv0WRZW1/ymJPY9HRQReGqgC7c
YHuprIEBNtx0OSgjxxm4wPj5N1zmLoA+drXqRiF1G8KXyokoVHym24ZzjwWA
YV+bVxhQ0ebFxP6uMHVg92/HdgCxFVrPa55xNrp0beY3kIFxNI1PEpgbT5eK
r35nC4prYjO/hdqhEfWirdELj+yY92t0LsYLY2D/SSQW91SN6dppdp5ytob1
0k+Msz3VLU/O6VAbHcDNlwKgiBMk1s9uhevxREvBv7dqx3tvxaztsc24YHO1
yxcFSr6gDDM/yTFw+t3Wo3zqTk3j1/XCvzaby4yeCX6gx3j9a0wfehNnp5tN
h3PNx9/Hs/8EGABk/lVFCmVuZHN0cmVhbQplbmRvYmoKMyAwIG9iago8PAov
UHJvY1NldCBbL1BERiAvVGV4dCBdCi9Gb250IDw8Ci9GMiA0IDAgUgo+Pgov
RXh0R1N0YXRlIDw8Ci9HUzEgNSAwIFIKPj4KPj4KZW5kb2JqCjggMCBvYmoK
PDwKL0xlbmd0aCA5MDYKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFt
DQpIibRV32/TPBR9z19xtaeOtWmT/mLA9zDGBkgIJi2Cl0iTm7iNPxI7xE5H
0f54ru1kTZOsgBCpVKX28bnnnnt964GHn2LjjN/eerCRjjeD0QIWng/Lcx8K
6qyd14EzvvYRFqwdb+JOnsMEP/bt3HwvPd+dLJcQZM7EbCLhCHcmcwgiXAru
nQG0n4fT4H/cG3l4FKMGb3ownzUmeNbYORu1nrMO5AHec6YYSdkPopjgNtKf
shzI7N05e9Vm+QVTZ+U4/+ffxHeTOY5HHTeFiKiUcEkL1RL29/z/PN//Ws+v
831/DR+IVL+Xr9lmHG6ISrqJ/L2eNuHRfIN3Vx/b+KsPt1dH+Q+cbNn6iO8p
a1+lH/FGxJeC5FDmlRDTSTQnBYW1KGwux/g1xUf6va7DIb7Hj6N6nsjvqJ/j
iicMG4hWlIML/AC3waebFksYVtBxNcJ815v552aEXbNNiXb4Ltj+qW4a4xu4
TsV9lJBC1VwL13M9HFZ5qaReuwocDxg4dqhOFzM7W93lAnCazp6bcfxMz+P+
MTydz92FHcODIGESSLoRBVNJBkTKMqMSVKJLlaISrUjSLeXY6loA6Crmhdiy
mMaghIZ2J3Suc8r3OaViw6IXGjd15xrU9CIckPAUiMbLnEaKbSlEWHm2ZpGd
zIZOrCGlfINv/GVtTThY4VGtVrGMDiEYmg67T1iUmOUtjveYqZ0+rX8bJpmI
Mo1h1SM8pooWGeM0xsqE1p6M7BBrjkdlUVCuICaKjm1IDCdFhsyC4QbjtTQb
TSo3PO2WPxxEqLuUtLhj9k/oLhcpi3Z3kqoXABfoudKa9z7oCBrR1YyV4BpE
CwmcZNpvE1zDmSkmUaZsJIporsgqpY3Caa3NKFqUC0FCn5IHCbENoouFWzUJ
Wl1SOCF8N7LgE2DWdE0EaCQXCiLBMRr6C2QlStVMsCayp90+12Jd7aLEEU14
lKD1jGO9M9MlQ4ipjAq20gYQuLywiWPsLZqAmknXupMm2YnpHVPmTvdhN2hL
mvBabhW1ujVtK0Pf9yXg9zQTUo0MASZ/eYFLsyZrTddNDN+jtMQwBxeokUU4
8OpbUNEzvMfoOXYDHe7vio8okWtKkqa7Yd+JkrNvWMV9SzWOT1tB8nKFhYKv
dLefIA347En4EB2M98D5EVmNGPj/geko3eU4pgS2HgJqlnsMbrv+8YBbzcqf
AgwApx24bwplbmRzdHJlYW0KZW5kb2JqCjkgMCBvYmoKPDwKL1Byb2NTZXQg
Wy9QREYgL1RleHQgXQovRm9udCA8PAovRjIgNCAwIFIKPj4KL0V4dEdTdGF0
ZSA8PAovR1MxIDUgMCBSCj4+Cj4+CmVuZG9iagoxMSAwIG9iago8PAovTGVu
Z3RoIDEyOTMKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiaxW
wXLbOAy9+yswOaXdWLWcxGm6e8lOk53MZLaHam+ZydASZLGVRJWk7LjTjy9A
irIUK50eNj5ElkHg4eEBYAwxffRm9u6fzzFszCy+gPkKVvESrq6XoHGWz/5O
Zu/ulmSW5LN4ES3ew4I+/ilervjfVbyMFldXkFSzhfuVPM7JYHEJSUqvkt3s
NCkQrG6NBVGnhdIg61zpSlipaqjEHtYIjVZbmWEGVoEl+0bY4k3yhTzMYwpA
4JKPs1OyStEYWW/APWatRvLmTrBLUDkIODFY5nMjNzX5S1FbmctUWDyJ2GPy
doCIDCYwSdP/usZUtIaCWNgJAxmWcosas+BpABcm0a33YFTVhdspbYs9nKjW
zlU+X4s6Owme+iMRwH3uvAYQTbsuZQpfcQ+i3CgtbVFRhb61UqPpzwstKrSo
zRkfrjtc4SUIPWBZlIpQ7sgRm/XJHMWLuhoso/hiee1q8HiKj2+ILmmlKOeN
Isv9vBJNQ3nPZV3ItbRnsCtkWpBV5pg3IHPwpsdF7c4y66Is1Y4AdCU91I6r
whxP4skHePC5oSjSdsAmgfQFq1iTazyGtBWlzFhRICyUKMhM1cjqGsNCn5Rk
v/WQSZKMfuowPXkoTwbtJPzNAL6o94HSV6ncFUiRtIPC9hNt4jzAp/uPYArV
llnXYaxOZjdnOUvGnJZt5vkWw7Qczvl5dMkeh2hXURwt4d6jld9dYdj2NpnF
IGF27WbDZXwZLWlExNfR1QpoHFy8dwPlLU+Ul4PEH7m4XoU54rpTjkJAUwhq
QjRWkDJNQSzYHZZbBHpDVdgKLekXer0WnGHbeFhjWpgwg1tqDVk3rTUf2GQi
ycdTQSVxGgi1sxrxA8AN8APrYFIDoZ+kPg6uGk5ElPCtJce5pJb8E1BQZTtV
kcy25EOF1qc4GhtqcKwtdUZQlpdmV2FSpy2okMTCBl/vGp+L+96PQBoxA1eM
Hp8lj+jfczmC4167qUMDsrHFKAnyhZxzmOx1W61JvSoPLgZUmj5gIdwToSmI
FtIvVa1XcAQBfT/8QhKZglrZ/yeXAJ8al8H/+9/DQwSf6hRf+/VsBGc/XAgp
DRE0E/1/yxKoVdbjO9JdaFNDA6nVQAgFqPUXTEnBYeZMja8wAYWDyJvRGJVK
4Sa8B3jQ4sCMJl3IgwZgpWhv0FSlcIdzFKBFPlNnPDhoIRGfpbT7MKaUdlus
Xyxcd5ej4aJ4kTx7llNVUbc6kXeycZau7IOJmiveDUylwUrUFHDcv4P0H08l
9W/ygksXG7gYJcJgQvZNxr6n24wXQb80CGSJ9YYT6JuJIoaQPaU877uYntcj
zsPpQV3CBIFRfFLGcN6M44bAgyo89VWYXhsTnRdC4bPF2rhL0Iug7v5TCf2V
rw899hB1CGnbIQqqGSxAqnZtqbWN36edvA43A/ZARTG+9XdudxlqSZPvfSsf
GHm5iZ//iF9dW4ON4rUbpDbRbAOVOCFySV5psaCsx+Xy/LC56dsFtwZg1dj9
WBD8PuQ5RU9f/w6BBzvtPzuodbr2lOPdzcPnW2rFhLkLHUg1MHQL1P62TVcD
YYMj35nfUauJUXUnN3yjPfccbbRo6GZy6B8/UDtiA9t+P/uXv2bR0U9Qb7JM
dqsydwF5r5Yl8C3cScDf0wn6AbQhAtZua9SbwxI5Li5dr93tfHxbn0gV4Mf8
5d+PY/xkBhPVAfce/uJTIxTdVemnAAMAByBn0gplbmRzdHJlYW0KZW5kb2Jq
CjEyIDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIC9UZXh0IF0KL0ZvbnQgPDwK
L0YyIDQgMCBSCj4+Ci9FeHRHU3RhdGUgPDwKL0dTMSA1IDAgUgo+Pgo+Pgpl
bmRvYmoKMTQgMCBvYmoKPDwKL0xlbmd0aCAxMTE0Ci9GaWx0ZXIgL0ZsYXRl
RGVjb2RlCj4+CnN0cmVhbQ0KSInUVl1v2zYUffevuOhTutmqpaZJm+2lW5oh
QNACqwbswYBBS5TFVl8lqbjux3/fISlKtuWk6TZgWPwQibw89/DccymGFOIn
15Mnv70Naa0m4SnNzugsjOj8RUSST7LJL/HkyVWEsDibhPNg/pzm+LmnMDoz
/87DKJifn1NcTuZ2FogzBMyfUZxgKN5MToi+zA7/vjyO32F6FmI1MseXNozc
3+ev3YMd+dnE04eWFSITXC4V12Zx/MM9yN2kA7l6efP21SFeIoUWCTD1dimq
FI+6lg/H/byIoqes2s6auhDJFm+nX3fQ+ceGJ5qnSzf9IM5QIwrC0+iFVeNK
rFvJ6WlA1xWYsoJuWdFyqjPSOTcvokfXknNSmmkzLgVbFdxnW5ysFo+p4bIU
2vBR7cpEqwuilwRWBk/WtaaKlVxRVkviLMntK+ltw8d1WpzwYB1M6c/g2XxO
qVBaVOtWqJynDmVKvGSiIJamkitlBgArGs+pHwezlGeiwnpino1nSBuhc1HR
Jhfgw4rCzLyDqh7GMUYExhX/0PJKU8KlhktQTDdlpBrGRF1Rw3ROKgeex8nw
HFCcC9Wrh6VJ0abAcLTGslxYaOFK45FchUywmfQLL/cUeu1Yqz4EW94hczmW
86fdVDTOAYDfr359HkUu3CONUuxFoUY6Cca2W5wkqAr/aLf//7VLVXu32By9
Jn/HLCXbkvWIR/lOq0yJVSkJrY7bBViPeNno7aOj5UhtORr0udBdv18AEFia
r7ns9tudYGYfqDW2X81e/3FzM67G+NxAfglBhOSp6QLeIw+YRpiqLVcYrLO+
/ZBD8SKbCaVa1HJPTV3TilMj68RULsULdIEcUM6v75KWphLgIMqmVobCmyqx
rp3a6EFnUwZgpjyRnCFy6oFWrbaTFWy5svVwAQEtUCpm0KdOlh2Kvt6mwgeM
1I6A43MW1aQCAHIPLUFFkH9AKutbt13a2WeAWl5n3gYzX9buG2JUMA4CrcoD
jTsfQXM0CCbkRih+5GxARPVjeNRMHARElYsVvDR8vO710ybnJpfJc6S3Rx9B
8ntJsV/7vTZ8krpSGIHFoF7JdJLvWW1oz6OOo29bzSMccRynIyzfXF86TyBW
4rto7MA8yA781FpzXdXyv7VmVzTlW8ocgRBmvLMH2dNdB3AkHRhygJp1CXc9
efcX7x95MjP3E9dfJWsa7Oxb51tnsS567Eok6y88AT3kTDt02BEn3Hmm7bOx
fnHaIbnHebBxaN8xQ/m/1zikcAE1/ac6gh5qh6fJ0QsFOO19Yjjh/JJSpGhj
Wm29qY7ocmChzj5dlrtsNOzrXzva1uCxqeV7ZF027Qoslu/5dsmKdY2bfl66
C1sq1kIDTqGnmTYX7D5g7KPWVBlVhxIi27rbVL+uPhDfGc1v7D4mziJ2W+IT
MmSyLi24lq3Sg/ncWsLagaSx3y1O0tTX2q5BvyS5uTNVcGRpry5Wo1fx5C8B
BgBIhoj0CmVuZHN0cmVhbQplbmRvYmoKMTUgMCBvYmoKPDwKL1Byb2NTZXQg
Wy9QREYgL1RleHQgXQovRm9udCA8PAovRjIgNCAwIFIKPj4KL0V4dEdTdGF0
ZSA8PAovR1MxIDUgMCBSCj4+Cj4+CmVuZG9iagoxNyAwIG9iago8PAovTGVu
Z3RoIDEwNzgKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiaxW
TW/jNhC961fM0VnYWkt27CS33WxbLBAURasUBdYLg5Yoi4lEakkqjvvrO6Q+
TFmye1nk4Egm38x7M/PGAQT4J/fex9/+CmCvvGAJsxWsghDW9yFI6qXe58j7
+GuIx6LUC+b+/A7m+Ff/F4Qr87EOQn++XkNUeHP7LSLO8MD8FqIYX0UHb7KZ
ZJsbOAj5yvh+W1a7nMXbV3p8AJ1RqJ8Bn6FSNAEt4I1Klh7NtzfRC4LMAoyB
+UVfvIlie050JSmIFAjEVGqWspho6gNEiDeMA0wB40wzkrN/aWIwow/eJJWi
sBloWSmNkZ1MSineWILvGD8dAcLjTMj2PuOpkAXRTHC/yTP0g2V4b/PcTNgo
6W1JJCmoplI9AJwegCglYkZMIgems3H2cSUl5dpJdYoHiYaCHLFmPyomexIS
6PRq095MElpSnmBaUJWi5kfyvZAYtdjcXJTRybzFeiOSkV1OzxSGq9IOUK6J
Da7KAF9TU5qYKmXSZ+pUi7PgSJzm6cywx1dOl0xbYc21qyTh/9h1+Z+upIzm
ielMw0NVuxcau8Ua7ZMXp0+YUhWVW4542B0GpH4DCVMaD1RMZZiB+R7oe4no
dT/3u6TRkdN37VJv9Y0zwvhZmZ3AF2TFpnIr2uT1MwbldSjA89cvD1jDEdam
0XfUmZYhfTs+hIMoTUiSQ8XZjwp5JTg6qAWV4+QxqCm1U9nBxXrY8FArPlzQ
egpCukhvJEeg35+fnq7Gvix4J6Y9vwnDUA15/ZRy5FiOgrzjJOhsm1O+15nt
RZuepnsMM8yUTzFK0rROvxySKqphd6zdHkGhBoVYcKUl9qI+zQ2Bx089Uzd4
s4V/a9DcPJ+NdcWiKHNqmLQz16Vl+QEqV6oplFQazvbEjigWjzirMyeOxVgA
UFhsI7DVdeUH/mJEOfsePht4eHTQ/ujQzJ1fIi8ABt693aKL1dJ8hPOFv14B
Ls7lnV29H8zuPV+5zZXl0r+rN+4kavnUujp5k9jwV6Y0OC0Nf+Nd2JY9SwAi
R/ZMzuyQ72guDpbqSAU2E4Kd8ne3q5tM+obTtdoUH+K8Mmvn4SJggIDWoRyM
A1HQ2PjlvThi5N1Kw58VRhE9utTaoTDNO37C2QjTsXEJR3LGaWcJ00cjPBNJ
Q51iORhaWDQ97eIF3v6k2/cDIBw0LjS2xJt4RQHqEbOvBB+qkAkcIqVx3WPP
byZ2ZBu/TAyBghkVcRLFTuPYNap0EpTYP6U0pgqPfz7BN0Vxh1HbSNj0/3w3
llaj9wt7shYDXemZSGc7k2pBcdVwpgq1uRnVbjmiXbNYmk3UK4qzpKZD9hhx
LMbt5RhD/zzZ/3h/ndx6iuwIP+9m50r/B2Df5rngM17luS0oyhhnVA23RePh
9VVz07qkqzfGuBKkDdAD6X79Wsdtmqk0Hs213xjUfwIMANvK834KZW5kc3Ry
ZWFtCmVuZG9iagoxOCAwIG9iago8PAovUHJvY1NldCBbL1BERiAvVGV4dCBd
Ci9Gb250IDw8Ci9GMiA0IDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEgNSAw
IFIKPj4KPj4KZW5kb2JqCjIwIDAgb2JqCjw8Ci9MZW5ndGggOTA5Ci9GaWx0
ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSInUVl1v20YQfOev2EelEBmR
lq0kfXKROAhgpGrNtAWqwqDJpXgBdcfeHS2rjv97d488fVgy7BROgEqAKJK7
szOze0fGENNXz4OX7y9imJsgHkN4AidxApPXCWgMyuCnNHh5llBYWgbxKBq9
ghF9u39xcsKHSZxEo8kE0kUwcncJMaSA0TGkOV1Kl8FgNriavYAPJeSorShF
nlkEAcKAVBYM1mUojGmxGMI1alGuwFaZpR8E0159xty+SD8TVhhTKaKZvg0G
MlsgIyyFrYQEJRFU6VIa1AthLRaXlGw1ooFSafgjOh6NGCf9IRgUwlgh560w
FRbAWGYImSx26mOWVx40qy1qmVlxjV24R6LaWzxPa/uRieGNRWmEkjAb5FpY
klwDkZBK+lNyRKxRnqzCEXPa7arBqPclieJx8tr5QvW+mdeMsM8Ub/K6Lf4X
drOChy0/LOQJjhcM3mFsu96oWuSCYDb0iEKj0aC00CnZN9sjCIZgjxj2OqtF
cekAV5fMzbfj46fz8yFhqhyN8YAsr4ulKqRhQUZS8asVTxWfUy8cbKnqWi35
zFhsDHNSukD9hlGOomPmtCs1JqnsimtWX2PqmODfLZluFcyS5CiTq7C7S2dj
NzSu4M8f3u4rXlbKOImtk0Ux4XStnFHJDtQ0uxYKpFI0QtPwFyLrtT5u/I6g
rdKzgdj07oDJ0k2EgYwkFm5QCmxstZ7GMIZlhRp70sL0baXKDc0nruGI/BBy
jUTPJ2eQV6IuOuTM9M0wb5zQ+3zYWK7hk6c/rsPWDl26K4rN6VZXH+FzDnDi
8FvH/e7AZP95xp2+yRZNjcRekZU0HGTGvlOuw51L+w32tsHGrwc8Ygdv36u6
GHrSv1fC4l0EcEq71gIfXmScxap94oWor5ls02CmfVseWZ6q9Nk7uydVTynZ
VfDrygCtqpy3s6t2x+W+7iaOJtYB0F/d1mxVXcMcJWq3wrsp8Nk7Y0b7drcD
7dSOHBnaRdrabj1CTKWWkufoTMxbcngc/cW3wknXz/AoSuLxkesHHPh8Ce9/
vuw38mBif/yVrOiveEpfUefB8P54e7e+8pXodPWeqWH8hIpnp+cX776Jnm6+
oRvs50Xf5H33qN+ev+lu5p/A4fuP1L2BeqRaK4WklxDaM//hNfL8WtxE3f13
p3Z3/e2E9V4C0+4Vg98VMskPhdx2OyADvEuDfwUYAOwBZnsKZW5kc3RyZWFt
CmVuZG9iagoyMSAwIG9iago8PAovUHJvY1NldCBbL1BERiAvVGV4dCBdCi9G
b250IDw8Ci9GMiA0IDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEgNSAwIFIK
Pj4KPj4KZW5kb2JqCjIzIDAgb2JqCjw8Ci9MZW5ndGggOTA2Ci9GaWx0ZXIg
L0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSIm8Vktvm0AQvvMr5uhWBhvycJOq
h1R5KFKlpgq3uooILGYrzLq7S5zW9X/v7MKuweA4qdLig2H55vHNDDPjg48/
PnNGV7c+zITjH4J7DMd+AJOTADhxUudj6IwuA4SFqeOPvfE7GOOvuvNP3qm/
iR9448kEwrkz1m9Ro4uA8RGEMR6FS2cwHVA6fQM0BZkRTmAZCSgYzCMZZ0AL
EJIsAEGIiYpEgd6E31HW9VE1uhWeO4OHKKfJ3YLlNP55JzkhKBjnZUIERKgs
IcBSSMhCokbXhyWVmVISvnUGqA+0OFTiMA2Cg6j46VaP+HQ4hBkpCI8kQW1x
RvNE6zQalDblFqQsz9mSFjOlsCTiFASRYA3U/oFkRvLz9bl7896ifpQISynh
d/qEwY37ZahJ1wgjRx4XJJbEMq7hK61v7dXxCTz/MDjR8fl6yTiQx2i+yMkQ
YlYImhCObLqB02wiS7Ad53YUdbo69KjoCaFnXD8TopxXUjHhEunGKq4aSTFd
Vwyjqyjf0vxBubhYkIgbaSyHnZLkURLkxQqV6wbCynoAIQprC7WvCSOq2CRk
0YNKrs3AEO7LVshrd2q5DGu0lTH44lYINHKdWhZb0ksVMGVOFzdJVHnXlX3P
HjAzMsPo8TJXachzI22rTy5Zo/5Eo6iHwApVgJjlKLa1XXlb8+ZElLlU6REZ
WxaAFC7prESPjrxvSsKdVAXjHniBf3igEw491293+/rdrZReQeipDHVu/H2B
tZ3w+n+1ticv1N7tF8+wd3n26fbi7+zt0b7qhmz9qjbwGjXup9OnwaPW0x70
aOv5afg2uovvS5e99vKusfrjbJ1sbusPtTr5B7abddm2vTIdZP1M27YFPMN2
WdCCSorN6hdJ9ElSFXfvy9fnvVIxX/fHfNWg/Rq2x60GZlsc3HAWEyHUeC4L
04Dt9MBhhi0RchKlVQMQOGJVaxfd3tb9IhXmwDtSgObYnQ4Cu9nsG1p2Yeld
cHbuJmC3j80sUuvAGe4OzQlEi4zeU3m3kVaTYMYJusNRPipgfLqDhhkrVWDq
GdzdHJotc9ilYLXo5cio6VtlcCTqYGCqjPtd4hhY9FpuRni1KSi9zSVtaDTE
mmrrHezf3Iz01gJnIoA8Us7mu5hsrS2LiJNCatNPLH1nZusz0ga5Y+vbuFKZ
6XW59pIKbf3/b4h9vn+o2oLO0EXo/BFgAAOUZjsKZW5kc3RyZWFtCmVuZG9i
agoyNCAwIG9iago8PAovUHJvY1NldCBbL1BERiAvVGV4dCBdCi9Gb250IDw8
Ci9GMiA0IDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEgNSAwIFIKPj4KPj4K
ZW5kb2JqCjI2IDAgb2JqCjw8Ci9MZW5ndGggODc5Ci9GaWx0ZXIgL0ZsYXRl
RGVjb2RlCj4+CnN0cmVhbQ0KSIm0Vk1T2zAQvftX7DF0Yid2AoEjnRIuPXSK
D2WaDiNsJVarWB5bIaSQ/96VZDl2HEzogDMgS96Pt6vVPvng4y9fOIPrGx8W
heOPwT2DMz+AyUUAOXXmzufQGUwDFAvnjj/0hucwxJ958y/O1TDxA284mUC4
dIb6K1p0UWB4CmGES+Ha6d0w/kDzrQdwWRSrJYVZEIxIunEzwVm0wdkYSJZR
khfAUpAJPQl/o67ro2mEFX5xehHNJZuziEgKWo3RAuijpGnBRApiDnUJ1of7
lVRWwk9O71rwGEgagwECsYBUSIQTJqyAfMUprBnnsKApzZW6XAurGyUMlVMR
ozt0EtNMJsq8SCnMRQ6URIkBtNEGqVXMabHiEtBBkYh1CveUizWQAqZsscop
nHm/lKg78fxxcAFuYEYVKxx4nt3957mdpIOKZvhO42rFQnyDnxfFy/Fp+7/W
dW5rqXX9I/xNL7/eXH1INE+qWPplpWzf1To+g9r7bNYtPGjMXpEe7M27xfel
2/KHNqp6Xo27lNXnrrGyey2Poln5AN/1itz33VGuLxWoPvxH+F6lLGWSEc7+
6gP3bMv64Mf3j1uX7/Zw3E+2qN8p59h7Rl7gj0e691RtDb7lIqJFwdIFRrwk
Mkow2qpnrxOqW3y9X7c72YEWX2Q0Qnlca9OHMjDyTpV2HdOsN5qdAJsrf4gN
ezEx7cawDDzgVsR3xsydzGm7DzVRYb/nGBmyhUzESiKnbKBGEH3U5VTxR0Kk
XvKw7yKvVUwkFeEUkmaYGcl4iYvgXypaJOP6UDq06tav9pnT1Csh1rjj51SR
0iNZZpz2IRKYuxjP2eFoDTNhMszmtQOeGNoyzKZosQSJ4e1A6mhVDEuS/8Gt
VigxNRY07o//A/8FkJAHHaiF39ekrDRN3mJ1Q8gyvlGlIy03V7kTOgrDq1pC
haCJOyKrguqvendr6AKNzppAi02MqpT8Ww0Ozd/XgaiA54Jj9OjLGsBbClcV
W145NB51fYgFJgXvFCUSVRcmUdqq1S6Nm7B3pYBjJNR+SVreCWwpj73g/HRy
1J3gbbeB8n2fekfHsl0nzw1qnjp5aNDA1CVqCcvC75CtuK0KtSXciGRv1hlm
M3vNWTm9Laf2MDf286XNOR7QrrA7EzCb7S02FkxCrkLnnwADAGV74d4KZW5k
c3RyZWFtCmVuZG9iagoyNyAwIG9iago8PAovUHJvY1NldCBbL1BERiAvVGV4
dCBdCi9Gb250IDw8Ci9GMiA0IDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEg
NSAwIFIKPj4KPj4KZW5kb2JqCjI5IDAgb2JqCjw8Ci9MZW5ndGggOTgyCi9G
aWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQ0KSIm0Vk1v2zgQvetXzNHp
WrIlO3HSnnaRpCgQLIKtCvQgIKClkcOuLKokHa+B/vgdkpIsRXLrLrYyYJoi
+ebNmw86hJA+cuPN3n8MYaO8cAn+FVyFEaxuIpDo5d4fsTe7j2hbnHvhPJhf
w5w+7teN/V6FUTBfrSDeenO7SIA+rcwvIU7pVbz3JvDqmdnvJHn1uvciSS7i
L94iuFwZWiHZoDG+9Sbf/OPzDfqz709LkaECkRvg+A0hdcwRkh0/1zPoL9rp
5+M0w0o/tzj/mREA98MGpgUfe2adRSfNj47MeotnnZlBf/F46NeK3lP59DT7
30Q3IHPwoyBcRjc2q2or93yzkwirAOBR7kpebkA/I7ywgmdPlSh4enjSErGb
m4sgCpcLi5JMlskF8NweSlFqnvOUaQR7lJMQ+I/GUnFRwp4p2DL5N2bAVE2o
k+ap5JrOFlNQqB1e/YbrwxMvMwMsJPASWFEMZLZaAQctIP7r010AH84l1SCU
Qjf8fo7LEcBRgg6X+98fPt4FZoffyNcJQjLBs+XjCgzDSqLCUrfMhkIOYmd4
/Pnp4SEYZkEyyYnAC0qeHwiNaUBOoJLsVoaBrnGM9Y1EoibNtpLanpDnmq+Z
49cdKxou705JQmFj5cGoqDRWCpIJSy6mNKzdkJqBbDvmOeOFmlr5KilSzEwy
E8ktL4mrmg7pSdQ7afOc2dPmQB1QozIrKTtpqAiuktzEgtxWohwRj6jygXPl
FFJRal7uENYHqFDmwtDZ1CSxYtLkzsH5NyRYcFrITGpdBWGwpMJs7HRt1LgW
dC9Z5e+qWjB3vsnJGuZyhL6Fp6p3jIzzhNjLQv6b7dV3sRcSA8/df4tLqv9r
iKIwWF0B3XzLa3t1vjF35/iVuVgsmytzEotaBLTmbNSUMvpQyF8Z77uZi6IQ
e9o51Mx5PqD/ttu1elnPXNkxqNN7SwE3HHrl1pZatz5Gc15VmHKKDeU+hT2J
ogXlsO+wabaETKDLE7KDTFIDpCxrY6TUDuWt2DJePjo+5AkDtVt/wVR3F0ZL
eP1TzpADLtLI0uehKyNkPtz6jyYfbQKfMPH25AURHjtc3RSawy+MCmxd4LC5
TA3BITfD2Db+hs2w13S67576GNbk2yb/+pTro9TtSGhsoWxvFdaE+Xm8ZUZC
4oKuXHaYtLbJkHN7zZma5bSBlG8ZCMdpffiuoKORjs7Ssu0T89MFwAkpwwKp
TI6qdsRzAp/T3XsyD6Iy6gbnrR/SMmY/jOqQSc3UD02xFNRDYE9Xl9hpe3+k
z7zI3J+EaeOoiVDdz/4VYAAVJHJBCmVuZHN0cmVhbQplbmRvYmoKMzAgMCBv
YmoKPDwKL1Byb2NTZXQgWy9QREYgL1RleHQgXQovRm9udCA8PAovRjIgNCAw
IFIKPj4KL0V4dEdTdGF0ZSA8PAovR1MxIDUgMCBSCj4+Cj4+CmVuZG9iagoz
MiAwIG9iago8PAovTGVuZ3RoIDg3NQovRmlsdGVyIC9GbGF0ZURlY29kZQo+
PgpzdHJlYW0NCkiJrFZfb9owEH/Pp7hHOhFKaFfavW1aN1XTpGrNIxIyyQXc
BjuznVK+/c5xHCBJabtWCELC+e7353wmgoheahmc/ryLYKmD6BzCC7iIJjC9
moDCIAu+xcHpjwmFxVkQjUfjSxjTy32Lri7tZRpNRuPpFOJ1MK5+pYwhBYw/
Q5zQo3gTDIRMcQR/sEBmwKy4Bm2wgFIYntM9KgRGbyHBRmqQ2Ul8T2vDiFIT
rPh7MEixMCvgYQRSQY5aw4ablSwNJCuepwrFyC4Kp6PofHIF4cRd7dLZIJmd
wFet+VLYcpCgMjzjCTMIulzcY2JAsDWCkbCR6oGL5ZxrXaKa28dV4viTTZS+
mOi2XOQ8+YXb/WRF9XD+gNu9XEi5brIqT3vtjcgkZBzzlLToVEqkMIwL3RWJ
CWD5UipSZl2vtyqRrCIUZZ5DwRQRMqj0ENiOx+6xh0fg7Q9dAvNdLDwyxdki
dwKNDzR/FzFgoodbL7E2qUSuC9tLrdSeVsekXdbnGTcxjXk3XexHMjOR2nC/
+FiFah+kPMtoTwgzBI3mhaV7dhADq0ePG7NB9obGbWvS9eIohSNdMRssXdMz
t9/IcG0UWW404JNBobkUQPOBiyQvU0zpSz+CPQJDWEuSbOs6GdWaG4PpnGgZ
hagr+fHJ5WueNg1hrAQeMgVryGSey43+YkPORp9txUMOEXHg2a7Una9EwAuF
mpyrccMBTDKzS+QZ0Ie4fHOSUGQ0mWVlclPSkuCmKvzIZWk3ZV6i77n6jou0
wuD13IntU1R7agTWmy6vVNKHkMbbQvZR2xmelDlTPoMboNuCiL6OE29MKEWy
YmJJ8DIa7mbF/DimbL1dNHFd5F19twGd9nhG/1I44YEU9+A/Rvg+Nv8j+4tM
SKJG7gZDv+phb/evXPdX7VidkRXl/WNU16c5AU/JChIgf3Ez4VNBk4SbeSHp
urUwbYLxEFJMFK6tpa2YrpWLLUR7B+yk3qdV9HzNioJmVm/mVshi65Pspztz
6bhY8QWBYGIbHgG7H9a0igtvYPYLzP2IrMM/fki2xbYGtiSousbjfvt4JPwK
/5Zc4XVd67aRyu9QW5Vuq/9y1H09R34LpzsO2+Drren2224m9pY/Nkxqw1zg
712zvB7uoYQObUvWZ8D21a6wXsfBPwEGAOPD2yMKZW5kc3RyZWFtCmVuZG9i
agozMyAwIG9iago8PAovUHJvY1NldCBbL1BERiAvVGV4dCBdCi9Gb250IDw8
Ci9GMiA0IDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEgNSAwIFIKPj4KPj4K
ZW5kb2JqCjM1IDAgb2JqCjw8Ci9MZW5ndGggMTA0MAovRmlsdGVyIC9GbGF0
ZURlY29kZQo+PgpzdHJlYW0NCkiJtFbRbts2FH3XV/DRKWzVUhzb2VuWdUOx
YAhWb30RYNASJTOmSI2knLhfv3sp2ZIltkUxDH6wLfHee87h4ZEiEsFHF8H7
3z5FpDBBtCCzJVlGMVndx0SzIA9+3gTvf41h2SYPonk4X5M5fJpfUbzEr1UU
h/PVimzKYO7uQscZLJjfkU0KlzavwSSZvCQ35GNO7J4RLvd8x+2DPD0rwdMT
YW+WScOVJNzA3VTUGcvgB66+2bxAj1kEIwDe5pdgkjJtec5TahmhMsMawYyB
xVSee2+pPM0q131KDLNX17Hl5l0wae4TqxyqIxU1IyofwQtbCHEYLeJ7ByGZ
HIDO30zz/IRzrevQBwagKHl8uLqWTKghpmIpXGDZmBgQpmRHDU8flTRWUy6t
6YmjNIEGR5wK9UTVdqby2Q40SG68IEWneR/HK3SRyoIuIp9xY2qWTZu2DZkx
spK+bStq91vBZGH3yK7QDHrpRvUvTCu3FxlLNSuZtGRQctZ8dyKRF2vZYMWS
J1fRaYDjKs0Mtm1MQcYeGIPuTDHA0jhiyGlgg4tJPIC8BGRDgJIDO5Ha0IJd
+/rMAOGWVB9gB1PNLXAQ0zH448Bb0PQROH/ihSRgTmwIJLxAFAD5k6WqkPxL
o06lVYpigPmJgm76MrkHsVN4jGYguRs7uw3v8H5/OPBP9yw9oNWTmylx5wS/
RPOFGoGLG4w55cJMHTsHMKs1I2CpkkuYYTyiaGZrLbksQGWsxgIuM8SEDJAq
7DatoF2lOXoDTGqU9MgESL+BETs1IPf0CNRVWQlmYcdMnaKSeS0EBAtEVet2
PgbrhGc6V7p0HN3BvjJuuy3I55IKaPBlGIWxBzNevyOfNa1mddVphgs/bIKI
cBLcu2BeRGuXz7ercLUkkMWLtUvzdxjnwxRvSm7v1+G6CfGJEwa93AcrfbHh
hGJvFcQkZGubp7xZNvdsYBcPw6Kv5sLufKzahak3GsfPjWFE+Nz0T801+9Ai
eb6g75/UPcUgvzwb5k12tM8lzIchEWNx4JGC/3aCYarMvbxS4PUAm1+M0Zp6
98JS+1zvoOPvzD2hXpU+gFG2lbu4hTgIzwiSSdbl/LD2o8wVAWOJDOEPJ4GY
FqTEZPAYWBQKYmJftvWv8Bt2Vs4kuB+CWtMSzoSGI0w7Ht3lNlDPKMcEtr21
Z728UrEfkKoD3Y2/puUB0hV9E0f+X4P1++8zvqhKJgUMfqQirQWuaV6hUDZg
7t4L8vOTi2etDbdWswaid2RtmN5yCVCpOFeAr3EnSa6EUK/mJ6zyRHwy4Z3b
xiPh+Pzx19PTdIyyvdOzLf9eJ4wRrPlhIlicxPFt9xYI/xZ+UP2zLC0EwhiL
d1P4/wsfi30U0r4P2uj/V4ABAGepwEsKZW5kc3RyZWFtCmVuZG9iagozNiAw
IG9iago8PAovUHJvY1NldCBbL1BERiAvVGV4dCBdCi9Gb250IDw8Ci9GMiA0
IDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEgNSAwIFIKPj4KPj4KZW5kb2Jq
CjQwIDAgb2JqCjw8Ci9MZW5ndGggNjQ3Ci9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
Cj4+CnN0cmVhbQ0KSImEVF1v2zAMfPev4GNWxKrlOEmzx2EfGFBswOa+DQhU
m4m1KpIhycmyXz9KtrtkbjE4QGyJPB6PJ3Hg9Nh9cvvpO4e9S3gB6QpWPIf1
JgeLyS55Vya3H3MKK3cJz1h2Bxk9/RvPV+FvzXOWrddQHpIs7hJiSgHZEsqK
lspTMpPao3VYeWk0mB34BuEolKy3rVGyOm+9RQSh67DzpvxJaSknVGJUvk9m
nUO7lVp6KdSY4dCDcLAzSpmTexuSFmwZMtKc8SLfxEzOoEaqfZAaY9WQRgR6
ENCmRgenxjiEVljUflhqxPEFHuKKdMD5kecLoc9pv0JfBQMoG+mAfkMv5U0y
u2o2lAj82bibM5BTUQI+YUdGIPV/4UJJbfwQCq+INkIEsYeEaRNzUk2RbgQU
Y+p+OEIpkN6NEFUjVU2iPfexGPuwGLDFJfUX5k391dj6BnTKRwhjQaGjmUjf
mM5HAWKdfjAXxEQ/KwbfsEXx3Fdk7Dy20Gkv1cCGZkvRw3Av68JQcEwf6171
lhZsveKbK2c9tGTlyhxaojO4OsgTKhPLVhB8a01F0FLvyU9EqqsqxBrrQaSp
v0iiLsqCv1qSSfrRCUdhpXhUUdW9pW7RBgU0/EZr5qGH18wRhR7m/OXh/r7v
J2eLO37VzopxtoKvnW+7fsAfyoSDhGQTz/oyK1hBZ31NQgCdbnoP98NNuCD+
vRf6jOJuyfL+Wph93k0EGcQgqYI34kbd0ZD6s0oN0o5F31kdosVUqwhARpG6
lpWII/Bmj2Hc0TywIxgFz5K+aMH5X9cgnIx9omLbtnukgO0Tnnty0/WtUHtj
qchhfnlpRf9Mg+liEYdwCTk2CPtHgAEADya9RgplbmRzdHJlYW0KZW5kb2Jq
CjQxIDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIC9UZXh0IF0KL0ZvbnQgPDwK
L0YyIDQgMCBSCj4+Ci9FeHRHU3RhdGUgPDwKL0dTMSA1IDAgUgo+Pgo+Pgpl
bmRvYmoKNDIgMCBvYmoKPDwKL1R5cGUgL0hhbGZ0b25lCi9IYWxmdG9uZVR5
cGUgMQovSGFsZnRvbmVOYW1lIChEZWZhdWx0KQovRnJlcXVlbmN5IDYwCi9B
bmdsZSA0NQovU3BvdEZ1bmN0aW9uIC9Sb3VuZAo+PgplbmRvYmoKNSAwIG9i
ago8PAovVHlwZSAvRXh0R1N0YXRlCi9TQSBmYWxzZQovT1AgZmFsc2UKL0hU
IC9EZWZhdWx0Cj4+CmVuZG9iago0IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9T
dWJ0eXBlIC9UeXBlMQovTmFtZSAvRjIKL0VuY29kaW5nIDQzIDAgUgovQmFz
ZUZvbnQgL0NvdXJpZXIKPj4KZW5kb2JqCjQzIDAgb2JqCjw8Ci9UeXBlIC9F
bmNvZGluZwovRGlmZmVyZW5jZXMgWyAwL2dyYXZlL2FjdXRlL2NpcmN1bWZs
ZXgvdGlsZGUvbWFjcm9uL2JyZXZlL2RvdGFjY2VudC9kaWVyZXNpcwovcmlu
Zy9jZWRpbGxhL2h1bmdhcnVtbGF1dC9vZ29uZWsvY2Fyb24vZG90bGVzc2kv
YnVsbGV0L2J1bGxldAovYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1
bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldAovYnVsbGV0L2J1bGxldC9idWxs
ZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldAogMzkvcXVv
dGVzaW5nbGUgOTYvZ3JhdmUgMTI3L2J1bGxldC9idWxsZXQvYnVsbGV0L3F1
b3Rlc2luZ2xiYXNlL2Zsb3Jpbi9xdW90ZWRibGJhc2UKL2VsbGlwc2lzL2Rh
Z2dlci9kYWdnZXJkYmwvY2lyY3VtZmxleC9wZXJ0aG91c2FuZC9TY2Fyb24v
Z3VpbHNpbmdsbGVmdC9PRQovYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0
L3F1b3RlbGVmdC9xdW90ZXJpZ2h0L3F1b3RlZGJsbGVmdC9xdW90ZWRibHJp
Z2h0Ci9idWxsZXQvZW5kYXNoL2VtZGFzaC90aWxkZS90cmFkZW1hcmsvc2Nh
cm9uL2d1aWxzaW5nbHJpZ2h0L29lCi9idWxsZXQvYnVsbGV0L1lkaWVyZXNp
cy9zcGFjZSAxNjQvY3VycmVuY3kgMTY2L2Jyb2tlbmJhciAxNjgvZGllcmVz
aXMvY29weXJpZ2h0Ci9vcmRmZW1pbmluZSAxNzIvbG9naWNhbG5vdC9oeXBo
ZW4vcmVnaXN0ZXJlZC9tYWNyb24vZGVncmVlL3BsdXNtaW51cy90d29zdXBl
cmlvcgovdGhyZWVzdXBlcmlvci9hY3V0ZS9tdSAxODMvcGVyaW9kY2VudGVy
ZWQvY2VkaWxsYS9vbmVzdXBlcmlvci9vcmRtYXNjdWxpbmUgMTg4L29uZXF1
YXJ0ZXIKL29uZWhhbGYvdGhyZWVxdWFydGVycyAxOTIvQWdyYXZlL0FhY3V0
ZS9BY2lyY3VtZmxleC9BdGlsZGUvQWRpZXJlc2lzL0FyaW5nCi9BRS9DY2Vk
aWxsYS9FZ3JhdmUvRWFjdXRlL0VjaXJjdW1mbGV4L0VkaWVyZXNpcy9JZ3Jh
dmUvSWFjdXRlCi9JY2lyY3VtZmxleC9JZGllcmVzaXMvRXRoL050aWxkZS9P
Z3JhdmUvT2FjdXRlL09jaXJjdW1mbGV4L090aWxkZQovT2RpZXJlc2lzL211
bHRpcGx5L09zbGFzaC9VZ3JhdmUvVWFjdXRlL1VjaXJjdW1mbGV4L1VkaWVy
ZXNpcy9ZYWN1dGUKL1Rob3JuL2dlcm1hbmRibHMvYWdyYXZlL2FhY3V0ZS9h
Y2lyY3VtZmxleC9hdGlsZGUvYWRpZXJlc2lzL2FyaW5nCi9hZS9jY2VkaWxs
YS9lZ3JhdmUvZWFjdXRlL2VjaXJjdW1mbGV4L2VkaWVyZXNpcy9pZ3JhdmUv
aWFjdXRlCi9pY2lyY3VtZmxleC9pZGllcmVzaXMvZXRoL250aWxkZS9vZ3Jh
dmUvb2FjdXRlL29jaXJjdW1mbGV4L290aWxkZQovb2RpZXJlc2lzL2Rpdmlk
ZS9vc2xhc2gvdWdyYXZlL3VhY3V0ZS91Y2lyY3VtZmxleC91ZGllcmVzaXMv
eWFjdXRlCi90aG9ybi95ZGllcmVzaXMKXQo+PgplbmRvYmoKMSAwIG9iago8
PAovVHlwZSAvUGFnZQovUGFyZW50IDYgMCBSCi9SZXNvdXJjZXMgMyAwIFIK
L0NvbnRlbnRzIDIgMCBSCj4+CmVuZG9iago3IDAgb2JqCjw8Ci9UeXBlIC9Q
YWdlCi9QYXJlbnQgNiAwIFIKL1Jlc291cmNlcyA5IDAgUgovQ29udGVudHMg
OCAwIFIKPj4KZW5kb2JqCjEwIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJl
bnQgNiAwIFIKL1Jlc291cmNlcyAxMiAwIFIKL0NvbnRlbnRzIDExIDAgUgo+
PgplbmRvYmoKMTMgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCA2IDAg
UgovUmVzb3VyY2VzIDE1IDAgUgovQ29udGVudHMgMTQgMCBSCj4+CmVuZG9i
agoxNiAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDYgMCBSCi9SZXNv
dXJjZXMgMTggMCBSCi9Db250ZW50cyAxNyAwIFIKPj4KZW5kb2JqCjE5IDAg
b2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgNiAwIFIKL1Jlc291cmNlcyAy
MSAwIFIKL0NvbnRlbnRzIDIwIDAgUgo+PgplbmRvYmoKMjIgMCBvYmoKPDwK
L1R5cGUgL1BhZ2UKL1BhcmVudCA2IDAgUgovUmVzb3VyY2VzIDI0IDAgUgov
Q29udGVudHMgMjMgMCBSCj4+CmVuZG9iagoyNSAwIG9iago8PAovVHlwZSAv
UGFnZQovUGFyZW50IDYgMCBSCi9SZXNvdXJjZXMgMjcgMCBSCi9Db250ZW50
cyAyNiAwIFIKPj4KZW5kb2JqCjI4IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9Q
YXJlbnQgNiAwIFIKL1Jlc291cmNlcyAzMCAwIFIKL0NvbnRlbnRzIDI5IDAg
Ugo+PgplbmRvYmoKMzEgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCA2
IDAgUgovUmVzb3VyY2VzIDMzIDAgUgovQ29udGVudHMgMzIgMCBSCj4+CmVu
ZG9iagozNCAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDM4IDAgUgov
UmVzb3VyY2VzIDM2IDAgUgovQ29udGVudHMgMzUgMCBSCj4+CmVuZG9iagoz
OSAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDM4IDAgUgovUmVzb3Vy
Y2VzIDQxIDAgUgovQ29udGVudHMgNDAgMCBSCj4+CmVuZG9iago2IDAgb2Jq
Cjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbMSAwIFIgNyAwIFIgMTAgMCBSIDEz
IDAgUiAxNiAwIFIgMTkgMCBSIDIyIDAgUiAyNSAwIFIgMjggMCBSIDMxIDAg
Ul0KL0NvdW50IDEwCi9QYXJlbnQgMzcgMCBSCj4+CmVuZG9iagozOCAwIG9i
ago8PAovVHlwZSAvUGFnZXMKL0tpZHMgWzM0IDAgUiAzOSAwIFJdCi9Db3Vu
dCAyCi9QYXJlbnQgMzcgMCBSCj4+CmVuZG9iagozNyAwIG9iago8PAovVHlw
ZSAvUGFnZXMKL0tpZHMgWzYgMCBSIDM4IDAgUiBdCi9Db3VudCAxMgovTWVk
aWFCb3ggWzAgMCA2MTIgNzkyXQo+PgplbmRvYmoKNDQgMCBvYmoKPDwKL1R5
cGUgL0NhdGFsb2cKL1BhZ2VzIDM3IDAgUgo+PgplbmRvYmoKNDUgMCBvYmoK
PDwKL0NyZWF0aW9uRGF0ZSAoRDoxOTk5MTAxNDEzMDU1NykKL1Byb2R1Y2Vy
IChBY3JvYmF0IERpc3RpbGxlciBDb21tYW5kIDMuMDEgZm9yIFNvbGFyaXMg
Mi4zIGFuZCBsYXRlciBcKFNQQVJDXCkpCi9DcmVhdG9yIChQU0NSSVBULkRS
ViBWZXJzaW9uIDQuMCkKL1RpdGxlIChNaWNyb3NvZnQgV29yZCAtIFJldmlz
ZWRQYXRocHJvYzZjLmRvYykKPj4KZW5kb2JqCnhyZWYKMCA0NgowMDAwMDAw
MDAwIDY1NTM1IGYgCjAwMDAwMTU2NTEgMDAwMDAgbiAKMDAwMDAwMDAxNiAw
MDAwMCBuIAowMDAwMDAxMzgzIDAwMDAwIG4gCjAwMDAwMTQxNTAgMDAwMDAg
biAKMDAwMDAxNDA3OSAwMDAwMCBuIAowMDAwMDE2NjQzIDAwMDAwIG4gCjAw
MDAwMTU3MzEgMDAwMDAgbiAKMDAwMDAwMTQ3NyAwMDAwMCBuIAowMDAwMDAy
NDU1IDAwMDAwIG4gCjAwMDAwMTU4MTEgMDAwMDAgbiAKMDAwMDAwMjU0OSAw
MDAwMCBuIAowMDAwMDAzOTE2IDAwMDAwIG4gCjAwMDAwMTU4OTQgMDAwMDAg
biAKMDAwMDAwNDAxMSAwMDAwMCBuIAowMDAwMDA1MTk5IDAwMDAwIG4gCjAw
MDAwMTU5NzcgMDAwMDAgbiAKMDAwMDAwNTI5NCAwMDAwMCBuIAowMDAwMDA2
NDQ2IDAwMDAwIG4gCjAwMDAwMTYwNjAgMDAwMDAgbiAKMDAwMDAwNjU0MSAw
MDAwMCBuIAowMDAwMDA3NTIzIDAwMDAwIG4gCjAwMDAwMTYxNDMgMDAwMDAg
biAKMDAwMDAwNzYxOCAwMDAwMCBuIAowMDAwMDA4NTk3IDAwMDAwIG4gCjAw
MDAwMTYyMjYgMDAwMDAgbiAKMDAwMDAwODY5MiAwMDAwMCBuIAowMDAwMDA5
NjQ0IDAwMDAwIG4gCjAwMDAwMTYzMDkgMDAwMDAgbiAKMDAwMDAwOTczOSAw
MDAwMCBuIAowMDAwMDEwNzk0IDAwMDAwIG4gCjAwMDAwMTYzOTIgMDAwMDAg
biAKMDAwMDAxMDg4OSAwMDAwMCBuIAowMDAwMDExODM3IDAwMDAwIG4gCjAw
MDAwMTY0NzUgMDAwMDAgbiAKMDAwMDAxMTkzMiAwMDAwMCBuIAowMDAwMDEz
MDQ2IDAwMDAwIG4gCjAwMDAwMTY4NTkgMDAwMDAgbiAKMDAwMDAxNjc3OCAw
MDAwMCBuIAowMDAwMDE2NTU5IDAwMDAwIG4gCjAwMDAwMTMxNDEgMDAwMDAg
biAKMDAwMDAxMzg2MSAwMDAwMCBuIAowMDAwMDEzOTU2IDAwMDAwIG4gCjAw
MDAwMTQyNDUgMDAwMDAgbiAKMDAwMDAxNjk1MCAwMDAwMCBuIAowMDAwMDE3
MDAxIDAwMDAwIG4gCnRyYWlsZXIKPDwKL1NpemUgNDYKL1Jvb3QgNDQgMCBS
Ci9JbmZvIDQ1IDAgUgovSUQgWzxhZDJhMWNlZmNjMjM3OTcwYmUyYjA5MDFi
MjBmMzQwOT48YWQyYTFjZWZjYzIzNzk3MGJlMmIwOTAxYjIwZjM0MDk+XQo+
PgpzdGFydHhyZWYKMTcyMTgKJSVFT0YK

--Singular_of_Boars_835_000--


Received: from mailhost.msc.es (mailhost.msc.es [195.53.79.2]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA22292 for <[e-mail]>; Thu, 14 Oct 1999 09:17:55 -0700 (PDT)
From: [e-mail]
Received: from mmsc00003.msc.es ([10.15.5.26]) by mailhost.msc.es (Netscape Mail Server v2.02) with ESMTP id AAA14993 for <[e-mail]>; Thu, 14 Oct 1999 18:21:54 +0200
Received: by MMSC00003 with Internet Mail Service (5.5.2448.0) id <475HYBYB>; Thu, 14 Oct 1999 18:19:09 +0200
Message-ID: <[e-mail]>
To: [e-mail]
Subject: unsubscribe
Date: Thu, 14 Oct 1999 18:03:54 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain


Received: from server.rowe.com ([208.249.160.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA21995 for <[e-mail]>; Thu, 14 Oct 1999 09:10:46 -0700 (PDT)
Received: from SSODT (unverified [63.72.226.63]) by server.rowe.com (Rockliffe SMTPRA 3.4.2) with ESMTP id <[e-mail]>; Thu, 14 Oct 1999 11:59:11 -0400
From: "Steve Sodt" <[e-mail]>
To: "Phillip M Hallam-Baker" <[e-mail]>, "Ed Gerck" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Sentient applications, was Re: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Thu, 14 Oct 1999 11:58:17 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
In-Reply-To: <003c01bf1659$c47eadc0$[e-mail]>
Disposition-Notification-To: "Steve Sodt" <[e-mail]>

Just an aside, I've also heard it argued that - paraphrased - knowledge
enables the use of information, implying that it is a prerequisite to the
effective use of information.  In this sense knowledge is independent, and
information dependent.  Sorry to interject any unwelcome simplemindedness.


-----Original Message-----
From: Phillip M Hallam-Baker [mailto:[e-mail]]
Sent: Thursday, October 14, 1999 11:36 AM
To: Ed Gerck
Cc: '[e-mail]'
Subject: RE: Sentient applications, was Re: FW: OCSP-X Internet Draft:
Extensions to OCSP


Ed,

	The ability to use knowledge is not generally considered a
sufficient requirement for sentience. Knowledge is simply information
that can be used.

	The language used would be appropriate if a human were
performing the task, it is therefore appropriate if a machine replaces
the human.

	I don't find it usefull to revisit Searle's Chineese room on
an IETF mailing list. The only reason that Searle's argument is
so much discussed is that it is so bad that everyone has their own
favourite means of arguing against it.

		Phill





Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA21597 for <[e-mail]>; Thu, 14 Oct 1999 08:55:53 -0700 (PDT)
Received: by balinese.baltimore.ie; id QAA10541; Thu, 14 Oct 1999 16:57:56 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma010501; Thu, 14 Oct 99 16:57:36 +0100
Received: from baltimore.ie ([192.168.21.62]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA31409; Thu, 14 Oct 1999 16:57:35 +0100
Message-ID: <[e-mail]>
Date: Thu, 14 Oct 1999 16:58:36 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linn, John" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, xme <[e-mail]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

> I don't think that the viability or utility of offloaded validation is
> something which would vary as a function of the application protocol(s) with
> which the validated certificates are being used.  It's a design tradeoff
> (probably more visible within PKI provider layers than in their consumer
> applications) which incurs additional reliance on a central server but
> reduces the amount of data which must be propagated to the clients in order
> for validation to be performed.

Well, some of the arguments in SCVP and OCSP-X relate to
"footprint", "device complexity" etc. One of the questions
I'd want answered is how these arguments stand up in
real cases - if such protocols don't actually reduce
the footprint etc. when used in real applications
then the arguments fall.

There are also issues to do with mapping from 
application specific naming to certificates. E.g.
if I want to encrypt a mail for someone, do I
first get their cert, then check with the server
for a valid path, or do I send up the email
address? The answers to such questions may well
mean that the claimed centralisation of policy
isn't really there (in addition to also affecting
the footprint stuff again).

Another reason for wanting to see the effect
of this is that it changes the trust model
of any PKI consuming application, and given
the ways things are implemented, potentially
without the application being modified. I'm
concerned that replacing a current PKI library 
(which has path validation) with one with 
only remote path validaiton may open up 
new vulnerabilities. Maybe I'm just stupid, 
but I want to see what the consequences would 
be before recommending this.

Basically, in the absence of worked cases, we're
assuming a lot in saying that such protocols 
should be on the standards track.

> If I understood earlier discussion on this thread correctly, Stephen had
> already agreed about the merits of support for server-based path
> construction.  If a client depends on its server for path construction
> purposes, it's already accepted the dependency on server availability; given
> this acceptance, I don't see a strong availability-oriented argument against
> broader scope for the server-side functions.  By extending OCSP (already
> accepted as an on-line service trusted for validation support purposes), the
> proposal isn't adding an additional attack target, though it arguably makes
> the existing target more attractive by broadening the impact of a successful
> compromise.

Not quite. Paths can be cached and re-used. A clever client
(of a path constructing server) could even relate them to 
build a "picture" of the PKI which is relevant for it.
The protocol I'd like to see would also have a "didn't
like that path, can you find another?" option for the
client to use. This means that the server doesn't have to
be trusted for much, nor need it be as "available" as
a putative SCVP/OCSP-X server.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.imc.org (8.9.3/8.9.3) with SMTP id IAA21230 for <[e-mail]>; Thu, 14 Oct 1999 08:35:32 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 Oct 1999 15:36:28 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA24671; Thu, 14 Oct 1999 11:32:00 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <4YXDADSA>; Thu, 14 Oct 1999 11:39:07 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: "Linn, John" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Thu, 14 Oct 1999 11:44:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Stephen wrote:

> > I fully agree with the additional explanations you have provided.
> 
> 'Fraid I don't, not "fully" anyway. Like I said in 
> my previous mail, I'd still love to see a worked case 
> showing why its a good thing to use a server to 
> construct *and* validate *all* certificate paths
> that a client will *ever* use. Even for one 
> application, (e.g. TLS or S/MIME), I'm far from
> convinced that this is a good approach. Until
> I do see such an example, I'll be very sceptical.

I don't think that the viability or utility of offloaded validation is
something which would vary as a function of the application protocol(s) with
which the validated certificates are being used.  It's a design tradeoff
(probably more visible within PKI provider layers than in their consumer
applications) which incurs additional reliance on a central server but
reduces the amount of data which must be propagated to the clients in order
for validation to be performed.  

> 
> (Don't forget, this isn't free, we'd be creating
> a new highly attractive target for attacks, that
> also has to be highly available and widely
> contactable! Just imagine using this if you had
> a mobile IP connection. Yuk!)

If I understood earlier discussion on this thread correctly, Stephen had
already agreed about the merits of support for server-based path
construction.  If a client depends on its server for path construction
purposes, it's already accepted the dependency on server availability; given
this acceptance, I don't see a strong availability-oriented argument against
broader scope for the server-side functions.  By extending OCSP (already
accepted as an on-line service trusted for validation support purposes), the
proposal isn't adding an additional attack target, though it arguably makes
the existing target more attractive by broadening the impact of a successful
compromise.     

--jl


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA21019 for <[e-mail]>; Thu, 14 Oct 1999 08:33:08 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA04522; Thu, 14 Oct 1999 08:32:39 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA15176; Thu, 14 Oct 1999 08:34:16 -0700 (PDT)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SF5S3PBW; Thu, 14 Oct 1999 08:34:17 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Ed Gerck" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Sentient applications, was Re: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Thu, 14 Oct 1999 11:35:39 -0400
Message-ID: <003c01bf1659$c47eadc0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Ed,

	The ability to use knowledge is not generally considered a
sufficient requirement for sentience. Knowledge is simply information
that can be used.

	The language used would be appropriate if a human were 
performing the task, it is therefore appropriate if a machine replaces
the human.

	I don't find it usefull to revisit Searle's Chineese room on
an IETF mailing list. The only reason that Searle's argument is
so much discussed is that it is so bad that everyone has their own
favourite means of arguing against it.

		Phill





Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA18742 for <[e-mail]>; Thu, 14 Oct 1999 06:21:04 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id PAA23348; Thu, 14 Oct 1999 15:22:39 +0200
Message-ID: <[e-mail]>
Date: Thu, 14 Oct 1999 15:22:34 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen,

You made a good guess !

So at least you got one example, but you might be right to say
that's not what you read SCVP or OCSP-X are trying to address
though.

Denis

 
> John, Denis,
> 
> Denis Pinkas wrote:
> >
> > John,
> >
> > I fully agree with the additional explanations you have provided.
> 
> 'Fraid I don't, not "fully" anyway. Like I said in
> my previous mail, I'd still love to see a worked case
> showing why its a good thing to use a server to
> construct *and* validate *all* certificate paths
> that a client will *ever* use. Even for one
> application, (e.g. TLS or S/MIME), I'm far from
> convinced that this is a good approach. Until
> I do see such an example, I'll be very sceptical.
> 
> (Don't forget, this isn't free, we'd be creating
> a new highly attractive target for attacks, that
> also has to be highly available and widely
> contactable! Just imagine using this if you had
> a mobile IP connection. Yuk!)
> 
> OTOH, I do see a use for such a service for
> Denis' purpose, which, I guess, is to figure out
> whether a certificate was valid at some time
> in the past as part of evaluating the evidence
> for NR purposes. That's not what I read SCVP or
> OCSP-X as trying to address though.
> 
> Stephen.
> 
> >
> > Denis
> >
> > > Denis proposed the following as a candidate functional scope for an OCSP-X:
> > >
> > > >
> > > > 1) validating a certificate * for a given time * against some rules
> > > > which would desribe an acceptable certification *forest* to be used
> > > > (a forest has several trees and thus several roots to be fully
> > > > explicit).
> > > >
> > > > 2) giving back to the user the certification path (i.e. the
> > > > certificate identifiers - not necessarilly the certificates
> > > > themselves) that have been used * for that given time * for the
> > > > validation, including the relevant revocation (i.e. CRLs) or status
> > > > (i.e. OSCP responses) information.
> > > >
> > > > This would be quite sufficient at the time being.
> > > >
> > >
> > > I agree that this would be a useful core set.  Further, return of (2) could
> > > be optional.  It would be useful to those clients which wish to retrace the
> > > path validation performed by the server, to display the path if needed, or
> > > to record information for audit purposes.  If none of these cases hold,
> > > return of the data collected by the server during the validation process
> > > seems redundant.
> > >
> > > --jl
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 61 Fitzwilliam Lane,                    fax: [phone]
> Dublin 2.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA18546 for <[e-mail]>; Thu, 14 Oct 1999 06:18:06 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA08427 for <[e-mail]>; Thu, 14 Oct 1999 15:20:09 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 14 Oct 1999 15:20:09 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA01961 for <[e-mail]>; Thu, 14 Oct 1999 15:20:08 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA24510 for [e-mail]; Thu, 14 Oct 1999 15:20:08 +0200 (MET DST)
Date: Thu, 14 Oct 1999 15:20:08 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dcs-02.txt

Please ignore the following draft. 

A new version will be send today or tomorrow. 

	Title		: Internet X.509 Public Key Infrastructure Data   
                          Validation and Certification Server Protocols
	Author(s)	: C. Adams, P. Sylvester, M. Zolotarev,  R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-02.txt
	Pages		: 26
	Date		: 13-Oct-99
	



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA18359 for <[e-mail]>; Thu, 14 Oct 1999 06:15:45 -0700 (PDT)
Received: by balinese.baltimore.ie; id OAA23932; Thu, 14 Oct 1999 14:17:46 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma023864; Thu, 14 Oct 99 14:16:54 +0100
Received: from baltimore.ie ([192.168.21.62]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA22245; Thu, 14 Oct 1999 14:16:54 +0100
Message-ID: <[e-mail]>
Date: Thu, 14 Oct 1999 14:17:55 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: "Linn, John" <[e-mail]>, "'[e-mail]'" <[e-mail]>, xme <[e-mail]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John, Denis,


Denis Pinkas wrote:
> 
> John,
> 
> I fully agree with the additional explanations you have provided.

'Fraid I don't, not "fully" anyway. Like I said in 
my previous mail, I'd still love to see a worked case 
showing why its a good thing to use a server to 
construct *and* validate *all* certificate paths
that a client will *ever* use. Even for one 
application, (e.g. TLS or S/MIME), I'm far from
convinced that this is a good approach. Until
I do see such an example, I'll be very sceptical.

(Don't forget, this isn't free, we'd be creating
a new highly attractive target for attacks, that
also has to be highly available and widely
contactable! Just imagine using this if you had
a mobile IP connection. Yuk!)

OTOH, I do see a use for such a service for
Denis' purpose, which, I guess, is to figure out 
whether a certificate was valid at some time
in the past as part of evaluating the evidence
for NR purposes. That's not what I read SCVP or
OCSP-X as trying to address though.

Stephen.


> 
> Denis
> 
> > Denis proposed the following as a candidate functional scope for an OCSP-X:
> >
> > >
> > > 1) validating a certificate * for a given time * against some rules
> > > which would desribe an acceptable certification *forest* to be used
> > > (a forest has several trees and thus several roots to be fully
> > > explicit).
> > >
> > > 2) giving back to the user the certification path (i.e. the
> > > certificate identifiers - not necessarilly the certificates
> > > themselves) that have been used * for that given time * for the
> > > validation, including the relevant revocation (i.e. CRLs) or status
> > > (i.e. OSCP responses) information.
> > >
> > > This would be quite sufficient at the time being.
> > >
> >
> > I agree that this would be a useful core set.  Further, return of (2) could
> > be optional.  It would be useful to those clients which wish to retrace the
> > path validation performed by the server, to display the path if needed, or
> > to record information for audit purposes.  If none of these cases hold,
> > return of the data collected by the server during the validation process
> > seems redundant.
> >
> > --jl

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA17776 for <[e-mail]>; Thu, 14 Oct 1999 05:38:04 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id OAA24168; Thu, 14 Oct 1999 14:39:33 +0200
Message-ID: <[e-mail]>
Date: Thu, 14 Oct 1999 14:39:29 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: "Linn, John" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

I fully agree with the additional explanations you have provided.

Denis

> Denis proposed the following as a candidate functional scope for an OCSP-X:
> 
> >
> > 1) validating a certificate * for a given time * against some rules
> > which would desribe an acceptable certification *forest* to be used
> > (a forest has several trees and thus several roots to be fully
> > explicit).
> >
> > 2) giving back to the user the certification path (i.e. the
> > certificate identifiers - not necessarilly the certificates
> > themselves) that have been used * for that given time * for the
> > validation, including the relevant revocation (i.e. CRLs) or status
> > (i.e. OSCP responses) information.
> >
> > This would be quite sufficient at the time being.
> >
> 
> I agree that this would be a useful core set.  Further, return of (2) could
> be optional.  It would be useful to those clients which wish to retrace the
> path validation performed by the server, to display the path if needed, or
> to record information for audit purposes.  If none of these cases hold,
> return of the data collected by the server during the validation process
> seems redundant.
> 
> --jl


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA14951 for <[e-mail]>; Thu, 14 Oct 1999 03:51:02 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24412; Thu, 14 Oct 1999 06:52:34 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ocspx-00.txt
Date: Thu, 14 Oct 1999 06:52:34 -0400
Sender: [e-mail]

--NextPart

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

	Title		: OCSP Extensions
	Author(s)	: P. Hallam-Baker
	Filename	: draft-ietf-pkix-ocspx-00.txt
	Pages		: 16
	Date		: 13-Oct-99
	
The OCSP protocol [RFC2560] enables online validation of the reliability of a digital certificate. RFC2560  defines a mandatory-to-implement mechanism supporting the revocation status of the certificate and defines and optional extension mechanism to support a richer set of semantics (e.g. full path validation by the OCSP server).

This document defines Internet-standard  extensions to OCSP that enable a client to delegate processing of certificate acceptance functions to a 
trusted server. The client may control the degree to which delegation takes place. In addition limited support is provided for delegating authorization decisions.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ocspx-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA14931 for <[e-mail]>; Thu, 14 Oct 1999 03:50:54 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24398; Thu, 14 Oct 1999 06:52:27 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dcs-02.txt
Date: Thu, 14 Oct 1999 06:52:26 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Data   
                          Validation and Certification Server Protocols
	Author(s)	: C. Adams, P. Sylvester, M. Zolotarev,  R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-02.txt
	Pages		: 26
	Date		: 13-Oct-99
	
This document describes a general data validation and certification
service and the protocols to be used when communicating with it.  The
Data Validation and Certification Server is a Trusted Third Party
(TTP) that can be used as one component in building reliable non-
repudiation services (see [ISONR]).
Useful Data Validation and Certification Server responsibilities in a
PKI are to validate signed documents and to assert the validity of
public key certificates at a given time.
We give examples of how to use the Data Certification Server to
extend the lifetime of a signature beyond key expiry or revocation
and to query the Data Certification Server regarding the status of a
public key certificate.
<draft>Note: The initial drafts of this protocol used the
abbreviation DCS instead of DVCS.</draft>

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dcs-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from csmes.ncsl.nist.gov ([129.6.54.2]) by mail.imc.org (8.9.3/8.9.3) with SMTP id OAA15116 for <[e-mail]>; Wed, 13 Oct 1999 14:31:33 -0700 (PDT)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id RAA08732 for <[e-mail]>; Wed, 13 Oct 1999 17:33:48 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 13 Oct 1999 17:36:39 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: updated path validation text
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_939864999==_"

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


Folks,

We are currently editing "son-of-RFC 2459" which should - no, *will* - be
posted by 5PM on October 22 (that is, before the Washington meeting
cut-off).  In general, that should be plenty of time to review and discuss
before the meeting.  Most of it is minor stuff, and pretty straightforward.

However, the current draft of section 6.1 (the path validation algorithm)
is significantly more detailed than the section 6.1 in RFC 2459.  It
probably bears additional review, so I wanted to circulate it ahead of the
rest of the I-D.  There are two basic changes:

#1 The old text left out details that appeared elsewhere in the
specification.  The new text is more comprehensive, addressing every field
or extension that affects whether a certification path is valid.

For example, the algorithm in section 6.1 assumed that unique identifiers
did not appear.  However, section 4.1.2.8 and 6.1 of RFC 2459 require that
UIDs be processed if they appear in a certificate, and this clearly affects
path validation.  The reader needed to augment the algorithm in 6.1 with
information from other sections of the document.  The new text explicitly
addresses the processing rules when UIDs apper in subject or issuer names.
This increases the bulk of the document, but should make it significantly
easier to use.

#2 ISO will be meeting Oct. 28 to consider some bug fixes that affect
processing of the certificate policies extensions and related constraints.
The bugs were important, causing unexpected acceptance of certain
certification paths!  Our goal is to incorporate the bug fixes into
"son-of-RFC 2459" so that policy and path processing in the ISO and IETF
specifications are equivalent. This text incorporates what we *expect* to
be the ouput of the Oct. 28 ISO meeting.  At least, it matches several
countries ballot comments...

Anyway, I have attached my current draft of section 6.1.  I believe this
text to be comprehensive, and I think it is in line with the changes ISO
will *probably* make regarding the defect report.

Please take a long, hard look at this text!  Your comments are appreciated!

Thanks,

Tim Polk

P.S.  Sorry about the Word attachment.  The straightforward conversion to
text lost all the formatting/indenting , and I think that really helps the
readers' comprehension.  If anyone asks, I will convert it to a nice UNIX
text file and repost.  Otherwise, it will get fixed when I convert to
nroff...
--=====================_939864999==_
Content-Type: application/octet-stream; name="RevisedPathproc6c.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="RevisedPathproc6c.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAUQAAAAAAAAAA
EAAAUgAAAAEAAAD+////AAAAAFAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////c
pWgAM+AJBAAAAABlAAAAAAAAAAAAAAAAAwAAeHAAAGCeAAAAAAAAAAAAAAAAAAAAAAAAeG0AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAAFYBAAAAiAAAVgEAAFaJAAAAAAAAVokA
AAAAAABWiQAAAAAAAFaJAAAAAAAAVokAABQAAAAwigAAAAAAADCKAAAAAAAAMIoAAAAAAAAwigAA
AAAAADCKAAAAAAAAMIoAAAoAAAA6igAAQAAAADCKAAAAAAAAMZ0AAFcAAAB6igAAAAAAAHqKAAAA
AAAAeooAAAAAAAB6igAAAAAAAHqKAAAAAAAAeooAAAAAAAB6igAAAAAAAHqKAAAAAAAA+ZUAAAIA
AAD7lQAAAAAAAPuVAAAAAAAA+5UAAEgAAABDlgAAaAMAAKuZAABoAwAAE50AAB4AAACInQAAWAAA
AOCdAACAAAAAMZ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAVokAAAAAAAB6igAAAAAAAAAAOQA6AAEA
CgB6igAAAAAAAHqKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHqKAAAAAAAAeooAAAAAAAAxnQAAAAAA
ABCVAAAAAAAAVokAAAAAAABWiQAAAAAAAHqKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHqKAAAAAAAA
EJUAAAAAAAAQlQAAAAAAABCVAAAAAAAAeooAAJYKAABWiQAAAAAAAHqKAAAAAAAAVokAAAAAAAB6
igAAAAAAAPmVAAAAAAAAAAAAAAAAAAAAxoYZ8RS/AWqJAABKAAAAtIkAAHwAAABWiQAAAAAAAFaJ
AAAAAAAAVokAAAAAAABWiQAAAAAAAHqKAAAAAAAA+ZUAAAAAAAAQlQAA6QAAABCVAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANNi4xIEJhc2ljIFBhdGggVmFsaWRhdGlvbg0NVGhp
cyB0ZXh0IGRlc2NyaWJlcyBhbiBhbGdvcml0aG0gZm9yIFguNTA5IHBhdGggcHJvY2Vzc2luZy4g
IEEgY29uZm9ybWFudCBpbXBsZW1lbnRhdGlvbiBTSEFMTCBpbmNsdWRlIGFuIFguNTA5IHBhdGgg
cHJvY2Vzc2luZyBwcm9jZWR1cmUgdGhhdCBpcyBmdW5jdGlvbmFsbHkgZXF1aXZhbGVudCB0byB0
aGUgZXh0ZXJuYWwgYmVoYXZpb3Igb2YgdGhpcyBhbGdvcml0aG0uDSANVGhpcyB0ZXh0IGFzc3Vt
ZXMgdGhhdCB0aGVyZSBpcyBhIHNpbmdsZSB0cnVzdCBhbmNob3IgZm9yIGNlcnRpZmljYXRpb24g
cGF0aCBwcm9jZXNzaW5nLCB3aGljaCBzaW1wbGlmaWVzIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUg
cGF0aCBwcm9jZXNzaW5nIHByb2NlZHVyZS4gQXMgbm90ZWQgYWJvdmUsIHRoaXMgcHJvY2VkdXJl
IGNhbiBiZSBleHRlbmRlZCB0byBhZGRyZXNzIG11bHRpcGxlIHRydXN0IGFuY2hvcnMuIFRoaXMg
aXMgZGlzY3Vzc2VkIGZ1cnRoZXIgaW4gU2VjdGlvbiA2LjIuDQ1BIGNlcnRpZmljYXRpb24gcGF0
aCBpcyBhIHNlcXVlbmNlIG9mIG4gY2VydGlmaWNhdGVzIHdoZXJlOg0NZm9yIGFsbCB4IGluIHsx
LCAuLi4sIG4tMX0sIHRoZSBzdWJqZWN0IG9mIGNlcnRpZmljYXRlIHggaXMgdGhlIGlzc3VlciBv
ZiBjZXJ0aWZpY2F0ZSB4KzE7IA0NY2VydGlmaWNhdGUgMSBpcyBpc3N1ZWQgYnkgdGhlIHRydXN0
IGFuY2hvcjsgYW5kDSANY2VydGlmaWNhdGUgbiBpcyB0aGUgZW5kIGVudGl0eSBjZXJ0aWZpY2F0
ZS4NDVRoZSBwcmltYXJ5IGdvYWwgb2YgcGF0aCB2YWxpZGF0aW9uIGlzIHRvIHZlcmlmeSB0aGUg
YmluZGluZyBiZXR3ZWVuIGEgc3ViamVjdCBkaXN0aW5ndWlzaGVkIG5hbWUgb3Igc3ViamVjdCBh
bHRlcm5hdGl2ZSBuYW1lIGFuZCBzdWJqZWN0IHB1YmxpYyBrZXksIGFzIHJlcHJlc2VudGVkIGlu
IHRoZSAiZW5kIGVudGl0eSIgY2VydGlmaWNhdGUsIGJhc2VkIG9uIHRoZSBwdWJsaWMga2V5IG9m
IHRoZSAibW9zdC10cnVzdGVkIENBIi4gIFRoaXMgcmVxdWlyZXMgb2J0YWluaW5nIGEgc2VxdWVu
Y2Ugb2YgY2VydGlmaWNhdGVzIHRoYXQgc3VwcG9ydCB0aGF0IGJpbmRpbmcuICBUaGUgcHJvY2Vk
dXJlIHBlcmZvcm1lZCB0byBvYnRhaW4gdGhpcyBzZXF1ZW5jZSBpcyBvdXRzaWRlIHRoZSBzY29w
ZSBvZiB0aGlzIHNlY3Rpb24uDQ1UbyBtZWV0IHRoaXMgZ29hbCwgdGhlIHBhdGggdmFsaWRhdGlv
biBwcm9jZXNzIHZlcmlmaWVzLCBhbW9uZyBvdGhlciB0aGluZ3MsIHRoYXQgYSBwcm9zcGVjdGl2
ZSBjZXJ0aWZpY2F0aW9uIHBhdGggKGEgc2VxdWVuY2Ugb2YgbiBjZXJ0aWZpY2F0ZXMpIHNhdGlz
ZmllcyB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnM6DShpKSBmb3IgYWxsIHggaW4gezEsIC4uLiwg
bi0xfSwgdGhlIHN1YmplY3Qgb2YgY2VydGlmaWNhdGUgeCBpcyB0aGUgaXNzdWVyIG9mIGNlcnRp
ZmljYXRlIHgrMTsgDShpaSkgY2VydGlmaWNhdGUgMSBpcyBpc3N1ZWQgYnkgdGhlIHRydXN0IGFu
Y2hvcjsNKGlpaSkgY2VydGlmaWNhdGUgbiBpcyB0aGUgZW5kIGVudGl0eSBjZXJ0aWZpY2F0ZTsg
YW5kDShpdikgZm9yIGFsbCB4IGluIHsxLCAuLi4sIG59LCB0aGUgY2VydGlmaWNhdGUgd2FzIHZh
bGlkIGF0IHRoZSB0aW1lIGluIHF1ZXN0aW9uLg0NQSBwYXJ0aWN1bGFyIGNlcnRpZmljYXRpb24g
cGF0aCBtYXkgbm90LCBob3dldmVyLCBiZSBhcHByb3ByaWF0ZSBmb3IgYWxsIGFwcGxpY2F0aW9u
cy4gIFRoZSBwYXRoIHZhbGlkYXRpb24gcHJvY2VzcyBhbHNvIGRldGVybWluZXMgdGhlIHNldCBv
ZiBjZXJ0aWZpY2F0ZSBwb2xpY2llcyB0aGF0IGFyZSB2YWxpZCBmb3IgdGhpcyBwYXRoLCBiYXNl
ZCBvbiB0aGUgY2VydGlmaWNhdGUgcG9saWNpZXMgZXh0ZW5zaW9uLCBwb2xpY3kgbWFwcGluZyBl
eHRlbnNpb24sIHBvbGljeSBjb25zdHJhaW50cyBleHRlbnNpb24sIGFuZCBpbmhpYml0IGFueS1w
b2xpY3kgZXh0ZW5zaW9uLiBUbyBhY2hpZXZlIHRoaXMsIHRoZSBwYXRoIHZhbGlkYXRpb24gYWxn
b3JpdGhtIGNvbnN0cnVjdHMgYSCTdmFsaWQgcG9saWN5IHRyZWWULiAgSWYgdGhlIHNldCBvZiBj
ZXJ0aWZpY2F0ZSBwb2xpY2llcyB0aGF0IGFyZSB2YWxpZCBmb3IgdGhpcyBwYXRoIGlzIG5vdCBl
bXB0eSB0aGUgcmVzdWx0IHdpbGwgYmUgYSB2YWxpZCBwb2xpY3kgdHJlZSBvZiBkZXB0aCBuLCBv
dGhlcndpc2UgdGhlIHJlc3VsdCB3aWxsIGJlIGEgTlVMTCB2YWxpZCBwb2xpY3kgdHJlZS4NDVRo
aXMgc2VjdGlvbiBwcmVzZW50cyB0aGUgYWxnb3JpdGhtIGluIGZvdXIgYmFzaWMgc3RlcHM6ICgx
KSBpbml0aWFsaXphdGlvbiwgKDIpIGJhc2ljIGNlcnRpZmljYXRlIHByb2Nlc3NpbmcsICgzKSBw
cmVwYXJhdGlvbiBmb3IgdGhlIG5leHQgY2VydGlmaWNhdGUsIGFuZCAoNCkgd3JhcC11cC4gIFN0
ZXBzICgxKSBhbmQgKDQpIGFyZSBwZXJmb3JtZWQgZXhhY3RseSBvbmNlLiAgU3RlcCAoMikgaXMg
cGVyZm9ybWVkIGZvciBhbGwgY2VydGlmaWNhdGVzIGluIHRoZSBwYXRoLiAgU3RlcCAoMykgaXMg
cGVyZm9ybWVkIGZvciBhbGwgY2VydGlmaWNhdGVzIGluIHRoZSBwYXRoIGV4Y2VwdCB0aGUgZmlu
YWwgY2VydGlmaWNhdGUuICBGaWd1cmUgMiBwcm92aWRlcyBhIGhpZ2gtbGV2ZWwgZmxvd2NoYXJ0
IG9mIHRoaXMgYWxnb3JpdGhtLg0NICAgICAgICAgICAgIC8tLS0tLS0tXA0gICAgICAgICAgICAg
fCBTVEFSVCB8DSAgICAgICAgICAgICBcLS0tLS0tLS8NICAgICAgICAgICAgICAgICB8DSAgICAg
ICAgICAgICAgICAgVg0gICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsNICAgICAgICAgfCBJbml0
aWFsaXphdGlvbiB8DSAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKw0gICAgICAgICAgICAgICAg
IHwNICAgICAgICAgICAgICAgICArPC0tLS0tLS0tLS0tLS0tLS0tLS0tKw0gICAgICAgICAgICAg
ICAgIHwgICAgICAgICAgICAgICAgICAgICB8DSAgICAgICAgICAgICAgICAgViAgICAgICAgICAg
ICAgICAgICAgIHwNICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgfA0gICAg
ICAgICB8ICBQcm9jZXNzIENlcnQgIHwgICAgICAgICAgICB8DSAgICAgICAgICstLS0tLS0tLS0t
LS0tLS0tKyAgICAgICAgICAgIHwNICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg
ICAgfA0gICAgICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICB8DSAgICAgICAgICs9
PT09PT09PT09PT09PT09KyAgICAgICAgICAgIHwNICAgICAgICAgfCAgSUYgTGFzdCBDZXJ0ICB8
ICAgICAgICAgICAgfA0gICAgICAgICB8ICAgIGluIFBhdGggICAgIHwgICAgICAgICAgICB8DSAg
ICAgICAgICs9PT09PT09PT09PT09PT09KyAgICAgICAgICAgIHwNICAgICAgICAgICB8ICAgICAg
ICAgICAgfCAgICAgICAgICAgICAgfA0gICAgICBUSEVOIHwgICAgICAgICAgICB8IEVMU0UgICAg
ICAgICB8DSAgICAgICAgICAgViAgICAgICAgICAgIFYgICAgICAgICAgICAgIHwNKy0tLS0tLS0t
LS0tLS0tLS0rICstLS0tLS0tLS0tLS0tLS0tKyAgfA18ICAgIFdyYXAgdXAgICAgIHwgfCAgUHJl
cGFyZSBmb3IgICB8ICB8DSstLS0tLS0tLS0tLS0tLS0tKyB8ICAgTmV4dCBDZXJ0ICAgIHwgIHwN
ICAgICAgICB8ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAgfA0gICAgICAgIFYgICAgICAg
ICAgICAgICB8ICAgICAgICAgICAgICB8DSAgICAvLS0tLS0tLVwgICAgICAgICAgICstLS0tLS0t
LS0tLS0tLSsNICAgIHwgU1RPUCAgfA0gICAgXC0tLS0tLS0vDQ1GaWd1cmUgMi4gIFBhdGggUHJv
Y2Vzc2luZyBGbG93Y2hhcnQNDTYuMS4xIElucHV0cw1UaGlzIGFsZ29yaXRobSBhc3N1bWVzIHRo
ZSBmb2xsb3dpbmcgc2V2ZW4gaW5wdXRzIGFyZSBwcm92aWRlZCB0byB0aGUgcGF0aCBwcm9jZXNz
aW5nIGxvZ2ljOg0NKGEpIGEgcHJvc3BlY3RpdmUgY2VydGlmaWNhdGlvbiBwYXRoIG9mIGxlbmd0
aCBuOw0NKGIpIHRoZSB0aW1lLCBULCBmb3Igd2hpY2ggdGhlIHZhbGlkaXR5IG9mIHRoZSBwYXRo
IHNob3VsZCBiZSBkZXRlcm1pbmVkLiAgKFRoaXMgbWF5IGJlIHRoZSBjdXJyZW50IGRhdGUvdGlt
ZSwgb3Igc29tZSBwb2ludCBpbiB0aGUgcGFzdC4pDQ0oYykgdXNlcl9pbml0aWFsX3BvbGljeV9z
ZXQ6ICBBIHNldCBvZiBjZXJ0aWZpY2F0ZSBwb2xpY3kgaWRlbnRpZmllcnMgbmFtaW5nIHRoZSBw
b2xpY2llcyB0aGF0IGFyZSBhY2NlcHRhYmxlIHRvIHRoZSBjZXJ0aWZpY2F0ZSB1c2VyLiBUaGUg
dXNlcl9pbml0aWFsX3BvbGljeV9zZXQgaGFzIHRoZSBzcGVjaWFsIHZhbHVlICJhbnktcG9saWN5
IiBpZiB0aGUgdXNlciBpcyBub3QgY29uY2VybmVkIGFib3V0IGNlcnRpZmljYXRlIHBvbGljeS4N
DShkKSB0cnVzdCBhbmNob3IgaW5mb3JtYXRpb24sIGRlc2NyaWJpbmcgYSBDQSB0aGF0IHNlcnZl
cyBhcyBhICJ0cnVzdCBhbmNob3IiIGZvciB0aGUgY2VydGlmaWNhdGlvbiBwYXRoLiAgVGhlIHRy
dXN0IGFuY2hvciBkZXNjcmliZXMgdGhlIGNlcnRpZmljYXRlIHVzZXKScyCTbW9zdC10cnVzdGVk
IENBlC4gIFRoZSB0cnVzdCBhbmNob3IgaW5mb3JtYXRpb24gaW5jbHVkZXM6DSgxKSB0aGUgdHJ1
c3RlZCBpc3N1ZXIgbmFtZSwNKDIpIG9wdGlvbmFsbHksIHRoZSB0cnVzdGVkIGlzc3VlciB1bmlx
dWUgaWRlbnRpZmllciwNKDMpIHRoZSB0cnVzdGVkIHB1YmxpYyBrZXkgYWxnb3JpdGhtLA0oNCkg
dGhlIHRydXN0ZWQgcHVibGljIGtleSwgYW5kDSg1KSBvcHRpb25hbGx5LCB0aGUgdHJ1c3RlZCBw
dWJsaWMga2V5IHBhcmFtZXRlcnMgYXNzb2NpYXRlZCB3aXRoIHRoZSBwdWJsaWMga2V5Lg0NVGhl
IHRydXN0IGFuY2hvciBpbmZvcm1hdGlvbiBtYXkgYmUgcHJvdmlkZWQgdG8gdGhlIHBhdGggcHJv
Y2Vzc2luZyBwcm9jZWR1cmUgaW4gdGhlIGZvcm0gb2YgYSAic2VsZi1zaWduZWQgY2VydGlmaWNh
dGUiLiAgVGhlIHRydXN0ZWQgYW5jaG9yIGluZm9ybWF0aW9uIGlzIHRydXN0ZWQgYmVjYXVzZSBp
dCB3YXMgZGVsaXZlcmVkIHRvIHRoZSBwYXRoIHByb2Nlc3NpbmcgcHJvY2VkdXJlIGJ5IHNvbWUg
dHJ1c3R3b3J0aHkgIm91dC1vZi1iYW5kIiBwcm9jZWR1cmUuICBJZiB0aGUgdHJ1c3RlZCBwdWJs
aWMga2V5IGFsZ29yaXRobSByZXF1aXJlcyBwYXJhbWV0ZXJzLCB0aGVuIHRoZSBwYXJhbWV0ZXJz
IGFyZSBwcm92aWRlZCBhbG9uZyB3aXRoIHRoZSB0cnVzdGVkIHB1YmxpYyBrZXkuDQ0oZSkgaW5p
dGlhbC1wb2xpY3ktbWFwcGluZy1pbmhpYml0LCB3aGljaCBpbmRpY2F0ZXMgaWYgcG9saWN5IG1h
cHBpbmcgaXMgYWxsb3dlZCBpbiB0aGUgY2VydGlmaWNhdGlvbiBwYXRoLg0NKGYpIGluaXRpYWwt
ZXhwbGljaXQtcG9saWN5LCB3aGljaCBpbmRpY2F0ZXMgaWYgdGhlIHBhdGggbXVzdCBiZSB2YWxp
ZCBmb3IgYXQgbGVhc3Qgb25lIG9mIHRoZSBjZXJ0aWZpY2F0ZSBwb2xpY2llcyBpbiB0aGUgdXNl
cl9pbml0aWFsX3BvbGljeV9zZXQuDQ0oZykgaW5pdGlhbC1hbnktcG9saWN5LWluaGliaXQsIHdo
aWNoIGluZGljYXRlcyB3aGV0aGVyIHRoZSBhbnktcG9saWN5IE9JRCBzaG91bGQgYmUgcHJvY2Vz
c2VkIGlmIGl0IGlzIGluY2x1ZGVkIGluIGEgY2VydGlmaWNhdGUuIA0NNi4xLjIgSW5pdGlhbGl6
YXRpb24NDVRoZSBpbml0aWFsaXphdGlvbiBwaGFzZSBlc3RhYmxpc2hlcyB0d2VsdmUgc3RhdGUg
dmFyaWFibGVzIGJhc2VkIHVwb24gdGhlIHNldmVuIGlucHV0czoNIA0oYSkgdmFsaWRfcG9saWN5
X3RyZWU6ICBBIHRyZWUgb2YgY2VydGlmaWNhdGUgcG9saWNpZXMgd2l0aCB0aGVpciBvcHRpb25h
bCBxdWFsaWZpZXJzOyBlYWNoIG9mIHRoZSBsZWF2ZXMgb2YgdGhlIHRyZWUgcmVwcmVzZW50cyBh
IHZhbGlkIHBvbGljeSBhdCB0aGlzIHN0YWdlIGluIHRoZSBjZXJ0aWZpY2F0aW9uIHBhdGggdmFs
aWRhdGlvbi4gSWYgdmFsaWQgcG9saWNpZXMgZXhpc3QgYXQgdGhpcyBzdGFnZSBpbiB0aGUgY2Vy
dGlmaWNhdGlvbiBwYXRoIHZhbGlkYXRpb24sIHRoZSBkZXB0aCBvZiB0aGUgdHJlZSBpcyBlcXVh
bCB0byB0aGUgbnVtYmVyIG9mIGNlcnRpZmljYXRlcyBpbiB0aGUgY2hhaW4gdGhhdCBoYXZlIGJl
ZW4gcHJvY2Vzc2VkLiBJZiB2YWxpZCBwb2xpY2llcyBkbyBub3QgZXhpc3QgYXQgdGhpcyBzdGFn
ZSBpbiB0aGUgY2VydGlmaWNhdGlvbiBwYXRoIHZhbGlkYXRpb24sIHRoZSB0cmVlIGlzIHNldCB0
byBOVUxMLiBPbmNlIHRoZSB0cmVlIGlzIHNldCB0byBOVUxMLCBwb2xpY3kgcHJvY2Vzc2luZyBj
ZWFzZXMuDQ1FYWNoIG5vZGUgaW4gdGhlIHZhbGlkX3BvbGljeV90cmVlIGluY2x1ZGVzIGZvdXIg
ZGF0YSBvYmplY3RzOiB0aGUgdmFsaWQgcG9saWN5LCBhIHNldCBvZiBhc3NvY2lhdGVkIHBvbGlj
eSBxdWFsaWZpZXJzLCBhIHNldCBvZiBvbmUgb3IgbW9yZSBleHBlY3RlZCBwb2xpY3kgdmFsdWVz
LCBhbmQgYSBjcml0aWNhbGl0eSBpbmRpY2F0b3IuICBJZiB0aGUgbm9kZSBpcyBhdCBkZXB0aCB4
LCB0aGUgY29tcG9uZW50cyBvZiB0aGUgbm9kZSBoYXZlIHRoZSBmb2xsb3dpbmcgc2VtYW50aWNz
Og0oaSkgVGhlIHZhbGlkX3BvbGljeSBpcyBhIHNpbmdsZSBwb2xpY3kgT0lEIHJlcHJlc2VudGlu
ZyBhIHZhbGlkIHBvbGljeSBmb3IgdGhlIHBhdGggb2YgbGVuZ3RoIHguDShpaSkgVGhlIHF1YWxp
Zmllcl9zZXQgaXMgYSBzZXQgb2YgcG9saWN5IHF1YWxpZmllcnMgYXNzb2NpYXRlZCB3aXRoIHRo
ZSB2YWxpZCBwb2xpY3kgaW4gY2VydGlmaWNhdGUgeC4NKGlpaSkgVGhlIGNyaXRpY2FsaXR5X2lu
ZGljYXRvciBpbmRpY2F0ZXMgd2hldGhlciB0aGUgY2VydGlmaWNhdGUgcG9saWN5IGV4dGVuc2lv
biBpbiBjZXJ0aWZpY2F0ZSB4IHdhcyBtYXJrZWQgYXMgY3JpdGljYWwuDShpdikgVGhlIGV4cGVj
dGVkX3BvbGljeV9zZXQgY29udGFpbnMgb25lIG9yIG1vcmUgcG9saWN5IE9JRHMgdGhhdCB3b3Vs
ZCBzYXRpc2Z5IHRoaXMgcG9saWN5IGluIHRoZSBjZXJ0aWZpY2F0ZSB4KzEuDQ1UaGUgaW5pdGlh
bCB2YWx1ZSBvZiB0aGUgdmFsaWRfcG9saWN5X3RyZWUgaXMgYSBzaW5nbGUgbm9kZSB3aXRoIHZh
bGlkX3BvbGljeSCTYW55LXBvbGljeZQsIGFuIGVtcHR5IHF1YWxpZmllcl9zZXQsIGFuIGV4cGVj
dGVkX3BvbGljeV9zZXQgd2l0aCB0aGUgc2luZ2xlIHZhbHVlIJNhbnktcG9saWN5lCwgYW5kIGEg
Y3JpdGljYWxpdHlfaW5kaWNhdG9yIG9mIEZBTFNFLiAgVGhpcyBub2RlIGlzIGNvbnNpZGVyZWQg
dG8gYmUgYXQgZGVwdGggemVyby4NDUZpZ3VyZSAzIGlzIGEgZ3JhcGhpYyByZXByZXNlbnRhdGlv
biBvZiB0aGUgaW5pdGlhbCBzdGF0ZSBvZiB0aGUgdmFsaWRfcG9saWN5X3RyZWUuICBBZGRpdGlv
bmFsIGZpZ3VyZXMgd2lsbCB1c2UgdGhpcyBmb3JtYXQgdG8gZGVzY3JpYmUgY2hhbmdlcyBpbiB0
aGUgdmFsaWRfcG9saWN5X3RyZWUgZHVyaW5nIHBhdGggcHJvY2Vzc2luZy4NDSAgfC0tLS0tLS0t
LS0tLS0tLS0tfA0gIHwgIJNhbnktcG9saWN5lCAgIHwgICA8LS0tLSB2YWxpZF9wb2xpY3kNICB8
LS0tLS0tLS0tLS0tLS0tLS18DSAgfCAgICAgICB7fSAgICAgICAgfCAgIDwtLS0tIHF1YWxpZmll
cl9zZXQNICB8LS0tLS0tLS0tLS0tLS0tLS18DSAgfCAgICAgIEZBTFNFICAgICAgfCAgIDwtLS0t
IGNyaXRpY2FsaXR5X2luZGljYXRvcg0gIHwtLS0tLS0tLS0tLS0tLS0tLXwNICB8ICB7k2FueS1w
b2xpY3mUfSB8ICAgPC0tLS0gZXhwZWN0ZWRfcG9saWN5X3NldA0gIHwtLS0tLS0tLS0tLS0tLS0t
LXwNDUZpZ3VyZSAzLiBJbml0aWFsIHZhbHVlIG9mIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSBzdGF0
ZSB2YXJpYWJsZQ0NKGIpIHBlcm1pdHRlZF9zdWJ0cmVlczogIEEgc2V0IG9mIHJvb3QgbmFtZXMg
Zm9yIGVhY2ggbmFtZSB0eXBlIChlLmcuLCBYLjUwMCBkaXN0aW5ndWlzaGVkIG5hbWVzLCBlbWFp
bCBhZGRyZXNzZXMsIG9yIGlwIGFkZHJlc3NlcykgZGVmaW5pbmcgYSBzZXQgb2Ygc3VidHJlZXMg
d2l0aGluIHdoaWNoIGFsbCBzdWJqZWN0IG5hbWVzIGluIHN1YnNlcXVlbnQgY2VydGlmaWNhdGVz
IGluIHRoZSBjZXJ0aWZpY2F0aW9uIHBhdGggc2hhbGwgZmFsbC4gVGhpcyB2YXJpYWJsZSBpbmNs
dWRlcyBhIHNldCBmb3IgZWFjaCBuYW1lIHR5cGU6IHRoZSBpbml0aWFsIHZhbHVlIGZvciB0aGUg
c2V0IGZvciBEaXN0aW5ndWlzaGVkIE5hbWVzIGlzIHRoZSBzZXQgb2YgYWxsIERpc3Rpbmd1aXNo
ZWQgbmFtZXM7IHRoZSBpbml0aWFsIHZhbHVlIGZvciB0aGUgc2V0IG9mIFJGQzgyMiBuYW1lcyBp
cyB0aGUgc2V0IG9mIGFsbCBSRkM4MjIgbmFtZXMsIGV0Yy4NDShjKSBleGNsdWRlZF9zdWJ0cmVl
czogIEEgc2V0IG9mIHJvb3QgbmFtZXMgZm9yIGVhY2ggbmFtZSB0eXBlICAoZS5nLiwgWC41MDAg
ZGlzdGluZ3Vpc2hlZCBuYW1lcywgZW1haWwgYWRkcmVzc2VzLCBvciBpcCBhZGRyZXNzZXMpIGRl
ZmluaW5nIGEgc2V0IG9mIHN1YnRyZWVzIHdpdGhpbiB3aGljaCBubyBzdWJqZWN0IG5hbWUgaW4g
c3Vic2VxdWVudCBjZXJ0aWZpY2F0ZXMgaW4gdGhlIGNlcnRpZmljYXRpb24gcGF0aCBtYXkgZmFs
bC4gVGhpcyB2YXJpYWJsZSBpbmNsdWRlcyBhIHNldCBmb3IgZWFjaCBuYW1lIHR5cGUsIGFuZCBp
dHMgaW5pdGlhbCB2YWx1ZSBpcyAiZW1wdHkiLg0NKGQpIGV4cGxpY2l0X3BvbGljeTogYW4gaW50
ZWdlciB3aGljaCBpbmRpY2F0ZXMgaWYgYSBub24tTlVMTCB2YWxpZF9wb2xpY3lfdHJlZSBpcyBy
ZXF1aXJlZC4gVGhlIGludGVnZXIgaW5kaWNhdGVzIHRoZSBudW1iZXIgb2Ygbm9uLXNlbGYtaXNz
dWVkIGNlcnRpZmljYXRlcyB0byBiZSBwcm9jZXNzZWQgYmVmb3JlIHRoaXMgcmVxdWlyZW1lbnQg
aXMgaW1wb3NlZC4gT25jZSBzZXQsIHRoaXMgdmFyaWFibGUgbWF5IGJlIGRlY3JlYXNlZCwgYnV0
IG1heSBub3QgYmUgaW5jcmVhc2VkLiAoVGhhdCBpcywgaWYgYSBjZXJ0aWZpY2F0ZSBpbiB0aGUg
cGF0aCByZXF1aXJlcyBhIG5vbi1OVUxMIHZhbGlkX3BvbGljeV90cmVlLCBhIGxhdGVyIGNlcnRp
ZmljYXRlIGNhbiBub3QgcmVtb3ZlIHRoaXMgcmVxdWlyZW1lbnQuKSBJZiBpbml0aWFsLWV4cGxp
Y2l0LXBvbGljeSBpcyBzZXQgdGhlbiB0aGUgaW5pdGlhbCB2YWx1ZSBpcyAwLCBvdGhlcndpc2Ug
dGhlIGluaXRpYWwgdmFsdWUgaXMgbisxLg0NKGUpIGluaGliaXRfYW55LXBvbGljeTogYW4gaW50
ZWdlciB3aGljaCBpbmRpY2F0ZXMgd2hldGhlciB0aGUgk2FueS1wb2xpY3mUIHBvbGljeSBpZGVu
dGlmaWVyIGlzIGNvbnNpZGVyZWQgYSBtYXRjaC4gVGhlIGludGVnZXIgaW5kaWNhdGVzIHRoZSBu
dW1iZXIgb2Ygbm9uLXNlbGYtaXNzdWVkIGNlcnRpZmljYXRlcyB0byBiZSBwcm9jZXNzZWQgYmVm
b3JlIHRoZSCTYW55LXBvbGljeZQgT0lELCBpZiBhc3NlcnRlZCBpbiBhIGNlcnRpZmljYXRlLCBp
cyBpZ25vcmVkLiBPbmNlIHNldCwgdGhpcyB2YXJpYWJsZSBtYXkgYmUgZGVjcmVhc2VkLCBidXQg
bWF5IG5vdCBiZSBpbmNyZWFzZWQuIChUaGF0IGlzLCBpZiBhIGNlcnRpZmljYXRlIGluIHRoZSBw
YXRoIGluaGliaXRzIHByb2Nlc3Npbmcgb2Ygk2FueS1wb2xpY3mULCBhIGxhdGVyIGNlcnRpZmlj
YXRlIGNhbiBub3QgcGVybWl0IGl0LikgSWYgaW5pdGlhbC1hbnktcG9saWN5LWluaGliaXQgaXMg
c2V0IHRoZW4gdGhlIGluaXRpYWwgdmFsdWUgaXMgMCwgb3RoZXJ3aXNlIHRoZSBpbml0aWFsIHZh
bHVlIGlzIG4rMS4NDShmKSBwb2xpY3lfbWFwcGluZzogYW4gaW50ZWdlciB3aGljaCBpbmRpY2F0
ZXMgaWYgcG9saWN5IG1hcHBpbmcgaXMgcGVybWl0dGVkLiAgVGhlIGludGVnZXIgaW5kaWNhdGVz
IHRoZSBudW1iZXIgb2Ygbm9uLXNlbGYtaXNzdWVkIGNlcnRpZmljYXRlcyB0byBiZSBwcm9jZXNz
ZWQgYmVmb3JlIHBvbGljeSBtYXBwaW5nIGlzIGluaGliaXRlZC4gIE9uY2Ugc2V0LCB0aGlzIHZh
cmlhYmxlIG1heSBiZSBkZWNyZWFzZWQsIGJ1dCBtYXkgbm90IGJlIGluY3JlYXNlZC4gKFRoYXQg
aXMsIGlmIGEgY2VydGlmaWNhdGUgaW4gdGhlIHBhdGggc3BlY2lmaWVzIHBvbGljeSBtYXBwaW5n
IGlzIG5vdCBwZXJtaXR0ZWQsIGl0IGNhbiBub3QgYmUgb3ZlcnJpZGRlbiBieSBhIGxhdGVyIGNl
cnRpZmljYXRlLikgSWYgaW5pdGlhbC1wb2xpY3ktbWFwcGluZy1pbmhpYml0IGlzIHNldCB0aGVu
IHRoZSBpbml0aWFsIHZhbHVlIGlzIDAsIG90aGVyd2lzZSB0aGUgaW5pdGlhbCB2YWx1ZSBpcyBu
KzEuDQ0oZykgd29ya2luZ19wdWJsaWNfa2V5X2FsZ29yaXRobTogdGhlIGRpZ2l0YWwgc2lnbmF0
dXJlIGFsZ29yaXRobSB1c2VkIHRvIHZlcmlmeSB0aGUgc2lnbmF0dXJlIG9mIGEgY2VydGlmaWNh
dGUuICBUaGUgd29ya2luZ19wdWJsaWNfa2V5X2FsZ29yaXRobSBpcyBpbml0aWFsaXplZCBmcm9t
IHRoZSB0cnVzdGVkIHB1YmxpYyBrZXkgYWxnb3JpdGhtIHByb3ZpZGVkIGluIHRoZSB0cnVzdCBh
bmNob3IgaW5mb3JtYXRpb24uDQ0oaCkgd29ya2luZ19wdWJsaWNfa2V5OiB0aGUgcHVibGljIGtl
eSB1c2VkIHRvIHZlcmlmeSB0aGUgc2lnbmF0dXJlIG9mIGEgY2VydGlmaWNhdGUuICBUaGUgd29y
a2luZ19wdWJsaWNfa2V5IGlzIGluaXRpYWxpemVkIGZyb20gdGhlIHRydXN0ZWQgcHVibGljIGtl
eSBwcm92aWRlZCBpbiB0aGUgdHJ1c3QgYW5jaG9yIGluZm9ybWF0aW9uLg0gDShpKSB3b3JraW5n
X3B1YmxpY19rZXlfcGFyYW1ldGVyczogIHBhcmFtZXRlcnMgYXNzb2NpYXRlZCB3aXRoIHRoZSBj
dXJyZW50IHB1YmxpYyBrZXksIHRoYXQgbWF5IHJlcXVpcmVkIHRvIHZlcmlmeSBhIHNpZ25hdHVy
ZSAoZGVwZW5kaW5nIHVwb24gdGhlIGFsZ29yaXRobSkuICBUaGUgd29ya2luZ19wdWJsaWNfa2V5
X3BhcmFtZXRlcnMgdmFyaWFibGUgaXMgaW5pdGlhbGl6ZWQgZnJvbSB0aGUgdHJ1c3RlZCBwdWJs
aWMga2V5IHBhcmFtZXRlcnMgcHJvdmlkZWQgaW4gdGhlIHRydXN0IGFuY2hvciBpbmZvcm1hdGlv
bi4gIElmIHByb2Nlc3NpbmcgaXMgaW5pdGlhbGl6ZWQgZnJvbSBhIHNlbGYtc2lnbmVkIGNlcnRp
ZmljYXRlLCB0aGUgd29ya2luZ19wdWJsaWNfa2V5X3BhcmFtZXRlcnMgdmFyaWFibGUgaXMgaW5p
dGlhbGl6ZWQgZnJvbSB0aGUgcGFyYW1ldGVycyBmaWVsZCBvZiB0aGUgc3ViamVjdCBwdWJsaWMg
a2V5Lg0NKGopIHdvcmtpbmdfaXNzdWVyX25hbWU6ICB0aGUgaXNzdWVyIGRpc3Rpbmd1aXNoZWQg
bmFtZSBleHBlY3RlZCBpbiB0aGUgbmV4dCBjZXJ0aWZpY2F0ZSBpbiB0aGUgY2hhaW4uICBUaGUg
d29ya2luZ19pc3N1ZXJfbmFtZSBpcyBpbml0aWFsaXplZCB0byB0aGUgdHJ1c3RlZCBpc3N1ZXIg
cHJvdmlkZWQgaW4gdGhlIHRydXN0IGFuY2hvciBpbmZvcm1hdGlvbi4NDShrKSB3b3JraW5nX2lz
c3Vlcl9VSUQ6IGEgZGlzdGluZ3Vpc2hlZCBuYW1lIG1heSBiZSBhc3NvY2lhdGVkIHdpdGggYW4g
b3B0aW9uYWwgdW5pcXVlIGlkZW50aWZpZXIuICBUaGUgd29ya2luZ19pc3N1ZXJfVUlEIGlzIHRo
ZSB1bmlxdWUgaWRlbnRpZmllciB0aGF0IGlzIGV4cGVjdGVkIGluIHRoZSBuZXh0IGNlcnRpZmlj
YXRlLCBvciB0aGUgdmFsdWUgTlVMTC4gIFRoZSB3b3JraW5nX2lzc3Vlcl9VSUQgaXMgaW5pdGlh
bGl6ZWQgdG8gdGhlIHRydXN0ZWQgaXNzdWVyknMgdW5pcXVlIGlkZW50aWZpZXIgcHJvdmlkZWQg
aW4gdGhlIHRydXN0IGFuY2hvciBpbmZvcm1hdGlvbi4NDShsKSBtYXhfcGF0aF9sZW5ndGg6ICB0
aGlzIGludGVnZXIgaXMgaW5pdGlhbGl6ZWQgdG8gbiwgYW5kIGlzIHJlc2V0IGJ5IHRoZSBwYXRo
IGxlbmd0aCBjb25zdHJhaW50IGZpZWxkIG9mIGEgQ0EgY2VydGlmaWNhdGUuIA0NVXBvbiBjb21w
bGV0aW9uIG9mIHRoZSBpbml0aWFsaXphdGlvbiBzdGVwcywgcGVyZm9ybSB0aGUgYmFzaWMgY2Vy
dGlmaWNhdGUgcHJvY2Vzc2luZyBzdGVwcyBzcGVjaWZpZWQgaW4gNi4xLjMuDQ02LjEuMyBCYXNp
YyBDZXJ0aWZpY2F0ZSBQcm9jZXNzaW5nDQ1UaGUgYmFzaWMgcGF0aCBwcm9jZXNzaW5nIGFjdGlv
bnMgdG8gYmUgcGVyZm9ybWVkIGZvciBjZXJ0aWZpY2F0ZSBpIGFyZSBsaXN0ZWQgYmVsb3cuDQ0o
YSkgVmVyaWZ5IHRoZSBiYXNpYyBjZXJ0aWZpY2F0ZSBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nOg0N
KDEpIHRoZSBjZXJ0aWZpY2F0ZSB3YXMgc2lnbmVkIHdpdGggdGhlIHdvcmtpbmdfcHVibGljX2tl
eV9hbGdvcml0aG0gdXNpbmcgdGhlIHdvcmtpbmdfcHVibGljX2tleSBhbmQgdGhlIHdvcmtpbmdf
cHVibGljX2tleV9wYXJhbWV0ZXJzLCANDSgyKSB0aGUgY2VydGlmaWNhdGUgdmFsaWRpdHkgcGVy
aW9kIGluY2x1ZGVzIHRpbWUgVCwNDSgzKSBBdCB0aW1lIFQsIHRoZSBjZXJ0aWZpY2F0ZSBpcyBu
b3QgcmV2b2tlZCBhbmQgaXMgbm90IG9uIGhvbGQgc3RhdHVzLCAodGhpcyBtYXkgYmUgZGV0ZXJt
aW5lZCBieSBvYnRhaW5pbmcgdGhlIGFwcHJvcHJpYXRlIENSTCBbc2VlIHNlY3Rpb24gNi5YXSBv
ciBzdGF0dXMgaW5mb3JtYXRpb24sIG9yIGJ5IG91dC1vZi1iYW5kIG1lY2hhbmlzbXMpLA0NKDQp
IHRoZSBjZXJ0aWZpY2F0ZSBpc3N1ZXIgbmFtZSBpcyB0aGUgd29ya2luZ19pc3N1ZXJfbmFtZSwg
YW5kDQ0oNSkgdGhlIGNlcnRpZmljYXRlIGlzc3VlciB1bmlxdWUgaWRlbnRpZmllciBpcyB0aGUg
d29ya2luZ19pc3N1ZXJfVUlELCBtZWFuaW5nOg0oaSkgd29ya2luZ19pc3N1ZXJfVUlEIGlzIG5v
bi1udWxsIGFuZCBtYXRjaGVzIHRoZSB2YWx1ZSBpbiB0aGUgaXNzdWVyVUlEIGZpZWxkLCBvcg0o
aWkpIHdvcmtpbmdfaXNzdWVyX1VJRCBpcyBudWxsIGFuZCB0aGUgaXNzdWVyVUlEIGZpZWxkIGlz
IG5vdCBwcmVzZW50Lg0NKGIpIElmIGNlcnRpZmljYXRlIGkgaXMgbm90IHNlbGYtaXNzdWVkLCB2
ZXJpZnkgdGhhdCB0aGUgc3ViamVjdCBuYW1lIGlzIHdpdGhpbiBvbmUgb2YgdGhlIHBlcm1pdHRl
ZF9zdWJ0cmVlcyBmb3IgWC41MDAgZGlzdGluZ3Vpc2hlZCBuYW1lcywgYW5kIHZlcmlmeSB0aGF0
IGVhY2ggb2YgdGhlIGFsdGVybmF0aXZlIG5hbWVzIGluIHRoZSBzdWJqZWN0QWx0TmFtZSBleHRl
bnNpb24gKGNyaXRpY2FsIG9yIG5vbmNyaXRpY2FsKSBpcyB3aXRoaW4gb25lIG9mIHRoZSBwZXJt
aXR0ZWRfc3VidHJlZXMgZm9yIHRoYXQgbmFtZSB0eXBlLg0gDShjKSBJZiBjZXJ0aWZpY2F0ZSBp
IGlzIG5vdCBzZWxmLWlzc3VlZCwgdmVyaWZ5IHRoYXQgdGhlIHN1YmplY3QgbmFtZSBpcyBub3Qg
d2l0aGluIG9uZSBvZiB0aGUgZXhjbHVkZWRfc3VidHJlZXMgZm9yIFguNTAwIGRpc3Rpbmd1aXNo
ZWQgbmFtZXMsIGFuZCB2ZXJpZnkgdGhhdCBlYWNoIG9mIHRoZSBhbHRlcm5hdGl2ZSBuYW1lcyBp
biB0aGUgc3ViamVjdEFsdE5hbWUgZXh0ZW5zaW9uIChjcml0aWNhbCBvciBub25jcml0aWNhbCkg
aXMgbm90IHdpdGhpbiBvbmUgb2YgdGhlIGV4Y2x1ZGVkX3N1YnRyZWVzIGZvciB0aGF0IG5hbWUg
dHlwZS4NDShkKSBpZiB0aGUgY2VydGlmaWNhdGUgcG9saWNpZXMgZXh0ZW5zaW9uIGlzIHByZXNl
bnQgaW4gdGhlIGNlcnRpZmljaWF0ZSBhbmQgdGhlIHZhbGlkX3BvbGljeV90cmVlIGlzIG5vdCBO
VUxMLCBwcm9jZXNzIHRoZSBwb2xpY3kgaW5mb3JtYXRpb24gYnkgcGVyZm9ybWluZyB0aGUgZm9s
bG93aW5nIHN0ZXBzIGluIG9yZGVyOg0gDSgxKSBmb3IgZWFjaCBwb2xpY3kgUCBub3QgZXF1YWwg
dG8gk2FueS1wb2xpY3mUIHdpdGggdGhlIE9JRCB3aG9zZSB2YWx1ZSBpcyBPSUQtUCBhbmQgdGhl
IHF1YWxpZmllciBzZXQgZGVub3RlZCBQLVEgaW4gdGhlIGNlcnRpZmljYXRlIHBvbGljaWVzIGV4
dGVuc2lvbjoNKGkpIGlmIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSBpbmNsdWRlcyBhIG5vZGUgb2Yg
ZGVwdGggaS0xIHdoZXJlIE9JRC1QIGlzIGluIHRoZSBleHBlY3RlZF9wb2xpY3lfc2V0LCBjcmVh
dGUgYSBjaGlsZCBub2RlIGFzIGZvbGxvd3M6IHNldCB0aGUgdmFsaWRfcG9saWN5IHRvIE9JRC1Q
OyBzZXQgdGhlIHF1YWxpZmllcl9zZXQgdG8gUC1RLCBhbmQgc2V0IHRoZSBleHBlY3RlZF9wb2xp
Y3lfc2V0IHRvIHtPSUQtUH0uDQ1bRm9yIGV4YW1wbGUsIGNvbnNpZGVyIGEgdmFsaWRfcG9saWN5
X3RyZWUgd2l0aCBhIG5vZGUgb2YgZGVwdGggaS0xIHdoZXJlIHRoZSBleHBlY3RlZF9wb2xpY3lf
c2V0IGlzIHtHb2xkLCBXaGl0ZX0uICBBc3N1bWUgdGhlIGNlcnRpZmljYXRlIHBvbGljaWVzIEdv
bGQgYW5kIFNpbHZlciBhcHBlYXIgaW4gdGhlIGNlcnRpZmljYXRlIHBvbGljaWVzIGV4dGVuc2lv
biBvZiBjZXJ0aWZpY2F0ZSBpLiAgVGhlIEdvbGQgcG9saWN5IGlzIG1hdGNoZWQgYnV0IHRoZSBT
aWx2ZXIgcG9saWN5IGlzIG5vdC4gIFRoaXMgcnVsZSB3aWxsIGdlbmVyYXRlIGEgY2hpbGQgbm9k
ZSBvZiBkZXB0aCBpIGZvciB0aGUgR29sZCBwb2xpY3kuIFRoZSByZXN1bHQgaXMgc2hvd24gYXMg
RmlndXJlIDQuXQ0NDSAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfA0gICAg
ICAgICAgICAgICAgICAgIHwgICAgICAgUmVkICAgICAgIHwNICAgICAgICAgICAgICAgICAgICB8
LS0tLS0tLS0tLS0tLS0tLS18DSAgICAgICAgICAgICAgICAgICAgfCAgICAgICB7fSAgICAgICAg
fA0gICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwgICBub2RlIG9mIGRlcHRo
IGktMQ0gICAgICAgICAgICAgICAgICAgIHwgICAgICBGQUxTRSAgICAgIHwNICAgICAgICAgICAg
ICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18DSAgICAgICAgICAgICAgICAgICAgfCAge0dvbGQs
IFdoaXRlfSAgfA0gICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwNICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBWDSAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfA0gICAgICAgICAgICAg
ICAgICAgIHwgICAgICBHb2xkICAgICAgIHwNICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0t
LS0tLS0tLS18DSAgICAgICAgICAgICAgICAgICAgfCAgICAgICB7fSAgICAgICAgfA0gICAgICAg
ICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwgbm9kZSBvZiBkZXB0aCBpDSAgICAgICAg
ICAgICAgICAgICAgfCAgdW5pbml0aWFsaXplZCAgfA0gICAgICAgICAgICAgICAgICAgIHwtLS0t
LS0tLS0tLS0tLS0tLXwNICAgICAgICAgICAgICAgICAgICB8ICAgICB7R29sZH0gICAgICB8DSAg
ICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfA0NICAgICAgICAgICAgRmlndXJl
IDQuIFByb2Nlc3NpbmcgYW4gZXhhY3QgbWF0Y2gNDShpaSkgaWYgdGhlcmUgd2FzIG5vIG1hdGNo
IGluIHN0ZXAgKGkpIGFuZCB0aGUgIHZhbGlkX3BvbGljeV90cmVlIGluY2x1ZGVzIGEgbm9kZSBv
ZiBkZXB0aCBpLTEgd2l0aCB0aGUgdmFsaWQgcG9saWN5IJNhbnktcG9saWN5lCwgZ2VuZXJhdGUg
YSBjaGlsZCBub2RlIHdpdGggdGhlIGZvbGxvd2luZyB2YWx1ZXM6IHNldCB0aGUgdmFsaWRfcG9s
aWN5IHRvIE9JRC1QOyBzZXQgdGhlIHF1YWxpZmllcl9zZXQgdG8gUC1RLCBhbmQgc2V0IHRoZSBl
eHBlY3RlZF9wb2xpY3lfc2V0IHRvIHtPSUQtUH0uDQ1bRm9yIGV4YW1wbGUsIGNvbnNpZGVyIGEg
dmFsaWRfcG9saWN5X3RyZWUgd2l0aCBhIG5vZGUgb2YgZGVwdGggaS0xIHdoZXJlIHRoZSB2YWxp
ZF9wb2xpY3kgaXMgk2FueS1wb2xpY3mULiAgQXNzdW1lIHRoZSBjZXJ0aWZpY2F0ZSBwb2xpY2ll
cyBHb2xkIGFuZCBTaWx2ZXIgYXBwZWFyIGluIHRoZSBjZXJ0aWZpY2F0ZSBwb2xpY2llcyBleHRl
bnNpb24gb2YgY2VydGlmaWNhdGUgaS4gIFRoZSBHb2xkIHBvbGljeSBkb2VzIG5vdCBoYXZlIGEg
cXVhbGlmaWVyLCBidXQgdGhlIFNpbHZlciBwb2xpY3kgaGFzIHRoZSBxdWFsaWZpZXIgUS1TaWx2
ZXIuICBJZiBHb2xkIGFuZCBTaWx2ZXIgd2VyZSBub3QgbWF0Y2hlZCBpbiAoaSkgYWJvdmUsIHRo
aXMgcnVsZSB3aWxsIGdlbmVyYXRlIHR3byBjaGlsZCBub2RlcyBvZiBkZXB0aCBpLCBvbmUgZm9y
IGVhY2ggcG9saWN5LiAgVGhlIHJlc3VsdCBpcyBzaG93biBhcyBGaWd1cmUgNS5dDQ0NICAgICAg
ICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18DSAgICAgICAgICAgICAgICAgICAgfCAg
k2FueS1wb2xpY3mUICAgfA0gICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwN
ICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHt9ICAgICAgICB8DSAgICAgICAgICAgICAgICAg
ICAgfC0tLS0tLS0tLS0tLS0tLS0tfCBub2RlIG9mIGRlcHRoIGktMQ0gICAgICAgICAgICAgICAg
ICAgIHwgICAgICBGQUxTRSAgICAgIHwNICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0t
LS0tLS18DSAgICAgICAgICAgICAgICAgICAgfCAge5NhbnktcG9saWN5lH0gfA0gICAgICAgICAg
ICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwNICAgICAgICAgICAgICAgICAgICAgICAvICAg
ICAgICAgICBcDSAgICAgICAgICAgICAgICAgICAgICAvICAgICAgICAgICAgIFwNICAgICAgICAg
ICAgICAgICAgICAgLyAgICAgICAgICAgICAgIFwNICAgICAgICAgICAgICAgICAgICAvICAgICAg
ICAgICAgICAgICBcDSAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwgICAgICAgICAgfC0tLS0tLS0t
LS0tLS0tLS0tfA0gICAgICB8ICAgICAgR29sZCAgICAgICB8ICAgICAgICAgIHwgICAgIFNpbHZl
ciAgICAgIHwNICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAgICB8LS0tLS0tLS0tLS0t
LS0tLS18DSAgICAgIHwgICAgICAge30gICAgICAgIHwgICAgICAgICAgfCAgIHtRLVNpbHZlcn0g
ICAgfA0gICAgICB8LS0tLS0tLS0tLS0tLS0tLS18IG5vZGVzIG9mIHwtLS0tLS0tLS0tLS0tLS0t
LXwNICAgICAgfCB1bmluaXRpYWxpemVkICAgfCBkZXB0aCBpICB8IHVuaW5pdGlhbGl6ZWQgICB8
DSAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfA0g
ICAgICB8ICAgICB7R29sZH0gICAgICB8ICAgICAgICAgIHwgICAge1NpbHZlcn0gICAgIHwNICAg
ICAgfC0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18DQ0NRmln
dXJlIDUuIFByb2Nlc3NpbmcgdW5tYXRjaGVkIHBvbGljaWVzIHdoZW4gYSBsZWFmIG5vZGUgc3Bl
Y2lmaWVzIJNhbnktcG9saWN5lCANDSgyKSBpZiB0aGUgY2VydGlmaWNhdGUgcG9saWNpZXMgZXh0
ZW5zaW9uIGluY2x1ZGVzIHRoZSBwb2xpY3kgk2FueS1wb2xpY3mUIHdpdGggdGhlIHF1YWxpZmll
ciBzZXQgQVAtUSBhbmQgaW5oaWJpdF9hbnktcG9saWN5IGlzIGdyZWF0ZXIgdGhhbiAwOg0NZm9y
IGVhY2ggbm9kZSBpbiB0aGUgdmFsaWRfcG9saWN5X3RyZWUgb2YgZGVwdGggaS0xLCBmb3IgZWFj
aCB2YWx1ZSBpbiB0aGUgZXhwZWN0ZWRfcG9saWN5X3NldCAoaW5jbHVkaW5nIJNhbnktcG9saWN5
lCkgdGhhdCBkb2VzIG5vdCBhcHBlYXIgaW4gYSBjaGlsZCBub2RlLCBjcmVhdGUgYSBjaGlsZCBu
b2RlIHdpdGggdGhlIGZvbGxvd2luZyB2YWx1ZXM6IHNldCB0aGUgdmFsaWRfcG9saWN5IHRvIHRo
ZSB2YWx1ZSBmcm9tIHRoZSBleHBlY3RlZF9wb2xpY3lfc2V0IGluIHRoZSBwYXJlbnQgbm9kZTsg
c2V0IHRoZSBxdWFsaWZpZXJfc2V0IHRvIEFQLVEsIGFuZCBzZXQgdGhlIGV4cGVjdGVkX3BvbGlj
eV9zZXQgdG8gdGhlIHZhbHVlIGluIHRoZSB2YWxpZF9wb2xpY3kgZnJvbSB0aGlzIG5vZGUuDQ1b
Rm9yIGV4YW1wbGUsIGNvbnNpZGVyIGEgdmFsaWRfcG9saWN5X3RyZWUgd2l0aCBhIG5vZGUgb2Yg
ZGVwdGggaS0xIHdoZXJlIHRoZSBleHBlY3RlZF9wb2xpY3lfc2V0ID0ge0dvbGQsIFNpbHZlcn0u
ICBBc3N1bWUgk2FueS1wb2xpY3mUIGFwcGVhcnMgaW4gdGhlIGNlcnRpZmljYXRlIHBvbGljaWVz
IGV4dGVuc2lvbiBvZiBjZXJ0aWZpY2F0ZSBpLCBidXQgR29sZCBhbmQgU2lsdmVyIGRvIG5vdC4g
IFRoaXMgcnVsZSB3aWxsIGdlbmVyYXRlIHR3byBjaGlsZCBub2RlcyBvZiBkZXB0aCBpLCBvbmUg
Zm9yIGVhY2ggcG9saWN5LiAgVGhlIHJlc3VsdCBpcyBzaG93biBiZWxvdyBhcyBGaWd1cmUgNi5d
DQ0gICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwNICAgICAgICAgICAgICAg
ICAgICB8ICAgICAgUmVkICAgICAgICB8DSAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0t
LS0tLS0tfA0gICAgICAgICAgICAgICAgICAgIHwgICAgICAge30gICAgICAgIHwNICAgICAgICAg
ICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18IG5vZGUgb2YgZGVwdGggaS0xDSAgICAgICAg
ICAgICAgICAgICAgfCAgICAgIEZBTFNFICAgICAgfA0gICAgICAgICAgICAgICAgICAgIHwtLS0t
LS0tLS0tLS0tLS0tLXwNICAgICAgICAgICAgICAgICAgICB8ICB7R29sZCwgU2lsdmVyfSB8DSAg
ICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfA0gICAgICAgICAgICAgICAgICAg
ICAgIC8gICAgICAgICAgIFwNICAgICAgICAgICAgICAgICAgICAgIC8gICAgICAgICAgICAgXA0g
ICAgICAgICAgICAgICAgICAgICAvICAgICAgICAgICAgICAgXA0gICAgICAgICAgICAgICAgICAg
IC8gICAgICAgICAgICAgICAgIFwNICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAgICB8
LS0tLS0tLS0tLS0tLS0tLS18DSAgICAgIHwgICAgICBHb2xkICAgICAgIHwgICAgICAgICAgfCAg
ICAgU2lsdmVyICAgICAgfA0gICAgICB8LS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgIHwtLS0t
LS0tLS0tLS0tLS0tLXwNICAgICAgfCAgICAgICB7fSAgICAgICAgfCAgICAgICAgICB8ICAgICAg
IHt9ICAgICAgICB8DSAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLXwgbm9kZXMgb2YgfC0tLS0tLS0t
LS0tLS0tLS0tfA0gICAgICB8IHVuaW5pdGlhbGl6ZWQgICB8IGRlcHRoIGkgIHwgdW5pbml0aWFs
aXplZCAgIHwNICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAgICB8LS0tLS0tLS0tLS0t
LS0tLS18DSAgICAgIHwgICAgIHtHb2xkfSAgICAgIHwgICAgICAgICAgfCAgICB7U2lsdmVyfSAg
ICAgfA0gICAgICB8LS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0t
LXwNDQ1GaWd1cmUgNi4gUHJvY2Vzc2luZyB1bm1hdGNoZWQgcG9saWNpZXMgd2hlbiB0aGUgY2Vy
dGlmaWNhdGUgcG9saWNpZXMgZXh0ZW5zaW9uIHNwZWNpZmllcyCTYW55LXBvbGljeZQgDQ0NKDMp
IGlmIHRoZXJlIGlzIGEgbm9kZSBpbiB0aGUgdmFsaWRfcG9saWN5X3RyZWUgb2YgZGVwdGggaS0x
IG9yIGxlc3Mgd2l0aG91dCBhbnkgY2hpbGQgbm9kZXMsIGRlbGV0ZSB0aGF0IG5vZGUuIFJlcGVh
dCB0aGlzIHN0ZXAgdW50aWwgdGhlcmUgYXJlIG5vIG5vZGVzIG9mIGRlcHRoIGktMSBvciBsZXNz
IHdpdGhvdXQgY2hpbGRyZW4uDQ1bRm9yIGV4YW1wbGUsIGNvbnNpZGVyIHRoZSB2YWxpZF9wb2xp
Y3lfdHJlZSBzaG93biBpbiBGaWd1cmUgNyBiZWxvdy4gIFRoZSB0d28gbm9kZXMgYXQgZGVwdGgg
aS0xIHRoYXQgYXJlIG1hcmtlZCB3aXRoIGFuIJFYkiBoYXZlIG5vIGNoaWxkcmVuLCBhbmQgYXJl
IGRlbGV0ZWQuICBBcHBseWluZyB0aGlzIHJ1bGUgdG8gdGhlIHJlc3VsdGluZyB0cmVlIHdpbGwg
Y2F1c2UgdGhlIG5vZGUgYXQgZGVwdGggaS0yIHRoYXQgaXMgbWFya2VkIHdpdGggYW4gkVmSIHRv
IGJlIGRlbGV0ZWQuICBUaGUgZm9sbG93aW5nIGFwcGxpY2F0aW9uIG9mIHRoZSBydWxlIGRvZXMg
bm90IGNhdXNlIGFueSBub2RlcyB0byBiZSBkZWxldGVkLCBhbmQgdGhpcyBzdGVwIGlzIGNvbXBs
ZXRlLl0NDQ0gICAgICAgICAgICAgICAgICAgICAgICAgIA0gICAgICAgICAgICAgICAgICAgIHwt
LS0tLS0tLS0tLXwNICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8IG5vZGUgb2YgZGVw
dGggaS0zDSAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tfA0gICAgICAgICAgICAgICAg
ICAgIC8gICAgIHwgICAgIFwNICAgICAgICAgICAgICAgICAgIC8gICAgICB8ICAgICAgXA0gICAg
ICAgICAgICAgICAgICAvICAgICAgIHwgICAgICAgXA0gICAgICAgICAgICAgICAgIC8gICAgICAg
IHwgICAgICAgIFwNICAgICAgIHwtLS0tLS0tLS0tLXwgfC0tLS0tLS0tLS0tfCAgfC0tLS0tLS0t
LS0tfA0gICAgICAgfCAgICAgICAgICAgfCB8ICAgICAgICAgICB8ICB8ICAgICBZICAgICB8IG5v
ZGVzIG9mDSAgICAgICAgICAgICB8LS0tLS0tLS0tLS18IHwtLS0tLS0tLS0tLXwgIHwtLS0tLS0t
LS0tLXwgZGVwdGggaS0yDSAgICAgICAgICAgICAgICAgLyAgIFwgICAgICAgICAgICAgICBcICAg
ICAgICAgICBcDSAgICAgICAgICAgICAgICAvICAgICBcICAgICAgICAgICAgICAgXCAgICAgICAg
ICAgXA18LS0tLS0tLS0tLS18IHwtLS0tLS0tLS0tLXwgIHwtLS0tLS0tLS0tLXwgIHwtLS0tLS0t
LS0tLXwgbm9kZXMgb2YNfCAgICAgICAgICAgfCB8ICAgICBYICAgICB8ICB8ICAgICAgICAgICB8
ICB8ICAgWCAgICAgICB8ICBkZXB0aA18LS0tLS0tLS0tLS18IHwtLS0tLS0tLS0tLXwgIHwtLS0t
LS0tLS0tLXwgIHwtLS0tLS0tLS0tLXwgICBpLTENICAgICAgfCAgICAgICAgICAgICAgICAgICAg
ICAvICAgICB8ICAgICBcDSAgICAgIHwgICAgICAgICAgICAgICAgICAgICAvICAgICAgfCAgICAg
IFwNICAgICAgfCAgICAgICAgICAgICAgICAgICAgLyAgICAgICB8ICAgICAgIFwNfC0tLS0tLS0t
LS0tfCB8LS0tLS0tLS0tLS18ICB8LS0tLS0tLS0tLS18ICB8LS0tLS0tLS0tLS18IG5vZGVzIG9m
DXwgICAgICAgICAgIHwgfCAgICAgICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgICAgICAgICAg
fCAgZGVwdGgNfC0tLS0tLS0tLS0tfCB8LS0tLS0tLS0tLS18ICB8LS0tLS0tLS0tLS18ICB8LS0t
LS0tLS0tLS18ICAgaQ0NICAgICAgIEZpZ3VyZSA3LiAgUHJ1bmluZyB0aGUgdmFsaWRfcG9saWN5
X3RyZWUNDQ0oNCkgaWYgdGhlIGNlcnRpZmljYXRlIHBvbGljaWVzIGV4dGVuc2lvbiB3YXMgbWFy
a2VkIGFzIGNyaXRpY2FsLCBzZXQgdGhlIGNyaXRpY2FsaXR5X2luZGljYXRvciBpbiBhbGwgbm9k
ZXMgb2YgZGVwdGggaSB0byBUUlVFLiBJZiB0aGUgY2VydGlmaWNhdGUgcG9saWNpZXMgZXh0ZW5z
aW9uIHdhcyBub3QgbWFya2VkIGNyaXRpY2FsLCBzZXQgdGhlIGNyaXRpY2FsaXR5X2luZGljYXRv
ciBpbiBhbGwgbm9kZXMgb2YgZGVwdGggaSB0byBGQUxTRS4NDShlKSBpZiB0aGUgY2VydGlmaWNh
dGUgcG9saWNpZXMgZXh0ZW5zaW9uIGlzIG5vdCBwcmVzZW50LCBzZXQgdGhlIHZhbGlkX3BvbGlj
eV90cmVlIHRvIE5VTEwuDQ0oZikgdmVyaWZ5IHRoYXQgZWl0aGVyIGV4cGxpY2l0X3BvbGljeSBp
cyBncmVhdGVyIHRoYW4gMCBvciB0aGUgdmFsaWRfcG9saWN5X3RyZWUgaXMgbm90IGVxdWFsIHRv
IE5VTEw7DQ1JZiBhbnkgb2Ygc3RlcHMgKGEpLCAoYiksIChjKSwgb3IgKGYpIGZhaWxzLCB0aGUg
cHJvY2VkdXJlIHRlcm1pbmF0ZXMsIHJldHVybmluZyBhIGZhaWx1cmUgaW5kaWNhdGlvbiBhbmQg
YW4gYXBwcm9wcmlhdGUgcmVhc29uLg0NSWYgaSBpcyBub3QgZXF1YWwgdG8gbiwgY29udGludWUg
YnkgcGVyZm9ybWluZyB0aGUgcHJlcGFyYXRvcnkgc3RlcHMgbGlzdGVkIGluIDYuMS40LiAgSWYg
aSBpcyBlcXVhbCB0byBuLCBwZXJmb3JtIHRoZSB3cmFwLXVwIHN0ZXBzIGxpc3RlZCBpbiA2LjEu
NS4NDTYuMS40IFByZXBhcmF0aW9uIGZvciBjZXJ0aWZpY2F0ZSBpKzENDVRvIHByZXBhcmUgZm9y
IHByb2Nlc3Npbmcgb2YgY2VydGlmaWNhdGUgaSsxLCBwZXJmb3JtIHRoZSBmb2xsb3dpbmcgc3Rl
cHMgZm9yIGNlcnRpZmljYXRlIGk6DQ0oYSkgaWYgYSBwb2xpY3kgbWFwcGluZyBleHRlbnNpb24g
aXMgcHJlc2VudCwgdmVyaWZ5IHRoYXQgdGhlIHNwZWNpYWwgdmFsdWUgk2FueS1wb2xpY3mUIGRv
ZXMgbm90IGFwcGVhciBhcyBhbiBpc3N1ZXJEb21haW5Qb2xpY3kgb3IgYSBzdWJqZWN0RG9tYWlu
UG9saWN5Lg0NKGIpIGlmIGEgcG9saWN5IG1hcHBpbmcgZXh0ZW5zaW9uIGlzIHByZXNlbnQsIHRo
ZW4gZm9yIGVhY2ggaXNzdWVyRG9tYWluUG9saWN5IElELVAgaW4gdGhlIHBvbGljeSBtYXBwaW5n
IGV4dGVuc2lvbjoNDQ0oMSkgaWYgdGhlIHBvbGljeV9tYXBwaW5nIHZhcmlhYmxlIGlzIGdyZWF0
ZXIgdGhhbiAwLCBmb3IgZWFjaCBub2RlIGluIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSBvZiBkZXB0
aCBpIHdoZXJlIElELVAgaXMgdGhlIHZhbGlkX3BvbGljeSwgc2V0IGV4cGVjdGVkX3BvbGljeV9z
ZXQgdG8gdGhlIHNldCBvZiBzdWJqZWN0RG9tYWluUG9saWN5IHZhbHVlcyB0aGF0IGFyZSBzcGVj
aWZpZWQgYXMgZXF1aXZhbGVudCB0byBJRC1QIGJ5IHRoZSBwb2xpY3kgbWFwcGluZyBleHRlbnNp
b24uDQ0oMikgaWYgdGhlIHBvbGljeV9tYXBwaW5nIHZhcmlhYmxlIGlzIGVxdWFsIHRvIDA6DQ0o
aSkgZGVsZXRlIGVhY2ggbm9kZSBvZiBkZXB0aCBpIGluIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSB3
aGVyZSBJRC1QIGlzIHRoZSB2YWxpZF9wb2xpY3kuDQ0oaWkpIGlmIHRoZXJlIGlzIGEgbm9kZSBp
biB0aGUgdmFsaWRfcG9saWN5X3RyZWUgb2YgZGVwdGggaS0xIG9yIGxlc3Mgd2l0aG91dCBhbnkg
Y2hpbGQgbm9kZXMsIGRlbGV0ZSB0aGF0IG5vZGUuIFJlcGVhdCB0aGlzIHN0ZXAgdW50aWwgdGhl
cmUgYXJlIG5vIG5vZGVzIG9mIGRlcHRoIGktMSBvciBsZXNzIHdpdGhvdXQgY2hpbGRyZW4uDQ0o
YykgQXNzaWduIHRoZSBjZXJ0aWZpY2F0ZSBzdWJqZWN0IG5hbWUgdG8gd29ya2luZ19pc3N1ZXJf
bmFtZS4NDShkKSBBc3NpZ24gdGhlIGNlcnRpZmljYXRlIHN1YmplY3RQdWJsaWNLZXkgdG8gd29y
a2luZ19wdWJsaWNfa2V5Lg0NKGUpIElmIHRoZSBzdWJqZWN0UHVibGljS2V5SW5mbyBmaWVsZCBv
ZiB0aGUgY2VydGlmaWNhdGUgY29udGFpbnMgYW4gYWxnb3JpdGhtIGZpZWxkIHdpdGggbm9uLW51
bGwgcGFyYW1ldGVycywgYXNzaWduIHRoZSBwYXJhbWV0ZXJzIHRvIHRoZSB3b3JraW5nX3B1Ymxp
Y19rZXlfcGFyYW1ldGVycyB2YXJpYWJsZS4NDUlmIHRoZSBzdWJqZWN0UHVibGljS2V5SW5mbyBm
aWVsZCBvZiB0aGUgY2VydGlmaWNhdGUgY29udGFpbnMgYW4gYWxnb3JpdGhtIGZpZWxkIHdpdGgg
bnVsbCBwYXJhbWV0ZXJzLCBjb21wYXJlIHRoZSBjZXJ0aWZpY2F0ZSBzdWJqZWN0UHVibGljS2V5
IGFsZ29yaXRobSB0byB0aGUgd29ya2luZ19wdWJsaWNfa2V5X2FsZ29yaXRobS4NSWYgdGhlIGNl
cnRpZmljYXRlIHN1YmplY3RQdWJsaWNLZXkgYWxnb3JpdGhtIGFuZCB0aGUgd29ya2luZ19wdWJs
aWNfa2V5X2FsZ29yaXRobSBhcmUgZGlmZmVyZW50LCBzZXQgdGhlIHdvcmtpbmdfcHVibGljX2tl
eV9wYXJhbWV0ZXJzIHRvIG51bGwuDQ0oZikgQXNzaWduIHRoZSBjZXJ0aWZpY2F0ZSBzdWJqZWN0
UHVibGljS2V5IGFsZ29yaXRobSB0byB0aGUgd29ya2luZ19wdWJsaWNfa2V5X2FsZ29yaXRobSB2
YXJpYWJsZS4NDShnKSBJZiBhIG5hbWUgY29uc3RyYWludHMgZXh0ZW5zaW9uIGlzIGluY2x1ZGVk
IGluIHRoZSBjZXJ0aWZpY2F0ZSwgbW9kaWZ5IHRoZSBwZXJtaXR0ZWRfc3VidHJlZXMgYW5kIGV4
Y2x1ZGVkX3N1YnRyZWVzIHN0YXRlIHZhcmlhYmxlcyBhcyBmb2xsb3dzOg0NKDEpIGlmIHBlcm1p
dHRlZFN1YnRyZWVzIGlzIHByZXNlbnQgaW4gdGhlIGNlcnRpZmljYXRlLCBzZXQgdGhlIHBlcm1p
dHRlZF9zdWJ0cmVlcyBzdGF0ZSB2YXJpYWJsZSB0byB0aGUgaW50ZXJzZWN0aW9uIG9mIGl0cyBw
cmV2aW91cyB2YWx1ZSBhbmQgdGhlIHZhbHVlIGluZGljYXRlZCBpbiB0aGUgZXh0ZW5zaW9uIGZp
ZWxkLiAgSWYgcGVybWl0dGVkU3VidHJlZXMgZG9lcyBub3QgaW5jbHVkZSBhIHBhcnRpY3VsYXIg
bmFtZSB0eXBlLCB0aGUgcGVybWl0dGVkX3N1YnRyZWVzIHN0YXRlIHZhcmlhYmxlIGlzIHVuY2hh
bmdlZCBmb3IgdGhhdCBuYW1lIHR5cGUuDQ0oMikgSWYgZXhjbHVkZWRTdWJ0cmVlcyBpcyBwcmVz
ZW50IGluIHRoZSBjZXJ0aWZpY2F0ZSwgc2V0IHRoZSBleGNsdWRlZF9zdWJ0cmVlcyBzdGF0ZSB2
YXJpYWJsZSB0byB0aGUgdW5pb24gb2YgaXRzIHByZXZpb3VzIHZhbHVlIGFuZCB0aGUgdmFsdWUg
aW5kaWNhdGVkIGluIHRoZSBleHRlbnNpb24gZmllbGQuIElmIGV4Y2x1ZGVkU3VidHJlZXMgZG9l
cyBub3QgaW5jbHVkZSBhIHBhcnRpY3VsYXIgbmFtZSB0eXBlLCB0aGUgZXhjbHVkZWRfc3VidHJl
ZXMgc3RhdGUgdmFyaWFibGUgaXMgdW5jaGFuZ2VkIGZvciB0aGF0IG5hbWUgdHlwZS4NDShoKSBp
ZiB0aGUgaXNzdWVyIGFuZCBzdWJqZWN0IG5hbWVzIGFyZSBub3QgaWRlbnRpY2FsOg0NKDEpIGlm
IGV4cGxpY2l0X3BvbGljeSBpcyBub3QgMCwgZGVjcmVtZW50IGV4cGxpY2l0X3BvbGljeSBieSAx
Lg0oMikgaWYgcG9saWN5X21hcHBpbmcgaXMgbm90IDAsIGRlY3JlbWVudCBwb2xpY3lfbWFwcGlu
ZyBieSAxLg0oMykgaWYgaW5oaWJpdF9hbnktcG9saWN5IGlzIG5vdCAwLCBkZWNyZW1lbnQgaW5o
aWJpdF9hbnktcG9saWN5IGJ5IDEuDQ0oaSkgSWYgYSBwb2xpY3kgY29uc3RyYWludHMgZXh0ZW5z
aW9uIGlzIGluY2x1ZGVkIGluIHRoZSBjZXJ0aWZpY2F0ZSwgbW9kaWZ5IHRoZSBleHBsaWNpdF9w
b2xpY3kgYW5kIHBvbGljeV9tYXBwaW5nIHN0YXRlIHZhcmlhYmxlcyBhcyBmb2xsb3dzOg0NKDEp
IElmIHJlcXVpcmVFeHBsaWNpdFBvbGljeSBpcyBwcmVzZW50IGFuZCBpcyBsZXNzIHRoYW4gZXhw
bGljaXRfcG9saWN5LCBzZXQgZXhwbGljaXRfcG9saWN5IHRvIHRoZSB2YWx1ZSBvZiByZXF1aXJl
RXhwbGljaXRQb2xpY3kuDQ0oMikgSWYgaW5oaWJpdFBvbGljeU1hcHBpbmcgaXMgcHJlc2VudCBh
bmQgaXMgbGVzcyB0aGFuIHBvbGljeV9tYXBwaW5nLCBzZXQgcG9saWN5X21hcHBpbmcgdG8gdGhl
IHZhbHVlIG9mIGluaGliaXRQb2xpY3lNYXBwaW5nLg0NKGopIElmIHRoZSBpbmhpYml0QW55UG9s
aWN5IGV4dGVuc2lvbiBpcyBpbmNsdWRlZCBpbiB0aGUgY2VydGlmaWNhdGUgYW5kIGlzIGxlc3Mg
dGhhbiBpbmhpYml0X2FueS1wb2xpY3ksIHNldCBpbmhpYml0X2FueS1wb2xpY3kgdG8gdGhlIHZh
bHVlIG9mIGluaGliaXRBbnlQb2xpY3kuDQ0oaykgVmVyaWZ5IHRoYXQgdGhlIGNlcnRpZmljYXRl
IGlzIGEgQ0EgY2VydGlmaWNhdGUgKGFzIHNwZWNpZmllZCBpbiBhIGJhc2ljQ29uc3RyYWludHMg
ZXh0ZW5zaW9uIG9yIGFzIHZlcmlmaWVkIG91dC1vZi1iYW5kKS4NDShsKSBJZiB0aGUgY2VydGlm
aWNhdGUgd2FzIG5vdCBzZWxmLWlzc3VlZCwgdmVyaWZ5IHRoYXQgbWF4X3BhdGhfbGVuZ3RoIGlz
IGdyZWF0ZXIgdGhhbiB6ZXJvIGFuZCBkZWNyZW1lbnQgbWF4X3BhdGhfbGVuZ3RoIGJ5IDEuDQ0o
bSkgSWYgcGF0aExlbmd0aENvbnN0cmFpbnQgaXMgcHJlc2VudCBpbiB0aGUgY2VydGlmaWNhdGUg
YW5kIGlzIGxlc3MgdGhhbiBtYXhfcGF0aF9sZW5ndGgsIHNldCBtYXhfcGF0aF9sZW5ndGggdG8g
dGhlIHZhbHVlIG9mIHBhdGhMZW5ndGhDb25zdHJhaW50Lg0NKG4pIElmIGEga2V5IHVzYWdlIGV4
dGVuc2lvbiBpcyBwcmVzZW50IGFuZCBtYXJrZWQgY3JpdGljYWwsIHZlcmlmeSB0aGF0IHRoZSBr
ZXlDZXJ0U2lnbiBiaXQgaXMgc2V0Lg0NKG8pIFJlY29nbml6ZSBhbmQgcHJvY2VzcyBhbnkgb3Ro
ZXIgY3JpdGljYWwgZXh0ZW5zaW9uIHByZXNlbnQgaW4gdGhlIGNlcnRpZmljYXRlLg0NSWYgY2hl
Y2sgKGEpLCAoayksIChsKSwgKG4pIG9yIChvKSBmYWlscywgdGhlIHByb2NlZHVyZSB0ZXJtaW5h
dGVzLCByZXR1cm5pbmcgYSBmYWlsdXJlIGluZGljYXRpb24gYW5kIGFuIGFwcHJvcHJpYXRlIHJl
YXNvbi4NDUlmIChhKSwgKGspLCAobCksIChuKSBhbmQgKG8pIGhhdmUgY29tcGxldGVkIHN1Y2Nl
c3NmdWxseSwgaW5jcmVtZW50IGkgYW5kIHBlcmZvcm0gdGhlIGJhc2ljIGNlcnRpZmljYXRlIHBy
b2Nlc3Npbmcgc3BlY2lmaWVkIGluIDYuMS4yLg0NNi4xLjUgV3JhcC11cCBwcm9jZWR1cmUNDShh
KSBJZiBjZXJ0aWZpY2F0ZSBuIHdhcyBub3Qgc2VsZi1pc3N1ZWQgYW5kIGV4cGxpY2l0X3BvbGlj
eSBpcyBub3QgMCwgZGVjcmVtZW50IGV4cGxpY2l0X3BvbGljeSBieSAxLg0NKGIpIElmIGEgcG9s
aWN5IGNvbnN0cmFpbnRzIGV4dGVuc2lvbiBpcyBpbmNsdWRlZCBpbiB0aGUgY2VydGlmaWNhdGUg
YW5kIHJlcXVpcmVFeHBsaWNpdFBvbGljeSBpcyBwcmVzZW50IGFuZCBoYXMgYSB2YWx1ZSBvZiAw
LCBzZXQgdGhlIGV4cGxpY2l0X3BvbGljeSBzdGF0ZSB2YXJpYWJsZSB0byAwLg0NKGMpIEFzc2ln
biB0aGUgY2VydGlmaWNhdGUgc3ViamVjdFB1YmxpY0tleSB0byB3b3JraW5nX3B1YmxpY19rZXku
DQ0oZCkgSWYgdGhlIHN1YmplY3RQdWJsaWNLZXlJbmZvIGZpZWxkIG9mIHRoZSBjZXJ0aWZpY2F0
ZSBjb250YWlucyBhbiBhbGdvcml0aG0gZmllbGQgd2l0aCBub24tbnVsbCBwYXJhbWV0ZXJzLCBh
c3NpZ24gdGhlIHBhcmFtZXRlcnMgdG8gdGhlIHdvcmtpbmdfcHVibGljX2tleV9wYXJhbWV0ZXJz
IHZhcmlhYmxlLg0NKGUpIEFzc2lnbiB0aGUgY2VydGlmaWNhdGUgc3ViamVjdFB1YmxpY0tleSBh
bGdvcml0aG0gdG8gdGhlIHdvcmtpbmdfcHVibGljX2tleV9hbGdvcml0aG0gdmFyaWFibGUuDQ0o
ZikgUmVjb2duaXplIGFuZCBwcm9jZXNzIGFueSBvdGhlciBjcml0aWNhbCBleHRlbnNpb24gcHJl
c2VudCBpbiB0aGUgY2VydGlmaWNhdGUgbi4NDShnKSBDYWxjdWxhdGUgdGhlIGludGVyc2VjdGlv
biBvZiB0aGUgdmFsaWRfcG9saWN5X3RyZWUgYW5kIHRoZSB1c2VyX2luaXRpYWxfcG9saWN5X3Nl
dCwgYXMgZm9sbG93czoNDShpKSBJZiB0aGUgdmFsaWRfcG9saWN5X3RyZWUgaXMgTlVMTCwgdGhl
IGludGVyc2VjdGlvbiBpcyBOVUxMLg0NKGlpKSBJZiB0aGUgdmFsaWRfcG9saWN5X3RyZWUgaXMg
bm90IE5VTEwgYW5kIHRoZSB1c2VyX2luaXRpYWxfcG9saWN5X3NldCBpcyCTYW55LXBvbGljeZQs
IHRoZSBpbnRlcnNlY3Rpb24gaXMgdGhlIGVudGlyZSB2YWxpZF9wb2xpY3lfdHJlZS4NDShpaWkp
IElmIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSBpcyBub3QgTlVMTCBhbmQgdGhlIHVzZXJfaW5pdGlh
bF9wb2xpY3lfc2V0IGlzIG5vdCCTYW55LXBvbGljeZQsIGNhbGN1bGF0ZSB0aGUgaW50ZXJzZWN0
aW9uIG9mIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSBhbmQgdGhlIHVzZXJfaW5pdGlhbF9wb2xpY3lf
c2V0IGFzIGZvbGxvd3M6DQ0xLiBkZXRlcm1pbmUgdGhlIHNldCBvZiBwb2xpY3kgbm9kZXMgd2hv
c2UgcGFyZW50IG5vZGVzIGhhdmUgYSB2YWxpZF9wb2xpY3kgb2Ygk2FueS1wb2xpY3mULiAgVGhp
cyBpcyB0aGUgdmFsaWRfcG9saWN5X25vZGVfc2V0Lg0yLiBpZiB0aGUgdmFsaWRfcG9saWN5IG9m
IGFueSBub2RlIGluIHRoZSB2YWxpZF9wb2xpY3lfbm9kZV9zZXQgaXMgbm90IGluIHRoZSB1c2Vy
X2luaXRpYWxfcG9saWN5X3NldCBhbmQgaXMgbm90IJNhbnktcG9saWN5lCwgZGVsZXRlIHRoaXMg
bm9kZSBhbmQgYWxsIGl0cyBjaGlsZHJlbi4NMy4gaWYgdGhlcmUgaXMgYSBub2RlIGluIHRoZSB2
YWxpZF9wb2xpY3lfdHJlZSBvZiBkZXB0aCBuLTEgb3IgbGVzcyB3aXRob3V0IGFueSBjaGlsZCBu
b2RlcywgZGVsZXRlIHRoYXQgbm9kZS4gUmVwZWF0IHRoaXMgc3RlcCB1bnRpbCB0aGVyZSBhcmUg
bm8gbm9kZXMgb2YgZGVwdGggbi0xIG9yIGxlc3Mgd2l0aG91dCBjaGlsZHJlbi4NDVVwb24gY29t
cGxldGlvbiBvZiBhbGwgc3RlcHMsIHBhdGggcHJvY2Vzc2luZyBoYXMgc3VjY2VlZGVkIGlmIHRo
ZSB2YWx1ZSBvZiBleHBsaWNpdF9wb2xpY3kgdmFyaWFibGUgaXMgZ3JlYXRlciB0aGFuIHplcm8s
IG9yIHRoZSB2YWxpZF9wb2xpY3lfdHJlZSBpcyBub3QgTlVMTC4NDTYuMS42IE91dHB1dHMNDUlm
IHBhdGggcHJvY2Vzc2luZyBzdWNjZWVkcywgdGhlIHByb2NlZHVyZSB0ZXJtaW5hdGVzLCByZXR1
cm5pbmcgYSBzdWNjZXNzIGluZGljYXRpb24gdG9nZXRoZXIgd2l0aCBmaW5hbCB2YWx1ZSBvZiB0
aGUgdmFsaWRfcG9saWN5X3RyZWUsIHRoZSB3b3JraW5nX3B1YmxpY19rZXksIHRoZSB3b3JraW5n
X3B1YmxpY19rZXlfYWxnb3JpdGhtLCBhbmQgdGhlIHdvcmtpbmdfcHVibGljX2tleV9wYXJhbWV0
ZXJzLg0NGAChAQCk0C+l4D2mCAenCAeooAWpoAWqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AwAADAUAAEkFAABKBQAABwYAAKcHAAB4CQAAzAsAAHINAAC9EQAA5BEAAPERAABPEgAAgRIAAIIS
AAANEwAADBQAAOQUAADiGAAA9xgAAGUxAACIMQAA2jIAAKUzAAAINgAAQDcAALA+AACxPgAAAUYA
AJNGAADrTQAAMFAAAKNUAACkVAAApVUAAGxWAADvVgAAhVcAAIZXAACsVwAAC1gAAB5ZAAAfWQAA
MloAADNaAACDWwAADl4AAHJeAABLYAAAgmEAALphAAD7YQAAE2MAAJhjAAC/ZQAAwGUAAL5mAAAS
ZwAAGmgAADJoAAAzaAAASWkAAEJqAAD8agAA82wAAHRtAAB9bwAAi28AAHdwAAB4cAAAknAAAP0A
/QD9AP0A/QD7/QD9AP0A/fn9+f0A/QD9AP0A/QD9AP0A/QD99v0A/QD9AP0A/QD9AP0A/QD9AP35
/QD9AP0A/fb9APQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ1AQAFXQMAXgECVYEAAl4BAANdAwAARgAD
AAABAwAAGwMAABwDAADyAwAA9AMAAAwFAAANBQAASQUAAEoFAACmBQAApwUAANgFAADaBQAABwYA
AAgGAACmBwAApwcAAF0IAAC9CAAA7wgAACYJAAB4CQAAeQkAAMsLAADMCwAAcQ0AAHINAACJDQAA
oA0AALcNAADKDQAA3Q0AAPkNAAAVDgAAMQ4AAEQOAABtDgAAlg4AAL8OAADoDgAAEQ8AADoPAAD9
AAHAIdMA/QABwCHTAP0AAcAh0wD9AATAIdMA/QABwCHTAP0ABMAh0wD4AAHAIdMA+AABwCHTAP0A
AcAh0wDzAALAIdMA8wABwCHTAPMAAcAh0wDzAAHAIdMA8wABwCHTAP0AAcAh0wD9AAbAIdMA/QAB
wCHTAPgAA8Ah0wDzAALAIdMA8wABwCHTAPMAAcAh0wDzAALAIdMA/QABwCHTAP0ACcAh0wD9AAHA
IdMA8AAHwCHTAPAAAcAh0wDuAAHAIdMA7gABwCHTAO4AAcAh0wDuAAHAIdMA7gABwCHTAO4AAcAh
0wDuAAHAIdMA7gABwCHTAO4AAcAh0wDuAAHAIdMA7gABwCHTAO4AAcAh0wDuAAHAIdMA7gABwCHT
AO4AAcAh0wAAAAAAAAAAAAAAAQAAAAIPADMBAAQRABHQAjMBAAAEEgARAAAzAQAAAgAAMwEqOg8A
AGMPAACMDwAAtQ8AAN4PAAAHEAAAMBAAAFkQAACCEAAAqxAAANQQAAD9EAAAJhEAAE8RAAB4EQAA
oREAAK8RAAC9EQAAvhEAAOMRAADkEQAA8REAAE4SAABPEgAAgRIAAIISAAANEwAADhMAAAsUAAAM
FAAA5BQAAAEVAAA3FQAAXRUAAH0VAADPFQAA0BUAAFoXAABbFwAAxxcAAMgXAAD+AAHAIdMA/gAB
wCHTAP4AAcAh0wD+AAHAIdMA/gABwCHTAP4AAcAh0wD+AAHAIdMA/gABwCHTAP4AAcAh0wD+AAHA
IdMA/gABwCHTAP4AAcAh0wD+AAHAIdMA/gABwCHTAP4AAcAh0wD+AAHAIdMA/gABwCHTAPsAAcAh
0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD4AALAIdMA+AABwCHTAPMAAcAh0wDuAAHAIdMA6wADwCHT
AO4AAcAh0wDuAAXAIdMA7gABwCHTAOgABMAh0wDjAAHAIdMA4wABwCHTAOMAAcAh0wDjAAHAIdMA
4wACwCHTAO4AAcAh0wDuAAfAIdMA7gABwCHTAO4AAsAh0wDuAAHAIdMAAAAAAAAAAAAAAAQAABGg
BTMBAAACEgAzAQACEAAzAQAEAAAR0AIzAQAABBEAEdACMwEAAAIAADMBAAIPADMBAAEAACjIFwAA
XBgAAF0YAADhGAAA4hgAAPcYAAD4GAAAURkAAFMZAABrGwAAbBsAAIMcAADlHAAATR0AAMkdAAA+
HgAAPx4AAEIfAABDHwAABSAAAAYgAAAcIAAARyAAAF0gAACJIAAAnyAAANMgAADpIAAAGyEAADEh
AAAyIQAAciEAAHMhAABTIwAAVCMAAKIkAACjJAAAoCYAAKEmAADMKAAAzSgAAMUqAADGKgAAuCsA
APsAA8Ah0wD7AAHAIdMA+wACwCHTAPgAAcAh0wD1AAHAIdMA+AABwCHTAPgAAsAh0wD4AAHAIdMA
+wAJwCHTAPsAAcAh0wD7AAXAIdMA8AACwCHTAPAAAsAh0wDwAAPAIdMA8AACwCHTAPsAAcAh0wD7
AAXAIdMA+wABwCHTAPsAA8Ah0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA+wABwCHTAPsA
AcAh0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA+wAI
wCHTAPsAAcAh0wD7AAbAIdMA+wABwCHTAPsACMAh0wD7AAHAIdMA+wAJwCHTAPsAAcAh0wD7AAjA
IdMA+wABwCHTAPsABMAh0wAAAAAEAAARoAUzAQAAAgEAMwEAAgAAMwEABAAAEdACMwEAK7grAAC5
KwAAfCwAAH4sAABWLgAAVy4AACYvAAAnLwAAczAAAHQwAADzMAAA9DAAAGQxAABlMQAAiDEAAIkx
AADfMQAA4DEAABkyAAAaMgAApDIAAKUyAADaMgAA2zIAAKUzAACmMwAA5jMAAOczAAA4NAAAjDQA
ANQ0AADVNAAABjYAAAg2AAA/NwAAQDcAAPs3AAD9NwAAmDgAAIY5AACHOQAADTsAAPsAAcAh0wD7
AATAIdMA+wABwCHTAPsACMAh0wD7AAHAIdMA+wAEwCHTAPsAAcAh0wD7AAbAIdMA+wABwCHTAPsA
AsAh0wD7AAHAIdMA+AACwCHTAPgAAcAh0wD1AAHAIdMA+AABwCHTAPgAAsAh0wD4AAHAIdMA+wAB
wCHTAPAAAcAh0wDwAAPAIdMA8AABwCHTAPAAAcAh0wDtAAHAIdMA7QAEwCHTAPAAAcAh0wDwAALA
IdMA8AABwCHTAPAAAsAh0wDoAALAIdMA6AACwCHTAPsAAcAh0wD7AAXAIdMA+wABwCHTAOUABcAh
0wDlAAHAIdMA+wADwCHTAPsAAcAh0wDwAAPAIdMA6AAFwCHTAOgAAcAh0wDoAAjAIdMAAAAAAhAA
MwEABAAAEXAIMwEAAAIRADMBAAQAABGgBTMBAAACAQAzAQACAAAzAQAEAAAR0AIzAQApDTsAAA47
AAAPOwAANzsAAF87AACHOwAArzsAAOs7AAATPAAAOzwAAGM8AACLPAAAqjwAAMk8AADoPAAABz0A
AC89AABXPQAAfz0AAKc9AADfPQAABz4AAC8+AABXPgAAfz4AAIA+AACwPgAAsT4AAM4/AADPPwAA
qEEAAKlBAACqQQAA0kEAAPpBAAAiQgAASkIAAIRCAACsQgAA1EIAAPxCAAAkQwAASUMAAG9DAAD7
AAHAIdMA9gABwCHTAPYAAcAh0wD2AAHAIdMA9gABwCHTAPYAAcAh0wD2AAHAIdMA9gABwCHTAPYA
AcAh0wD2AAHAIdMA9gABwCHTAPYAAcAh0wD2AAHAIdMA9gABwCHTAPYAAcAh0wD2AAHAIdMA9gAB
wCHTAPYAAcAh0wD2AAHAIdMA9gABwCHTAPYAAcAh0wD2AAHAIdMA9gABwCHTAPYAAcAh0wD2AAHA
IdMA9gABwCHTAPMAAcAh0wD7AAbAIdMA+wABwCHTAPsACcAh0wD7AAHAIdMA9gABwCHTAPYAAcAh
0wD2AAHAIdMA9gABwCHTAPYAAcAh0wD2AAHAIdMA9gABwCHTAPYAAcAh0wD2AAHAIdMA9gABwCHT
APYAAcAh0wD2AAHAIdMAAAAAAAAAAAAAAhMAMwEABAAAEdACMwEAAAQAABFwCDMBACtvQwAAlkMA
AL5DAAD1QwAALEQAAGNEAACaRAAA0UQAAAhFAAA/RQAAdkUAAK1FAACuRQAAr0UAAABGAAABRgAA
kkYAAJNGAAAjSAAAJEgAAHxJAAB9SQAApUkAAM1JAAD1SQAAHUoAAFdKAAB/SgAAp0oAAM9KAAD3
SgAAHEsAAEJLAABpSwAAkUsAAMhLAAD/SwAANkwAAG1MAACkTAAA20wAABJNAABJTQAA+wABwCHT
APsAAcAh0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA
+wABwCHTAPsAAcAh0wD7AAHAIdMA+wABwCHTAPsAAsAh0wD2AAHAIdMA8wADwCHTAPMAAcAh0wDu
AAjAIdMA7gABwCHTAO4AB8Ah0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA+wABwCHTAPsA
AcAh0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA+wAB
wCHTAPsAAcAh0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHA
IdMAAAAAAAAAAAAAAAQAABFwCDMBAAACEQAzAQAEAAARoAUzAQAABAAAEdACMwEAKklNAACATQAA
gU0AAIJNAADqTQAA600AAOxNAACtTgAArk4AAC9QAAAwUAAAMVAAAExQAABuUAAAolAAAMRQAADm
UAAACVEAAC1RAABSUQAAhFEAAL9RAAABUgAANFIAAGhSAACrUgAA7FIAACxTAABXUwAAg1MAALBT
AADzUwAANFQAAHJUAABzVAAAo1QAAKRUAAClVAAApVUAAKZVAAADVgAA+wABwCHTAPsAAcAh0wD7
AAHAIdMA+wACwCHTAPYAAcAh0wDxAAHAIdMA7gAEwCHTAO4AAcAh0wDuAAfAIdMA7gABwCHTAPsA
AcAh0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA+wAB
wCHTAPsAAcAh0wD7AAHAIdMA6wABwCHTAOsAAcAh0wDrAAHAIdMA+wABwCHTAPsAAcAh0wD7AAHA
IdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA+wABwCHTAPsAAcAh0wD7AAHAIdMA+wABwCHTAPsAAcAh
0wDuAAHAIdMA5gABwCHTAOYABcAh0wDhAAHAIdMA4QACwCHTAAAAAAAAAAQTABHQAjMBAAAEAAAR
oAUzAQAAAgAAMwEAAhEAMwEABBEAEXAIMwEAAAQAABFwCDMBAAAEAAAR0AIzAQAoA1YAAARWAABs
VgAAbVYAAO5WAADvVgAAhVcAAIZXAACsVwAArVcAAApYAAALWAAAp1gAAKhYAAAdWQAAHlkAAB9Z
AAAyWgAAM1oAAGVaAABmWgAAv1oAAMBaAACCWwAAg1sAAMNbAADEWwAAB1wAAAhcAAC8XAAAvVwA
AHxdAAANXgAADl4AAHJeAAD7AAHAIdMA+wACwCHTAPUAAcAh0wDyAALAIdMA8gABwCHTAO0AA8Ah
0wDnAAHAIdMA8gABwCHTAOEAAcAh0wDyAALAIdMA5wABwCHTANwAA8Ah0wDcAAHAIdMA3AACwCHT
ANwAAcAh0wD1AAHAIdMA1wAFwCHTANIAAcAh0wDXAAHAIdMAzwABwCHTAM8AAsAh0wDPAAHAIdMA
zwAEwCHTAMoAAcAh0wDFAAHAIdMAxQABwCHTAMUAAcAh0wDFAAHAIdMAxQADwCHTAMUAAcAh0wDF
AAPAIdMAxQADwCHTAPIAAcAh0wDCAALAIdMAAAAAAAAAAAAAAAISADMBAAQAABHQAjMBAAAEDwAR
0AIzAQAAAhMAMwEABAAAEXAIMwEAAAQTABGgBTMBAAAEEQAR0AIzAQAABQAAEXAIE9ACMwEABQAA
EaAFE9ACMwEABBIAEQAAMwEAAAIAADMBAAUAABHQAhPQAjMBAAQTABHQAjMBACJyXgAAc14AAAdf
AAAIXwAASmAAAEtgAACBYQAAgmEAALlhAAC6YQAA+2EAADpiAACBYgAAgmIAABJjAAATYwAAmGMA
AJljAAAaZAAAG2QAAL5kAAC/ZAAAPmUAAD9lAADAZQAAwWUAAFdmAABYZgAAvWYAAL5mAAARZwAA
EmcAAJBnAACRZwAAGWgAABpoAAAyaAAAM2gAAJpoAACbaAAASGkAAPsAAcAh0wD7AAPAIdMA+wAB
wCHTAPYABsAh0wD2AAHAIdMA8wAGwCHTAO4AAcAh0wD7AAHAIdMA+wABwCHTAPMAAsAh0wD2AALA
IdMA9gACwCHTAPsAAcAh0wD7AAPAIdMA+wABwCHTAPMAA8Ah0wD2AAHAIdMA9gADwCHTAPsAAcAh
0wD7AAPAIdMA6wABwCHTAPsAAsAh0wD7AAHAIdMA+wADwCHTAPYAAcAh0wD7AAPAIdMA6wABwCHT
APsAAsAh0wD7AAHAIdMA6AACwCHTAOMAAcAh0wDrAALAIdMA6wABwCHTAOsAAsAh0wDrAAHAIdMA
4AABwCHTAOsAAcAh0wDjAALAIdMA4wABwCHTAOMAA8Ah0wAAAAAAAgEAMwEABBIAEQAAMwEAAAIS
ADMBAAIAADMBAAQRABHQAjMBAAACEQAzAQAEAAARoAUzAQAABAAAEdACMwEAKEhpAABJaQAAjGkA
AI1pAABBagAAQmoAAKZqAACnagAA/GoAAP1qAABiawAAY2sAAKNrAACkawAAMWwAADJsAADybAAA
82wAAHRtAAAabgAA2m4AANtuAAB8bwAAfW8AAItvAACMbwAAd3AAAHhwAAD7AAHAIdMA+AABwCHT
APMAAcAh0wD4AAPAIdMA+AABwCHTAPsAAsAh0wD7AAHAIdMA+wACwCHTAPgAAcAh0wD4AALAIdMA
+AABwCHTANAAAcAh0wDzAAHAIdMA8wADwCHTAPMAAcAh0wDzAATAIdMA8wABwCHTAMsAA8Ah0wDG
AATAIdMAxgAEwCHTAPgAAcAh0wC+AAPAIdMA+AABwCHTAPgAAcAh0wD4AAHAIdMA+AAEwCHTAPgA
AcAh8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAEeABMwEPBQABwAMAAAQAABGgBTMBAAAEEgAR
oAUzAQAAIgAAEdACMwEMNAIBAQgAAAAAAAABANACAAAAAAAAKCkAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAPBQABoAUAAAQAABHQAjMBAAACAAAzAQAEEgARAAAzAQAbDgAUAAgAAQBLAA8A
AAAAAB4AAEDx/wIAHgAGTm9ybWFsAAQAAAAzAAYAXQQAYQkEJAABQAEAAgAkAAlIZWFkaW5nIDEA
AAQAAQAIAQcAVYFdAwBeAQAAAAAAAAAAAAAAAAAAAAAAIgBBQPL/oQAiABZEZWZhdWx0IFBhcmFn
cmFwaCBGb250AAAAAAAAAAAAAAAeAP5PAQDyAB4AClBsYWluIFRleHQAAgAPAAMAXQMAACQA/k8B
AAIBJAALQm9keSBUZXh0IDIAAAUAEAAR0AIAAwBdAwAAKgD+TwEAEgEqABJCb2R5IFRleHQgSW5k
ZW50IDIABQARABGgBQADAF0DAAAkAP5PAQAiASQADEJvZHkgVGV4dCAyMQAFABIAEdACAAMAXQMA
ACoA/k8BADIBKgASQm9keSBUZXh0IEluZGVudCAzAAUAEwARcAgAAwBdAwAAAAAAAHhtAAADAHhw
AAAAAP////8MAAQh//8BAAAh//8CAAQh//8DAAAh//8EAAQg//8FAAAg//8GAAQg//8HAAAg//8I
AAQg//8JAAAg//8KAAQg//8LAAAg//8MAAAAAADKCgAAjhMAANMdAAB+KQAACDMAAM88AADNRgAA
NFEAAL1ZAADBYgAAkGsAAHhtAAAAABMAAAABAMwAAAACABYAAAADANgBAAAEADcBAAAFANkBAAAG
ACgAAAAHAD4AAAAIAL8AAAAJAJYAAAAKAEoAAAALAAAAAAAAAwAAknAAADkAAAMAADoPAADIFwAA
uCsAAA07AABvQwAASU0AAANWAAByXgAASGkAAHhwAAA6ADsAPAA9AD4APwBAAEEAQgBDAAAAAABe
BQAAXwUAAPwLAAAADAAAyQwAAM0MAACaDQAAmw0AABkOAAAdDgAAEhAAACkQAACZEAAAsBAAAEMV
AABaFQAAVxYAAGgWAAB9GAAAjhgAAIQZAACFGQAAixkAAJcZAADuGQAA+xkAAFcaAABsGgAA0hoA
AOUaAAACGwAABhsAAFgbAABpGwAAgBsAAIwbAACkGwAAsRsAALYbAADJGwAA9BsAAAkcAACEHAAA
lRwAANscAADsHAAAOh0AAEYdAAB7HQAAiB0AAL0dAADSHQAABx4AABoeAABRHgAAYh4AAHceAACJ
HgAA6R4AAOseAAAJHwAAER8AAOsfAAD4HwAAWCAAAGkgAADKIAAAzCAAAOogAADyIAAApyEAALYh
AADhIQAA8iEAAPQiAAAFIwAApSMAALAjAADRJQAA3yUAAMonAADmJwAAPCgAAFgoAAC9KAAAzygA
ABQpAAAmKQAAfykAAIApAACCKQAAnykAACIqAAA/KgAA6yoAAAgrAABbKwAAbisAAMMrAADWKwAA
KywAAD0sAACPLAAAoSwAAP0sAAAPLQAAeC0AAIctAADLLgAAzC4AAEIvAABeLwAAaS8AAHsvAACE
LwAAoS8AAM0wAADgMAAAGzEAAC0xAAA5MQAAOjEAADwxAABOMQAAkTEAAKMxAADoMQAA6TEAADAy
AABCMgAAlzIAAKUyAAC9MgAAyDIAAN8yAADxMgAAGzMAABwzAABnMwAAeDMAAM0zAADbMwAA8zMA
AP4zAAAZNAAAKjQAAHw0AACINAAAkTQAAKI0AACZNQAAmjUAAKM1AAC0NQAA6DUAAPs1AAAlNgAA
MTYAAEQ2AABRNgAAZjYAAHk2AACgNgAAsTYAANU2AADoNgAA1DcAANU3AADdOgAA3joAAPY6AAAD
OwAA1TsAANY7AADhOwAA8jsAAG08AAB5PAAAjDwAAJk8AACuPAAAwTwAAOg8AAD5PAAAHT0AACk9
AAAyPgAAMz4AAG0+AABuPgAA2UEAAOZBAADxQQAA8kEAAPZBAAADQgAAbEMAAHdDAACoQwAAuUMA
AN5DAADxQwAAaEQAAHREAACLRAAAnkQAALtEAADIRAAA3kQAAPFEAAAGRQAAEkUAAD1FAABORQAA
ckUAAIVFAADqRQAA60UAADtGAAA8RgAArEkAALlJAADESQAAxUkAAMlJAADWSQAACksAABtLAADJ
SwAA2ksAAHBRAABxUQAAkVEAAKJRAADvUQAABFIAABtSAAAcUgAAbVIAAIJSAACZUgAAmlIAAOhS
AAD5UgAAG1MAACpTAABEUwAAVVMAAPJTAADzUwAASVQAAEpUAAAHVQAACFUAAHpVAACMVQAAklUA
AKVVAADkVQAA9lUAACpWAAA4VgAAalYAAHtWAACFVgAAhlYAAJlWAAClVgAAq1YAAL5WAADNVgAA
4FYAAD5XAABMVwAAZ1cAAGhXAACEVwAAhVcAAI1XAACeVwAAsVcAAL1XAADfVwAA8FcAAK5YAADB
WAAA31gAAO9YAADzWAAABVkAAJRZAACxWQAAPFoAAExaAABeWgAAeloAAI9aAACfWgAAsloAAM5a
AADmWgAAA1sAAClbAAA5WwAAS1sAAGdbAADCWwAA1FsAANlbAADqWwAAD1wAACBcAABIXAAAWlwA
AMhcAADZXAAAB10AABldAABSXQAAYl0AAIpdAACbXQAAAV4AABFeAAA/XgAAUF4AAMFeAADQXgAA
5V4AAPReAAACXwAAEF8AACVfAAAzXwAAQV8AAExfAABoXwAAc18AAINfAACEXwAA018AAOJfAADn
XwAA9V8AABpgAAAvYAAATGAAAFtgAABhYAAAcGAAAIFgAACWYAAAoGAAALRgAADRYAAA32AAAOVg
AADzYAAABGEAABhhAAAmYQAANmEAAHFhAAB8YQAAiWEAAJRhAACsYQAAvGEAAAZiAAAWYgAAd2IA
AIZiAACqYgAAuWIAAMhiAADcYgAADGMAABtjAAAhYwAAMGMAAEFjAABVYwAApWMAALBjAADWZAAA
12QAAGBlAABvZQAAhGUAAJNlAADkZQAA+WUAACNmAAAyZgAAZGYAAHRmAAB4ZgAAimYAABlnAAA2
ZwAAXWcAAG1nAAB/ZwAAm2cAACNoAAA0aAAAPWgAAFRoAABkaAAAZWgAAG5oAAB/aAAAsGgAAMFo
AADWaAAA7WgAAB5pAAAvaQAAP2kAAFBpAABlaQAAfGkAALRpAADFaQAAzmkAAOVpAAAyagAAPmoA
AF1qAAByagAAfmoAAIpqAACeagAAs2oAAMJqAADZagAAN2sAAEhrAAAnbAAANmwAAF1sAABubAAA
A20AABRtAAAabQAALG0AADJtAABObQAAWG0AAHVtAAB6bQAABwAcAAcAHAAHABwABwAbAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwDpABxWYWx1ZWQgR2F0ZXdheSAyMDAwIEN1c3RvbWVy
NEM6XHByb2dyYW0gZmlsZXNcZXVkb3JhXGF0dGFjaFxSZXZpc2VkUGF0aHByb2M2YS5kb2McVmFs
dWVkIEdhdGV3YXkgMjAwMCBDdXN0b21lcjRDOlxwcm9ncmFtIGZpbGVzXGV1ZG9yYVxhdHRhY2hc
UmV2aXNlZFBhdGhwcm9jNmIuZG9jHFZhbHVlZCBHYXRld2F5IDIwMDAgQ3VzdG9tZXIlQzpcTXkg
RG9jdW1lbnRzXFJldmlzZWRQYXRocHJvYzZjLmRvY/9ATGV4bWFyayBPcHRyYSBwbHVzIFBTMgBc
XEtBVEhFUklORVxMZXhtYXJrAExFWFBTAExleG1hcmsgT3B0cmEgcGx1cyBQUzIATGV4bWFyayBP
cHRyYSBwbHVzIFBTMgAAAAAAAAAAAAAABPcBlADTAh9XAAABAAEA6gpvCGQAAQAHAFgCAQABAAAA
AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAEAAAACAAAAAAAAAAAAAAAAAAAAAAAAAExleG1hcmsgT3B0cmEgcGx1cyBQUzIAAAAAAAAAAAAA
WAIAAP4BAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAChOb25lKQAA
AAAAAAAAAAAAAAAAAAAAAChOb25lKQAAAAAAAAAAAAAAAAAAAAAAAChOb25lKQAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoTm9uZSkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAWALCAQEAWgBaAAAAAAAAAAEAAgAAAAAAAAAAAAAAAADYAgAAAABlAPUBAgAAAAAAAAAB
AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAA
AQABAAAAAQAAAAAALAEsAVgCwgFYAlgCWALCAbAEsAQkBMIBAAAAAAAAAAAAAAAAAAAAAAGAAgAC
gAIAA4ACAASAAgAFgAIABoACAAeAAgAIgAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgA
AQALAAEABAACAAcAAQABAAEAAgAIAAUAAQAgAAMABgABABYAAQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAYAQBMZXhtYXJrIE9wdHJhIHBsdXMgUFMyAAAAAAAAAAAAAAAE9wGUANMCH1cAAAEAAQDq
Cm8IZAABAAcAWAIBAAEAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAAAAAAAAAAAAAAAAAAAAAAATGV4bWFyayBPcHRyYSBw
bHVzIFBTMgAAAAAAAAAAAABYAgAA/gEBAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAKE5vbmUpAAAAAAAAAAAAAAAAAAAAAAAAKE5vbmUpAAAAAAAAAAAAAAAAAAAAAAAA
KE5vbmUpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAChOb25lKQAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAsIBAQBaAFoAAAAAAAAAAQACAAAAAAAAAAAAAAAAANgC
AAAAAGUA9QECAAAAAAAAAAEAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAIAAAABAAEAAAABAAAAAAAsASwBWALCAVgCWAJYAsIBsASwBCQEwgEAAAAA
AAAAAAAAAAAAAAAAAYACAAKAAgADgAIABIACAAWAAgAGgAIAB4ACAAiAAgAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAACAABAAsAAQAEAAIABwABAAEAAQACAAgABQABACAAAwAGAAEAFgABAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAABgBAAGAAQDrHwAA6x8AAAsAAQBIAOsfAAAAAAAA6x8AAFcA
FRaQAQAAVGltZXMgTmV3IFJvbWFuAAwWkAECAFN5bWJvbAALJpABAABBcmlhbAARNZABAABDb3Vy
aWVyIE5ldwATIpABAABNUyBTYW5zIFNlcmlmACIABABBAIgYAADQAgAAAAAAAAAAIWQ6RiFkOkaH
KzpGAgAAAAAA1Q8AAENaAAAMAC4AAAAAAAAAwAAAAAAAAAAAAAAADAABAAAAAQAAAAAAAAC0BAAA
AACAAAAANEJpbGwgQnVyciBIYWNrIGF0IHRoZSBQS0lYIFBhdGggVmFsaWRhdGlvbiBBbGdvcml0
aG0AAAAcVmFsdWVkIEdhdGV3YXkgMjAwMCBDdXN0b21lchxWYWx1ZWQgR2F0ZXdheSAyMDAwIEN1
c3RvbWVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAA
BwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAV
AAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMA
AAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAA
ADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAA
QAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABO
AAAATwAAAP7////9////VAAAAP7///9cAAAA/v//////////////////////////////////////
///+////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAABw
FwAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AQAAAAAJ
AgAAAAAAwAAAAAAAAEYAAAAA4GtpnDwQvwEAxoYZ8RS/AVMAAAAABAAAAAAAAFcAbwByAGQARABv
AGMAdQBtAGUAbgB0AAAAQwDI4fplVGdFAAgR3H9UZ0UAEDrcf1RnRQA852IA/H9BAHgnRwAaAAIB
AgAAAAMAAAD/////AAAAAI+S978AAEAAAAAAAGjnYgBM7GIAWP9DAKiT+mVU/0MAAAAAAGCeAAAB
AAAAAQBDAG8AbQBwAE8AYgBqAAAAQAAAAAAAIOtiAPHpYgABAAAAtOhiALT/AFDx6WIAtOdiAAEA
AAAAAAAAtOdiABIAAgH///////////////8AAAAA8eliAK8jB1C052IA8eliAAAAAAAAAAAAAAAA
AAAAAAAAAAAAagAAACgAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAA
bW1vbiBGaWxlc1xNaWNyb3NvZnQgU2hhKAACAf////8EAAAA/////2wzMi5jbnYsIGh0bSAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAcAgAAAAAAAAEAAAD+////AwAAAAQAAAAFAAAABgAAAAcA
AAAIAAAACQAAAAoAAAD+////DAAAAA0AAAAOAAAADwAAAP7/////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////AQD+/wMKAAD/////AAkCAAAAAADAAAAAAAAA
RhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3Vt
ZW50LjYA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAA
AAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAADsAQAAEgAAAAEAAACYAAAAAgAAAKAA
AAADAAAA4AAAAAQAAADsAAAABQAAABQBAAAGAAAAIAEAAAcAAAAsAQAACAAAAEABAAAJAAAAaAEA
ABIAAAB0AQAACgAAAJwBAAALAAAAqAEAAAwAAAC0AQAADQAAAMABAAAOAAAAzAEAAA8AAADUAQAA
EAAAANwBAAATAAAA5AEAAAIAAADkBAAAHgAAADUAAABCaWxsIEJ1cnIgSGFjayBhdCB0aGUgUEtJ
WCBQYXRoIFZhbGlkYXRpb24gQWxnb3JpdGhtAMYFAB4AAAABAAAAAMhHAB4AAAAdAAAAVmFsdWVk
IEdhdGV3YXkgMjAwMCBDdXN0b21lcgApRwAeAAAAAQAAAACwSAAeAAAAAQAAAAC5QQAeAAAACwAA
AE5vcm1hbC5kb3QAAB4AAAAdAAAAVmFsdWVkIEcFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEA
cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP///////////////wAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAAAIAQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////
////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC
1c3VnC4bEJOXCAArLPmuMAAAANgAAAAIAAAAAQAAAEgAAAAPAAAAUAAAAAQAAABgAAAABQAAAGgA
AAAGAAAAcAAAAAsAAAB4AAAAEAAAAIAAAAAMAAAAiAAAAAIAAADkBAAAHgAAAAUAAABOSVNUACZH
AAMAAAAAvAAAAwAAAMAAAAADAAAALgAAAAsAAAAAAAAACwAAAAAAAAAMEAAAAgAAAB4AAAA1AAAA
QmlsbCBCdXJyIEhhY2sgYXQgdGhlIFBLSVggUGF0aCBWYWxpZGF0aW9uIEFsZ29yaXRobQADAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAYXRld2F5IDIwMDAgQ3VzdG9tZXIA90gAHgAAAAIAAAAyAEMA
HgAAAB4AAABNaWNyb3NvZnQgV29yZCBmb3IgV2luZG93cyA5NQCDLkAAAAAAAAAAAAAAAEAAAAAA
ejlrXA+/AUAAAAAApnv58BS/AUAAAAAApnv58BS/AQMAAAAMAAAAAwAAANUPAAADAAAAQ1oAAAMA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAA
AAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA2AAAAAgAAAABAAAASAAAAA8AAABQAAAA
BAAAAGAAAAAFAAAAaAAAAAYAAABwAAAACwAAAHgAAAAQAAAAgAAAAAwAAACIAAAAAgAAAOQEAAAe
AAAABQAAAE5JU1QAJkcAAwAAAAC8AAADAAAAwAAAAAMAAAAuAAAACwAAAAAAAAALAAAAAAAAAAwQ
AAACAAAAHgAAADUAAABCaWxsIEJ1cnIgSGFjayBhdCB0aGUgUEtJWCBQYXRoIFZhbGlkYXRpb24g
QWxnb3JpdGhtAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAA=
--=====================_939864999==_--



Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.imc.org (8.9.3/8.9.3) with SMTP id NAA13955 for <[e-mail]>; Wed, 13 Oct 1999 13:11:13 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Oct 1999 20:12:06 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA28256; Wed, 13 Oct 1999 16:07:43 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <4YXC095X>; Wed, 13 Oct 1999 16:14:49 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "Salz, Rich" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Wed, 13 Oct 1999 16:19:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Denis proposed the following as a candidate functional scope for an OCSP-X:

> 
> 1) validating a certificate * for a given time * against some rules
> which would desribe an acceptable certification *forest* to be used
> (a forest has several trees and thus several roots to be fully
> explicit).
> 
> 2) giving back to the user the certification path (i.e. the
> certificate identifiers - not necessarilly the certificates
> themselves) that have been used * for that given time * for the
> validation, including the relevant revocation (i.e. CRLs) or status
> (i.e. OSCP responses) information.
> 
> This would be quite sufficient at the time being.
> 

I agree that this would be a useful core set.  Further, return of (2) could
be optional.  It would be useful to those clients which wish to retrace the
path validation performed by the server, to display the path if needed, or
to record information for audit purposes.  If none of these cases hold,
return of the data collected by the server during the validation process
seems redundant. 

--jl


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA10507 for <[e-mail]>; Wed, 13 Oct 1999 09:12:33 -0700 (PDT)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FJJUG800.L4R for <[e-mail]>; Wed, 13 Oct 1999 16:14:32 +0000 
Received: from nma.com ([209.21.28.110]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FJJUFT00.9EL; Wed, 13 Oct 1999 16:14:17 +0000 
Message-ID: <[e-mail]>
Date: Wed, 13 Oct 1999 09:14:27 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: "Salz, Rich" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Denis Pinkas wrote:

> >
> > I share Stephen's concerns about PKIX getting involved in authorization; I
> > think it's way too premature.

I agree, except if the implict assumptions in the RFC (see my last msg) are
made explict.  Then, the RFC could specify authorization but with clear
trust metrics to be applied, not just trust points as it does today.  In
practice, though, this would not be very much different than what you
suggest below, which also IMO deals with authorization. For example,
you define one such trust metric below, authorizing a certificate to be
used if it meets the criteria trusted beforehand ("some rules",
"acceptable") for its validity:

> 1) validating a certificate * for a given time * against some rules
> which would desribe an acceptable certification *forest* to be used
> (a forest has several trees and thus several roots to be fully
> explicit).

Yes. However, for the sake of terminology (and, saving trees), the
data model you mention is not called forest but "network" -- in contrast
to a "hierarchical tree".  To summarize the difference, the network data
model can be regarded as an extended form of the hierarchic
data model – the principal distinction between the two being that
in a hierarchic structure, a child record has exactly one parent
whereas in a network structure, a child record can have any
number of parents (possibly even zero).

The other data model which could also be applied  is the relational
data model, which then would describe an acceptable *view* to
be used when authorizing a certificate within a trust metric.

Cheers,

Ed Gerck




Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA05683 for <[e-mail]>; Wed, 13 Oct 1999 07:41:49 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA15894; Wed, 13 Oct 1999 16:42:47 +0200
Message-ID: <[e-mail]>
Date: Wed, 13 Oct 1999 16:42:45 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: "Salz, Rich" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> 
> I share Stephen's concerns about PKIX getting involved in authorization; I
> think it's way too premature.

I share the same concern too. We should not address authorization.
The document is in fact adsressing too many aspects. From the list
of functionality only two items should be covered/supported: 

1) validating a certificate * for a given time * against some rules
which would desribe an acceptable certification *forest* to be used
(a forest has several trees and thus several roots to be fully
explicit).

2) giving back to the user the certification path (i.e. the
certificate identifiers - not necessarilly the certificates
themselves) that have been used * for that given time * for the
validation, including the relevant revocation (i.e. CRLs) or status
(i.e. OSCP responses) information.

This would be quite sufficient at the time being.

Denis

> There are many places where cross-certification is "outlawed" and path
> discovery is pretty darn simple.  I think that's justification enough
> to start work here.
>         /r$


Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA04846 for <[e-mail]>; Wed, 13 Oct 1999 07:17:14 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id BFD2715532; Wed, 13 Oct 1999 10:18:38 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 62AE87C051; Wed, 13 Oct 1999 10:18:38 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2232.9) id <4XVLFX52>; Wed, 13 Oct 1999 10:18:29 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Wed, 13 Oct 1999 10:18:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

I share Stephen's concerns about PKIX getting involved in authorization; I
think it's way too premature.

There are many places where cross-certification is "outlawed" and path
discovery is pretty darn simple.  I think that's justification enough
to start work here.
	/r$



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA04037 for <[e-mail]>; Wed, 13 Oct 1999 07:03:12 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhktk12523; Wed, 13 Oct 1999 14:04:55 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA13118; Wed, 13 Oct 99 10:03:06 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA00365; Wed, 13 Oct 1999 10:04:52 -0400
Date: Wed, 13 Oct 1999 10:04:52 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: End-Entity Certificate Policies
References: <[e-mail]> <001601bf156a$743350e0$21b80ccb@WSANDREW>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

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

 Andrew> CAs would never use the *same* policy OID as they surely they
 Andrew> would be issuing policies prefixed by their own unique
 Andrew> company's / CAs OID!

Not necessarily.  What if a CA adopted the Standard Terms and
Conditions created by the European Professional Association of CAs?
There are plenty of examples like that in current business practice. 

	paul


Received: from mail-int.cubis.de (maildt.cubis.de [212.185.174.4]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA02962; Wed, 13 Oct 1999 06:47:58 -0700 (PDT)
Received: from secunet.de (huehnlein.cubis.de [10.0.133.71]) by mail-int.cubis.de (8.9.3/8.9.3) with ESMTP id PAA24822; Wed, 13 Oct 1999 15:34:34 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Wed, 13 Oct 1999 15:31:01 +0100
From: Detlef =?iso-8859-1?Q?H=FChnlein?= <[e-mail]>
Organization: Secunet AG - The Trust Company
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en,de-DE
MIME-Version: 1.0
To: [e-mail]
Subject: CQRE'99 - Call for Participation
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.imc.org id GAB02966

Dear Listmembers! 

Sorry for crossposting. The Call for Participation below
might be of interest for you. To register, please visit
http://www.cqre.net . You might want to note that the 
early bird registration period already expires on Oct. 22, 
which is less than two weeks from now. 

I would be looking forward to seeing you at CQRE. 

Best regards

	Detlef Huehnlein
	

***************************************************************
                  Call for Participation 
            CQRE [Secure] Congress & Exhibition
        Duesseldorf, Germany, Nov. 30 - Dec. 2 1999
---------------------------------------------------------------
provides a new international forum covering most aspects of
information security with a special focus to the role of
information security in the context of rapidly evolving 
economic processes.
---------------------------------------------------------------
Part I covers stratecial issues of IT-Security while Part II
will discuss more technical issues, like 

- SmartCard Technology / Security
- Public Key Infrastructures
- Network Security
- Mobile Security
- Intrusion Detection
- Enterprise Security
- Security Design
- Electronic Payment
- Electronic Commerce
- Cryptography
- Espionage
- Interoperability
- Biometrics 
- Risk Management
- Signature Laws 
- Training / Awareness

for example.
----------------------------------------------------------------
                       CQRE-PROGRAM:
----------------------------------------------------------------
Part I - Strategical Aspects
Tuesday, November 30, 1999
----------------------------------------------------------------
09.30 Opening: Chairman Paul Arlman, Federation of European 
Stock Exchange 
09.45 Keynote Dr.Hagen Hultzsch, Deutsche Telekom AG
"A corporate group in transition - how Deutsche Telekom is 
preparing for the digital economy."
10.15 Keynote Jean-Paul Figer, Cap Gemini S.A
"Brave Digital World? The balance between chances and 
risks for the information society."
10:45 Coffee
11:15 Five parallel Workshops:
Workshop 1 - "Values & standards"   (Prof.Dr. Gertrud Höhler)
Workshop 2 - "Law & regulation"     (Klaus-Dieter Scheurle)  
Workshop 3 - "Strategy & success" 
Workshop 4 - "Role of technology"   (Karl-Heinz Streibich)
Workshop 5 - "Monitoring & control" (Piet van Reenen)
12.45 Lunch
14.15 Keynote Dr.Ulrich Schumacher, CEO Infineon
"Network Citizen - what does the networked citizen and 
consumer stand to gain and lose?"
15.15 Workshop results (Moderator Paul Arlman) 
15.45 Coffee
16.00 Summary / 10-point-programme 
17.00 Happy Hour
18.00 Platform debate (Moderator Klaus-Peter Siegloch, ZDF)
----------------------------------------------------------------
Part II - Technical Aspects:
Wednesday, December 1, 1999
----------------------------------------------------------------
09.00 R.Baumgart: Welcome 
09.15 B.Schneier: "Attack trees - a novel methodology 
        for risk management."
10.00 Refreshments 
10.15 Four parallel tracks:
I. Risk Management:
      D.Povey: "Developing Electronic Trust Policies 
        Using a Risk Management Model"
      J.Hopkinson: "Guidelines for the Management
        of IT-Security"
II. Security Design:
      L.Romano, A.Mazzeo and N.Mazzocca: "SECURE:
        a simulation tool for PKI design"
      D.Basin: "Lazy Infinite State Analysis 
        of Security Protocols"
III. Enterprise Security:
      P.Kunz: "The case for IT-Security"
      W.Wedl: "Integrated Enterprise Security - Examples 
        conducted in large European Enterprises"
      B.Esslinger: "The PKI development of Deutsche Bank"
IV. Tutorial:
      H.Handschuh: "Cryptographic SmartCards"
11.45 Lunch
13.15 S.Senda: "Electronic Cash in Japan"
14.00 M.Yung, Y.Tsiounis, M.Jakobsson, D.MRhaihi:
      "Panel: Electronic payments where do we go 
      from here?"
15.00 Four parallel tracks:
I. SmartCard Issues
      R.Kehr, J.Possega, H.Vogt: "PCA: Jini-based 
        Personal Card Assistant"
      M.Nyström, J.Brainard: "An X.509-Compatible 
        Syntax for Compact Certificates"
II. Applications
      D.Hühnlein, J.Merkle: "Secure and cost efficent
        electronic stamps"
      K.Sako: "Implementation of a Digital 
        Lottery Server on WWW"
III. PKI-experiences
      J.Lopez, A.Mana, J.J.Ortega: "CerteM: 
        Certification System Based on Electronic 
      Mail Service Structure"
        K.Schmeh: "A method for developing PKI models"
      J.Hughes: "The Realities of PKI Inter-Operability
IV. Tutorial
      S.Kent: "How many Certification Authorities 
        are Enough?"
16.45 J.J.Quisquater: "Attacks on SmartCards 
        and Countermeasures"
17.00 M.Kuhn: "How tamper-resistant are 
        todays SmartCards?"
18.15 L. Martini,M. Kuhn, J.J.Quisquater, Hamann: 
        "Secure SmartCards - Fact or Fiction"
19.00 Get-together with music (4 to the bar)
        and CQRE - Speakers corner - rump session
----------------------------------------------------------------
Part II - Technical Aspects:
Thursday, December 2, 1999
----------------------------------------------------------------
09.00 R.Baumgart : Good morning 
09.15 P.Landrock: Mobile Commerce
10.15 Four parallel tracks:
I. Mobile Security
      M.Borchering: "Mobile Security - an
        Overview of GSM, SAT and WAP"
      S.Pütz, R.Schmitz, B.Tiez: "Secure Transport of
        Authentication Data in Third Generation Mobile
        Phone Networks"
II. Cryptography
      J.P. Seifert, N.Howgrave: "Extending Wiener`s 
        attack in the Presence of many decrypting
        exponents"
      S.Micali, L.Reyzin: "Improving The Exact 
        Security of Fiat-Shamir Signature Schemes"

III. Network Security
      C.Yuen-yan: "On Privacy Issues of Internet 
        Access Services via Proxy Servers"
      Jorge Davila, Javier Lopez and Rene Peralta: 
        "VPN solutions in diverse layers of the 
         TCP/IP stack"
      B.Schneier, Mudge, D.Wagner: "Cryptanalysis of
        Microsofts PPTP Authentification Extensions
       (MS-CHAPv2)"
IV. Tutorial
      I.Winkler: "How to fight the inner enemy"
12.00 J.S. Coron: "On the security of RSA padding"
12.45 Lunch
14.15 Four parallel tracks:
I. PKI
      A.Young, M.Yung: "Auto-Recoverable 
       Auto-Certifiable Cryptosystems (a survey)"
II. Intrusion Detection
      D.Bulatovic, D.Velasevic: "A Distributed Intrusion 
       Detection System based on Bayesian Alarm
       Networks"
III. Espionage
      M.Fink: "Espionage - State of the Art and 
        Countermeasures"
      W.Haas: "Informational Self Defense"
IV.  Tutorial
      A.Philip: "Secure E-business"
15.00 S.Kent: "Security for Certification Authorities 
        - A system approach"
16.00 Four parallel tracks: 
I. Interoperability
      S.Gupta, J.Mulvenna, S.Ganta, L.Keys, D.Walters: 
        "Interopreability Characteristics of S/MIME
         Products"
      M.Rubia, J.C.Cruellas, M.Medina: "The DEDICA 
         Project: The Solution to the Interoperability 
         Problems between the X.509 and EDIFACT Public 
         Key Infrastructures"
II. Biometrics 
      H.Arendt: "Biometrics - State of the Art"
      A.P.Gonzales-Marcos, C.Sanchez-Avila,
        R.Sanchez-Reillo: "Multiresolution Analysis and
        Geometric Measure for Biometric Identification"
III. Signature Laws 
      Workshop - Leader, K.Keus: "German Signature Act -
        Expiriences made for Europe?"
IV. Tutorial
      J.Massey: "Cryptography at a glance"
17.45 S.Baker, R.Schlechter, T.Peters, T.Barassi:
      "Panel: Perspectives for a global signature law"
18.30 R.Baumgart: Closing Remarks


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA28499 for <[e-mail]>; Wed, 13 Oct 1999 05:31:14 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20752; Wed, 13 Oct 1999 08:32:41 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Diffie-Hellman Proof-of-Possession Algorithms to Proposed Standard
Reply-to: [e-mail]
Date: Wed, 13 Oct 1999 08:32:41 -0400
Sender: [e-mail]

The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider Diffie-Hellman Proof-of-Possession
Algorithms <draft-ietf-pkix-dhpop-02.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by October 27, 1999.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-02.txt




Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id EAA24162 for <[e-mail]>; Wed, 13 Oct 1999 04:00:57 -0700 (PDT)
Received: from WSANDREW (d33-1.cpe.Melbourne.aone.net.au [203.12.184.33]) by springfield.SIMPSONS with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 4LK3J84S; Wed, 13 Oct 1999 21:01:53 +1000
Message-ID: <001601bf156a$743350e0$21b80ccb@WSANDREW>
From: "Andrew Probert" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
References: <[e-mail]>
Subject: Re: End-Entity Certificate Policies
Date: Wed, 13 Oct 1999 21:02:31 +1000
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0012_01BF15BE.4401C740"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01BF15BE.4401C740
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

CAs would never use the *same* policy OID as they surely they would be
issuing policies prefixed by their own unique company's / CAs OID!

That's why cross-certification and policy-mapping was invented.

I think the process breaks down if you take the shared policy OID approach.

Regards.

----- Original Message -----
From: Russ Housley <[e-mail]>
To: <[e-mail]>
Sent: Friday, September 10, 1999 4:00 AM
Subject: RE: End-Entity Certificate Policies


> I want to send a quick message to summarize the impact that this thread
has
> had on my thinking.  This thoughts have not been coordinated with the
other
> RFC 2459 authors.
>
> First, I have been convinced that there are times when it is appropriate
to
> include more than one certificate policy OID in an end
> entity-certificate.  However, it is clear to me that some policies should
> not be combined in one certificate.  I guess that there are many errors
> that a CA could make, and that this is just one more.  Can anyone suggest
a
> subjective rule for the types of policies that might appear in one
> end-entity certificate?  If not, how about a subjective rule for the types
> of policies that should not appear in one end-entity certificate?
>
> Second, I remain concerned about the use of qualifier with certificate
> policies in CA certificates.
>
> The certificate policy qualifiers do not impact the certificate path
> validation algorithm.  Rather, the certificate policy qualifiers are
> provided as an output of the algorithm to the certificate user (a.k.a.
> relying party) to help determine whether or not the end-entity certificate
> is appropriate for the task at hand.
>
> While the X.509 path validation algorithm does not prohibit an
> implementation from returning information that tells which certificate
> provided particular qualifiers, the algorithm does not require that this
> information be provided.  Therefore, we must assume that this information
> is not available to the certificate user.
>
> I still think that it is important that the set of certificate policy
> qualifiers not include contradictions.
>
> I belive that it is possible that two CAs can support the same certificate
> policy using different CPSs.  Thus, certificates issued by the two CAs
> would have the same certificate policy OID, but they would include
> different values for the CPS pointer qualifier.  If a path includes
> certificates from both of these CAs, the output of the certificate path
> validation algorithm would include the common certificate policy OID and
> two different CPS pointer qualifiers.
>
> Since the certificate validation algorithm does not use certificate policy
> qualifiers, how do certificate policy qualifiers in CA certificates help
> the certificate user?
>
> Russ
>

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFbzCCAo4w
ggF2oAMCAQICBAX14XkwDQYJKoZIhvcNAQEEBQAwLDELMAkGA1UEBhMCYXUxHTAbBgNVBAoTFFNl
Y3VyZU5ldCBDQSBDbGFzcyBCMCYXETk5MTAwNTAwMDAwMCsxMDAwFxEwMDEwMDUyMzU5NTkrMTAw
MDBiMQswCQYDVQQGEwJhdTEOMAwGA1UEChMFUm90ZWsxFzAVBgNVBAMTDkFuZHJldyBQcm9iZXJ0
MSowKAYJKoZIhvcNAQkBExthbmRyZXcucHJvYmVydEByb3Rlay5jb20uYXUwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBALREU1Bf5/saJ9glyr3lxGwmK5Mu/NyFKS18k3PFommdfGpH1Y+hPGGl
mg+JXsCcJAEpGsBUE6mNnu2nCOCfRpg9gt4yQC0rih1kDw1y258LzAVk19LIIPd3np+/twn37AiN
BX2sulstnR8PilOujGO/yAr67rL6LXHqFo5gM0GbAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBABDA
UkvIKvOYT1go2Lo4duhoHLuVd+/iC4u9V9594+aC5A1DyxM4OWJ5rsW2z5GcduTtY3ZBlQzl6fvu
1D7p2Ns8b6dgUvL0JJlOTQJb1gnQO81VE1V+/ydsFxNN7VBzTUhHDEm9VdTgFyKM4wKP8QAcmOro
9RPS1L2wXBmy11GakMEl3AnrGEseLMecNXGd1b8psxVqzu5I75ONFb4798gQcTMuSwTcRJF4ZcwV
yyn0+06rKDtHyb1oQGO6pffy/rHPkQeClAKcLRa6KtK4wF9QIYtydMEQ+UNOSw6hU/mUzGF5+ays
/TPkJEHm09FAGZ+4CZCTWfcW+6NqULMpgHwwggLZMIIBwaADAgEAAgEAMA0GCSqGSIb3DQEBBAUA
MCwxCzAJBgNVBAYTAmF1MR0wGwYDVQQKExRTZWN1cmVOZXQgQ0EgQ2xhc3MgQjAmFxE5OTA2MzAw
MDAwMDArMTAwMBcRMDkxMDE1MjM1OTAwKzEwMDAwLDELMAkGA1UEBhMCYXUxHTAbBgNVBAoTFFNl
Y3VyZU5ldCBDQSBDbGFzcyBCMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApmPZxhVa
dudGZcc0kfl73Va7+JY1LinKp30KHvcxUuhayNPPOQFOW/AfsbhK0rNHQ2Y/AUBOMEnhD/3rEmN4
zPYWYhj1b2n9fm4zdiGjwIgP6uYl/KmXzBhyxzG2C5vNwsV4YWNFrDSmJ3hoxL1SaM6ETdIkpShs
gObK5s/mmp5QeM7zNtKjQ1ocBq/LIO7QLMREGJBssZFkZbm3hYNLqJGZxeCc97hQ19OwT5rtY/tN
9NQoJDqAW3uTjMUFhK87hv6BMce2nV8a6pB7sEZesghSAFcNVVKDeJVK/WiPntlQtktT+vKFApVO
OPWDp5bUMT8/p8o3U9zFL20adKbMvwIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQBLRqYiWunRpeQQ
j0xTYONNVIbeuhyqKlo2CB1KC0mh76q9vCYypP9zQDAkD+yrEdXLr8RLm+ceHMNQhbpPCCsvPxQj
qvaDmYa+RngRFSua5KO/femNfvln3z5/5q1G52BlZ1/lgPMsu1Nnc2/grpcSbUkYHGhMsyzzWsE1
Mfbs6T6ny81UUIdYRcAU1Ui28yiOOhgp6JqZ8eD1o8sItH14JRPhNM5om9q3IiEbNFLL71Pi89cM
YtqxRUFFuJdYLAhiRSMOWZU1Gg5Ex1FwTj8ErSbCHe0PSC1VEx1xoqcOsy+Hb7Du5cc2iyxxUUCH
Gs5WFDkp7yUKgAoZnfVWn92KMYIBlzCCAZMCAQEwNDAsMQswCQYDVQQGEwJhdTEdMBsGA1UEChMU
U2VjdXJlTmV0IENBIENsYXNzIEICBAX14XkwCQYFKw4DAhoFAKCBujAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw05OTEwMTMyMTAyMzFaMCMGCSqGSIb3DQEJBDEWBBT1
/1aLi0ZVN0fgG9mMvmFgnQsZazBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCHTAN
BgkqhkiG9w0BAQEFAASBgArbPWEwFxIuVGUPn/yFcpbG7z9i2DlBQx85OjIDkBPK0sz/feuSrXR/
kinVghFSlFTDdiq0m5D5sKCGwk0qm8WyFgBJZ3BOSGiu5YfcwkjrqQGmghfwmkeQBzyy5Np6A5aU
8sBbrmJjXa9R0GlqZcjiyDagI+8++NWQhvWAjla0AAAAAAAA

------=_NextPart_000_0012_01BF15BE.4401C740--



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA23949 for <[e-mail]>; Wed, 13 Oct 1999 03:52:31 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17253; Wed, 13 Oct 1999 06:53:59 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-laap-00.txt
Date: Wed, 13 Oct 1999 06:53:58 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Limited AttributeCertificate Acquisition Protocol
	Author(s)	: S. Farrell, D. Chadwick
	Filename	: draft-ietf-pkix-laap-00.txt
	Pages		: 11
	Date		: 12-Oct-99
	
The PKIX working group is profiling the use of X.509 attribute
certificates. This document specifies a deliberately limited
protocol for requesting an attribute certificate from a server. It
is intended to be complementary to the use of LDAP for AC retrieval,
covering those cases where use of an LDAP server is not suitable due
to the type of authorization model being employed. For many other
cases, the use of LDAP is preferred.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-laap-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA22901 for <[e-mail]>; Wed, 13 Oct 1999 03:23:29 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id MAA16852; Wed, 13 Oct 1999 12:24:37 +0200
Message-ID: <[e-mail]>
Date: Wed, 13 Oct 1999 12:24:36 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: "Manger, James" <[e-mail]>
CC: [e-mail]
Subject: Re: Timestamp: 03: TSP version 3
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

James,

It has been long since you posted these comments. :-( Since I am now
in the process of revising the document and publish a new version
before the dead line, here are my answers:

 
> > Comments on version 3 of the timestamp draft:
> >
> > 2.2
> > Highlights from the 1st sentence: ".. requesting .. requests .. request
> > ..Req ..".  :-)

Any better proposal ? :-) 


> > 2.4.1
> > Please use integer 1 for version 1 - it avoids confusion.
> >       version INTEGER {v1(1)},

OK. 

> > 4) ..TSA offers no guarantee about the strength of the hash functions..
> > But the paragraph after the MessageImprint definition still says 'It is up
> > to the TSA to decide whether or not the given has algorithm is
> > "sufficient"'.  

Ooops ! I forgot to delete that one. Good catch.

> > Rename the 'messageImprint' field as 'opaque' to make it
> > obvious that the TSA is making no claim about the value, other than its
> > existence, even though it is signing it.
> >       opaque  [2] MessageImprint,
> > Why is it optional?

I do not think renaming it is necessary. Since the field is now
mandatory, I will change SHOULD by SHALL in the text.

> > 2.4.2
> > Why repeat selected definitions from CMS (SignedData etc.)?  You still
> > have to read CMS because not all definitions are repeated (e.g.
> > CMSVersion).  Don't bother repeating any - it just opens the possibility
> > of incompatibility or confusion.

It helps the reading anyway.


> > Time is the whole reason for the timestamp.  Call the field 'time', not
> > 'genTime'; put it at the top of the token (after the version) and don't
> > bury it in a TSTTime construct (make 'accuracy' the 3rd field in TSTInfo).
> > Now the major items are directly visible in the definition of the major
> > type.

I will change the ordering to place all mandatory fields first
followed by optional fields and will suppress the TSTTime construct
as you suggest.

> > Don't restrict the 'seconds' accuracy field to 1..59.  This is an
> > unnecessary & arbitrary limit.  My clock may only be synchronized to UTC
> > to +/-2 minutes (I may wish to use a very conservative estimate).  You
> > don't, of course, need a new 'minutes' choice in the Accuracy type, just
> > allow values like 120 seconds.

OK.

> > Show the syntax as: YYYYMMDDhhmmss[.s...]Z
> > This implies all the DER-encoding rules it can (keep the sentence about
> > omitting trailing 0's in the fractional second component & the decimal
> > point if the fractional seconds is 0).
> > The syntax in the current draft does not show the full options of the
> > GeneralizedTime syntax (e.g. does not show decimal comma option), nor does
> > it imply all the DER-encoding restrictions (e.g. terminate with Z).
> >
> > 3.2
> > time-to-check-back
> > Surely a relative time would be far more appropriate here, i.e. number of
> > seconds from now until you should poll again.

This is part of an issue that I am currently discussing with the
co-editors.

> > 3.4
> > How about an easier HTTP request:
> >
> > http://aaa.bbb.com/cgi-bin/timestamp?alg=sha1&hash=A9993E364706816ABA3E257
> > 17850C26C9CD0D89D

 ... but this would mean that we are no more transport independent.
:-(

> >
> > 6.
> > CMS has been published as RFC 2630.

OK.

> > A.
> > Providing a syntax to hold a timestamp & its associated data is a good
> > idea, but there is no need for this to have extra security - the timestamp
> > is already signed & contains a hash of the data!

I personally agree.

> > Given that a major identified use of timestamps is to timestamp a digital
> > signature it is likely that a CMS SignedData structure is already being
> > used.  A sensible place to store a timestamp is in this existing structure
> > - as an unauthenticatedAttribute.
> >
> > A timestamp could apply to the content being signed (e.g. PDF doc), the
> > signature on the content or the signature plus the certificates & CRLs.

This is an interesting proposal. In order to keep things simple I
would propose to limit the case to the signature itself only.
Including certificates and CRLs does not always make sense since the
certificates and CRLs that MAY be present in a CMS structure do not
necessarilly reflect a valid certification path. As advertised on
this mailing list, an ETSI draft document on a foramt of an
*electronic* signature is adding two unsigned attributes which may
contain a certification path and revocation information for that
path and it makes sense to time stamp all that information together.
However this would mean defining additional unsigned attributes
which are clearly out of the scope of this document. Hence the
reason to support only one of your proposals. 


> > Perhaps three attributes are required:
> >       timestampedContent      ATTRIBUTE ::= { WITH SYNTAX ContentInfo  ID
> > id-at-??? 1 }
> >               -- msgImprint is the same value as the MessageDigest
> > auth.att. value
> >       timestampedSignature    ATTRIBUTE ::= { WITH SYNTAX ContentInfo  ID
> > id-at-??? 2 }
> >               -- msgImprint is the hash of the encryptedDigest field
> > (DER-encoded)
> >       timestampedCertSig      ATTRIBUTE ::= { WITH SYNTAX ContentInfo  ID
> > id-at-??? 2 }
> >               -- msgImprint is the hash of the concatenation of the
> > certificates, crls &
> >               -- encryptedDigest fields (all DER-encoded)
> >
> > Alternatively, or in addition, define how the data can be stored in the
> > timestamp itself.
> >       "Data can be stored with its associated timestamp as the contents of
> > an octet string held as the value of a attribute of type 'data' in the
> > unauthenticatedAttributes field of the timestamp."

Before I read your proposal I had never thought things this way !
This is quite original and would be a way to keep things together. I
see it as an alternative to the method described in the appendix A.
I would however like to hear some other opinions from the list on
that topic. 

> >
> > x.
> > The I-D ACTION e-mail had an extra sentence at the end of the Annex,
> > compared to the actual draft.
> >       "..(TDA) .. proves in addition that a datum existed before a
> > particular unpredictable event."
> > This should say "after", not "before".

This is now gone.

Thanks for your very valuable comments.

Denis


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id CAA18108 for <[e-mail]>; Wed, 13 Oct 1999 02:52:29 -0700 (PDT)
Received: by balinese.baltimore.ie; id KAA25817; Wed, 13 Oct 1999 10:54:24 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma025743; Wed, 13 Oct 99 10:53:32 +0100
Received: from baltimore.ie ([192.168.20.104]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA08582; Wed, 13 Oct 1999 10:53:21 +0100
Message-ID: <[e-mail]>
Date: Wed, 13 Oct 1999 10:54:20 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Phillip M Hallam-Baker <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, xme <[e-mail]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP
References: <005101bf14e0$55191440$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phill,

When SCVP was originally proposed, I voiced a number of 
questions and objections. I guess its time to repeat them, 
since I don't believe they were addressed at the time. 
Now that OCSP-X has entered the picture, I also have 
a few new ones to do with authorization.

>From my reading of the situation, the only potential 
benefits of these protocols are:

	- to allow centralisation of PKI policy 
          enforcement, and,
	- to remove certificate path discovery from 
	  the client.

(NB: I said "discovery", a.k.a. path constuction, 
*not* path validation, about which I remain to
be convinced, but see later.)

1) For centralisation of policy, I'd assert that the 
PKIX WG is *not* the place where this should be considered.
We simply don't have sufficient input on the range
of applications which give rise to requirements to
do a good job. 

For example, the policy and AAA WGs are both examining
many of these issues, in broader contexts, and with
more familiarity with the actual issues which arise. 
I do believe that some of these WGs outputs will show
up a need for PKIX to tackle some issues, but we're
not yet at that point. To be concrete, I've been
doing some work on authorization in the AAA WG, and
there are many environments in which the authorization
approach proposed with OCSP-X just won't work!
(E.g. mobileip or remote access when there are brokers
involved. There'll be an updated authorization
requirements draft from the AAA WG in the next few days
which should clarify the point.) It may be that we
can make some progress on centralising PKI policies,
but if the clients still have to get their other
equally important policy some other way, then I'm 
not sure we're helping them very much.

2) Certificate path discovery, OTOH, is an issue which
PKIX should and can address. Personally, I'm open as
to whether this uses a new protocol, an OCSP extension
or a CMP or CMC extension, or all whether we provide
all of the above options.

2) One of the major difficulties with SCVP and OCSP-X that
I do see is with the whole idea of a server deciding 
which paths are trustworthy.I think the onus is on 
those proposing this functionality to answer, in 
detail:

	What are the *concrete* applications or protocols
	which need this functionality today?
	For each application:
		- how will SCVP/OCSP-X work?
		- what RFCs will need to be changed?
		- what deployed base will need to be
		changed or extended?
		- how will the switch from client 
		processing to server processing
		occur?
		- what *specific* benefit does SCVP/OCSP-X
		offer?

I'd be happier with all of this if someone could
convincingly show how an an S/MIME, IPSec, or TLS 
implementation would be improved. They need so
much other ASN.1 & crypto code that the savings
are very unclear.

So, in conclusion I think PKIX should:

- progress with server-side path construction
- think hard about policy and authorization, after
  taking a look at what other WGs need and 
  what they're doing
- provide a real justification for server-side
  path validation with concrete examples as 
  requested above.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from ns.cmbchina.com ([202.96.161.112]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id VAA01026 for <[e-mail]>; Tue, 12 Oct 1999 21:03:19 -0700 (PDT)
Received: from cmbchina.com ([10.1.4.27]) by ns.cmbchina.com (Netscape Messaging Server 3.01)  with ESMTP id AAA6762 for <[e-mail]>; Wed, 13 Oct 1999 12:05:21 -0800
Message-ID: <[e-mail]>
Date: Wed, 13 Oct 1999 12:05:11 +0800
From: "Xiong Shao Jun" <[e-mail]>
Organization: China Merchants Bank
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: questions on rfc2587
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi, there. I'm currently working on a PKIX project, and I have some
questions about
LDAP v2 schema.
1) If a user have more than one certificates from one or more CA, how to
represent
    it in a pkiUser object class?
2) If a subject has a NULL DN, how to represent it?

Best regards,
Xiong Shaojun
China Merchants Bank



Received: from eagle.rsa.com (eagle.rsa.com [192.80.211.35]) by mail.imc.org (8.9.3/8.9.3) with SMTP id QAA12262 for <[e-mail]>; Tue, 12 Oct 1999 16:48:31 -0700 (PDT)
Received: from exrsa01.rsa.com by eagle.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Oct 1999 23:50:28 UT
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2448.0) id <THR92RJW>; Tue, 12 Oct 1999 16:50:26 -0700
Message-ID: <[e-mail]>
From: "Kingdon, Kevin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: OCSP-X  Internet Draft: Extensions to OCSP
Date: Tue, 12 Oct 1999 16:50:17 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

A few comments and questions about the OCSP-X draft (mostly about the
ASN.1):

Why use EXPLICIT context tagging for the SingleExtendedStatus CHOICE?
Wouldn't IMPLICIT tagging produce a more efficient encoding without
increased complexity for "hand-written" encoders?

What are the semantics implied by the SEQUENCE OF SEQUENCE { OBJECT
IDENTIFIER } definition of Rules? What purpose is served by wrapping the
Rule oid in a sequence?

I believe the Evaluate type would be better defined as a BIT STRING of named
bits. The current structure should at least define the SEQUENCE elements as
OPTIONAL.

The AuthorizationMode type would also be better defined as a BIT STRING of
named bits. If defined as a SEQUENCE, the elements should be OPTIONAL and
use IMPLICIT tagging.

The AuthorizationStatus type is not completely defined. I believe it should
be a CHOICE of IMPLICIT-ly tagged NULLs.

It would help me to understand how OCSP-X fits into OCSP if some example
PDUs were included. I would suggest using the ASN.1 value notation for these
examples.

Kevin W. Kingdon
RSA Security, Inc.

		-----Original Message-----
		From:	Phillip M Hallam-Baker [mailto:[e-mail]]
		Sent:	Tuesday, October 12, 1999 11:34 AM
		To:	'[e-mail]'
		Subject:	FW: OCSP-X  Internet Draft: Extensions to
OCSP

		 << File: Certificate Extensions to OCSP III.txt >> All,

			Attached is an Internet Draft written by myself,
based on comments
		by Mike Myers, recent proposals to the list by Ambarish
Malpani, conference
		submissions from Barbara Fox & Brian LaMachia, and comments
thereto on the
		list (for a fuller list please see the draft, if anyone
thinks they have
		been
		forgotten please email me).

			At the time OCSP was first introduced it was agreed
that the protocol
		could be a vehicle to support much more than certificate
revocation status
		checking. It was also the consensus that the draft should be
extreemly
		narrowly focused in order to make progress. For this reason
extensions such
		as trust path processing, time stamping and such were tabled
for later
		discussion. It is now 'later' and time to have that
discussion.

			The draft addresses two shortcommings of SCVP.
First, as discussed in
		Oslo all the functions of SCVP may be addressed in the OCSP
syntax and
		there is no need to duplicate all the work already done on
OCSWP. Second,
		SCVP addresses only trust path processing. This only
addresses half of the
		issue that an ISV with a product to be PKI enabled must
address, if a client
		is to delegate trust processing for authentication then it
might as well
		delegate authorization as well.

			My belief that this is a natural functionality set
is confirmed by
		the appearence of several commercial products offering
precisely these
		functions.

			The approach I have taken in OCSP-X is substantially
different in
		approach however. In the first place the transfer protocol
is OCSP/HTTP
		rather than LDAP, in the second URIs are used to identify
resources.

			The reason for choosing OCSP/HTTP over LDAP is that
this is a
		machine/machine interaction in which both sides know
a-priori the exact
		reference terms to be employed. The value add of LDAP over
HTTP is a
		resource discovery protocol which in this case is unneeded.
By avoiding
		the LDAP data model the issue of schema conflicts is
avoided. I believe
		that convergence on a common specification will be
considerably easier
		using OCSP/HTTP as a technology base than attempting to
agree on a
		common directory schema.

			Additionally the protocol proposal made here is a
'thin client -
		fat server' approach rather than the 'fat client - thin
server' approach
		directories are designed to support.


			The use of URIs as names for authenticatable
resources takes some
		explanation and for this reason an appendix provides some
worked examples.
		I believe it may be prudent to separate these examples into
a second,
		non-authoritative draft at a later date to avoid the risk
that conventions
		used in the examples be assumed to be dependable parts of
the standard.

			Essentially this protocol employs URIs as names in
that it uses
		the URI to refer to a resource without actually retrieving
it. This was
		the original intention of URNs.

					Phill

		Phillip Hallam-Baker
		Principal Consultant, VeriSign Inc.
		[phone] x227
		[e-mail]


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA11807 for <[e-mail]>; Tue, 12 Oct 1999 16:18:12 -0700 (PDT)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FJIJHJ00.RYN for <[e-mail]>; Tue, 12 Oct 1999 23:20:07 +0000 
Received: from nma.com ([209.21.28.72]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.04) with ESMTP id FJIIJW00.CA2; Tue, 12 Oct 1999 22:59:56 +0000 
Message-ID: <[e-mail]>
Date: Tue, 12 Oct 1999 16:20:23 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Phillip M Hallam-Baker <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Sentient applications, was Re: FW: OCSP-X  Internet Draft: Extensions to  OCSP
References: <005101bf14e0$55191440$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phillip M Hallam-Baker wrote:

> All,
>
>         Attached is an Internet Draft written by myself, based on comments
> by Mike Myers, recent proposals to the list by Ambarish Malpani, conference
> submissions from Barbara Fox & Brian LaMachia, and comments thereto on the
> list (for a fuller list please see the draft, if anyone thinks they have
> been forgotten please email me).

Phill:

The draft begins:

 For an application to make an informed decision as to whether it trusts a
 digital certificate the application must have knowledge of the certificate
 itself,

where the "humanization" of applications extends to the entire text. To talk
about "informed decision", "have knowledge" and so on is not only a style
slip but IMO also a dangerous overslight inducer. For example, rephrasing the
above for applications that are not sentient would produce:

 For an application to decide whether a digital certificate is trusted, the
 application must [be programmed with a trust metric, defined here to
 include, exclusively,] trust on the certificate itself,

where one should note not only the passive role of the application as
an evaluator of trust (actually, a proxy for the end user) but also the now
clear input that must be provided to the application: the trust metric.
Which was not mentioned in  the original section and which is still not
specified simply by specifying its components (the trust points).

Besides, I encounter the words "trust management".  Of course, we are all
familiar with the words "trust", "trusted system" and "'trusted third party".

However, it is IMO unfortunate to call "trust management" what actually
is "decision management" or, at most, "authorization management".

First, because if "trust management" would exist then it would imply
managing what you do not control. So, "trust management" is  an
oxymoron and one which leads to a series of unrelated assumptions
regarding the usefullness of that "management" .

Second, because trust is not boolean -- while the RFC constructs are
entirely boolean, yes or no.

Third, the fact that people introduce soundbites like "trust management"
instead of using clear words like "authorization management", does not
mean that any relevant conclusions can be drawn from the misuse
of terms like "trust" in the soundbite.

In other words, if you can successfully "manage" something, there is
nothing left to "trust" about it. That is, "trust" is qualified reliance
upon a "value" that cannot be directly observed or controlled at the
moment a decision is to be made that would depend upon that value
-- and which does *not* depend upon you at all, so there is nothing
you can "manage" about it.  Calling it "trust management" may be
reassuring, that we have everything under control, but such is not
true otherwise there would no need to trust -- you would control it.

However, and in a positive note, since a decision is *always* boolean,
decision management is a boolean problem amenable to the RFC. Even
though the whole process of authorization is not represented in your
RFC (for example, I miss the issues of delegation), one could still also
use it for authorization management of certificate validity in a restricted
(and, not sentient) sense.

Thus, my suggestion is that the trust points as well as the trust metric
used in the RFC must be made clear, and not "humanized", so that they
can be rendered as a logical process amenable to a protocol. Perhaps,
other options for trust metric could also be made available, including
the question of transtitive trust (depth of certificate chains acceptable),
fresheness of each component, reliance of each component in a risk model
as defined by CPS, insurance policies, etc.  If this is too complex, then the
RFC should mention what it is implictly assuming.

Cheers,

Ed Gerck




Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA09120 for <[e-mail]>; Tue, 12 Oct 1999 12:49:02 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id MAA04363; Tue, 12 Oct 1999 12:48:38 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA03521; Tue, 12 Oct 1999 12:50:25 -0700 (PDT)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SF5SN9PZ; Tue, 12 Oct 1999 12:50:26 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Peter Williams" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: OCSP-X  Internet Draft: Extensions to OCSP
Date: Tue, 12 Oct 1999 15:51:51 -0400
Message-ID: <006301bf14eb$39fe4b20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>

> Phil,
> 
> Was OCSP (and any variants) not intended to be transport
> independent? OCSP should be available as value-add
> on CMP-based products soon, for example.

I believe you have misunderstood me. OCSP and OCSP-X are both
transport independent. CMP would remain an appropriate transport 
layer.

What I was attempting to explain (perhaps poorly) was the 
reason for using OCSP as a base technology as opposed to LDAP
which I anticipated might be the subject of extensive 
protestations if not arguments.

The ability to run over CMP (or for that matter SMTP!) would be 
one further reason to adopt the OCSP approach.

> This would
> be inappropriate in certain quite typical military
> contexts whose infrastructure requires
> separation of these two management needs,
> and where LOCAL authorization control is a
> requirement. See SDN 801 and later MISSI work...
> as reported by Ford and others )

Quite so, the argument I was trying to make was that the 
specification having addressed one aspect of the should 
really go the whole way and address both. This is not the
same thing as saying that applications must USE the features,
just that they should be there.

The degree of authorization delgation must as you point
out be left to the specific configuration. I very much
agree on the issue of LOCAL authorization information
management as the examples in the draft discuss at length.


		Phill


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA08643 for <[e-mail]>; Tue, 12 Oct 1999 12:23:41 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id MAA03744; Tue, 12 Oct 1999 12:25:36 -0700 (PDT)
Received: from rsalaptop ([192.168.3.229]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id MAA07648; Tue, 12 Oct 1999 12:25:06 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Phillip M Hallam-Baker" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: OCSP-X  Internet Draft: Extensions to OCSP
Date: Tue, 12 Oct 1999 12:28:24 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <005101bf14e0$55191440$[e-mail]>

Phil,

Was OCSP (and any variants) not intended to be transport
independent? OCSP should be available as value-add
on CMP-based products soon, for example.

Why do you propose that OCSP, when extended to address
additional PKI-related semantics, have this
transport independence removed?

This web-centric change of direction seems at odds
with what is an otherwise highly articulate argument.

(Though I praise your argument, above, this does
not mean I agree with all its design
assumptions or your beliefs concerning seemingly
MANDATORY co-location of authentication and
authorization providers. This would
be inappropriate in certain quite typical military
contexts whose infrastructure requires
separation of these two management needs,
and where LOCAL authorization control is a
requirement. See SDN 801 and later MISSI work...
as reported by Ford and others )




> -----Original Message-----
> From: Phillip M Hallam-Baker [mailto:[e-mail]]
> Sent: Tuesday, October 12, 1999 11:34 AM
> To: '[e-mail]'
> Subject: FW: OCSP-X Internet Draft: Extensions to OCSP
>
>
> All,
>
> 	Attached is an Internet Draft written by myself, based on comments
> by Mike Myers, recent proposals to the list by Ambarish Malpani,
> conference
> submissions from Barbara Fox & Brian LaMachia, and comments thereto on the
> list (for a fuller list please see the draft, if anyone thinks they have
> been
> forgotten please email me).
>
> 	At the time OCSP was first introduced it was agreed that
> the protocol
> could be a vehicle to support much more than certificate revocation status
> checking. It was also the consensus that the draft should be extreemly
> narrowly focused in order to make progress. For this reason
> extensions such
> as trust path processing, time stamping and such were tabled for later
> discussion. It is now 'later' and time to have that discussion.
>
> 	The draft addresses two shortcommings of SCVP. First, as
> discussed in
> Oslo all the functions of SCVP may be addressed in the OCSP syntax and
> there is no need to duplicate all the work already done on OCSWP. Second,
> SCVP addresses only trust path processing. This only addresses half of the
> issue that an ISV with a product to be PKI enabled must address,
> if a client
> is to delegate trust processing for authentication then it might as well
> delegate authorization as well.
>
> 	My belief that this is a natural functionality set is confirmed by
> the appearence of several commercial products offering precisely these
> functions.
>
> 	The approach I have taken in OCSP-X is substantially different in
> approach however. In the first place the transfer protocol is OCSP/HTTP
> rather than LDAP, in the second URIs are used to identify resources.
>
> 	The reason for choosing OCSP/HTTP over LDAP is that this is a
> machine/machine interaction in which both sides know a-priori the exact
> reference terms to be employed. The value add of LDAP over HTTP is a
> resource discovery protocol which in this case is unneeded. By avoiding
> the LDAP data model the issue of schema conflicts is avoided. I believe
> that convergence on a common specification will be considerably easier
> using OCSP/HTTP as a technology base than attempting to agree on a
> common directory schema.
>
> 	Additionally the protocol proposal made here is a 'thin client -
> fat server' approach rather than the 'fat client - thin server' approach
> directories are designed to support.
>
>
> 	The use of URIs as names for authenticatable resources takes some
> explanation and for this reason an appendix provides some worked examples.
> I believe it may be prudent to separate these examples into a second,
> non-authoritative draft at a later date to avoid the risk that conventions
> used in the examples be assumed to be dependable parts of the standard.
>
> 	Essentially this protocol employs URIs as names in that it uses
> the URI to refer to a resource without actually retrieving it. This was
> the original intention of URNs.
>
> 			Phill
>
> Phillip Hallam-Baker
> Principal Consultant, VeriSign Inc.
> [phone] x227
> [e-mail]
>



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA07635 for <[e-mail]>; Tue, 12 Oct 1999 11:31:11 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id LAA00216; Tue, 12 Oct 1999 11:30:48 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA00261; Tue, 12 Oct 1999 11:32:33 -0700 (PDT)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SF5SN8XZ; Tue, 12 Oct 1999 11:32:30 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Tue, 12 Oct 1999 14:33:52 -0400
Message-ID: <005101bf14e0$55191440$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0052_01BF14BE.CE077440"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

This is a multi-part message in MIME format.

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

All,

	Attached is an Internet Draft written by myself, based on comments
by Mike Myers, recent proposals to the list by Ambarish Malpani, conference
submissions from Barbara Fox & Brian LaMachia, and comments thereto on the
list (for a fuller list please see the draft, if anyone thinks they have
been
forgotten please email me).

	At the time OCSP was first introduced it was agreed that the protocol
could be a vehicle to support much more than certificate revocation status
checking. It was also the consensus that the draft should be extreemly
narrowly focused in order to make progress. For this reason extensions such
as trust path processing, time stamping and such were tabled for later
discussion. It is now 'later' and time to have that discussion.

	The draft addresses two shortcommings of SCVP. First, as discussed in
Oslo all the functions of SCVP may be addressed in the OCSP syntax and
there is no need to duplicate all the work already done on OCSWP. Second,
SCVP addresses only trust path processing. This only addresses half of the
issue that an ISV with a product to be PKI enabled must address, if a client
is to delegate trust processing for authentication then it might as well
delegate authorization as well.

	My belief that this is a natural functionality set is confirmed by
the appearence of several commercial products offering precisely these
functions.

	The approach I have taken in OCSP-X is substantially different in
approach however. In the first place the transfer protocol is OCSP/HTTP
rather than LDAP, in the second URIs are used to identify resources.

	The reason for choosing OCSP/HTTP over LDAP is that this is a
machine/machine interaction in which both sides know a-priori the exact
reference terms to be employed. The value add of LDAP over HTTP is a
resource discovery protocol which in this case is unneeded. By avoiding
the LDAP data model the issue of schema conflicts is avoided. I believe
that convergence on a common specification will be considerably easier
using OCSP/HTTP as a technology base than attempting to agree on a
common directory schema.

	Additionally the protocol proposal made here is a 'thin client -
fat server' approach rather than the 'fat client - thin server' approach
directories are designed to support.


	The use of URIs as names for authenticatable resources takes some
explanation and for this reason an appendix provides some worked examples.
I believe it may be prudent to separate these examples into a second,
non-authoritative draft at a later date to avoid the risk that conventions
used in the examples be assumed to be dependable parts of the standard.

	Essentially this protocol employs URIs as names in that it uses
the URI to refer to a resource without actually retrieving it. This was
the original intention of URNs.

			Phill

Phillip Hallam-Baker
Principal Consultant, VeriSign Inc.
[phone] x227
[e-mail]

------=_NextPart_000_0052_01BF14BE.CE077440
Content-Type: text/plain;
	name="Certificate Extensions to OCSP III.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Certificate Extensions to OCSP III.txt"

Internet Draft                                         Phillip =
Hallam-Baker
draft-ietf-pkix-ocspx-01                                      VeriSign =
Inc.
September 03, 1999
Expires in six months

OCSP Extensions=20

Status of this memo

This document is an Internet-Draft and is in full conformance with all =
pro-
visions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task=20
Force (IETF), its areas, and its working groups.  Note that other groups =

may also distribute working documents as Internet-Drafts.=20

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

them other than as "work in progress."

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

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

Abstract

The OCSP protocol [RFC2560] enables online validation of the reliability =
of=20
a digital certificate. RFC2560  defines a mandatory-to-implement =
mechanism=20
supporting the revocation status of the certificate and defines and op-
tional extension mechanism to support a richer set of semantics (e.g. =
full=20
path validation by the OCSP server).

This document defines Internet-standard  extensions to OCSP that enable =
a =20
client to delegate processing of certificate acceptance functions to a=20
trusted server. The client may control the degree to which delegation =
takes=20
place. In addition limited support is provided for delegating =
authorization=20
decisions.

1	Introduction

For an application to make an informed decision as to whether it trusts =
a=20
digital certificate the application must have knowledge of the =
certificate=20
itself, a set of trusted public keys from which certificate chains may =
be=20
constructed, a set of intermediate certificate authorities from which =
the=20
trust chain may be constructed and the validation status of every =
certifi-
cate used to construct the trust chain.=20

In a typical PKI deployment these data frequently originate from =
multiple=20
sources. Certificates and certificate status information will be issued =
by=20
multiple Certification Authorities. In the typical case authorization =
data=20
will be maintained separately. As the task of managing these disparate=20
sources of data required to decide upon the acceptability of digital =
cer-
tificates increases it is advantageous to delegate this task to one or =
more=20
specialist applications.

These data must then be integrated into certificate path processing =
compli-
ant to RFC 2459 [RFC2459]. In some environments, it may be useful to =
defer=20
this integration to a trusted server, thereby relieving certificate =
using=20
functions of the need to acquire this information and integrate it into=20
compliant path processing logic.  It may also be useful to defer this =
inte-
gration to a trusted server due to the server=92s ability to more easily =
com-
bine certificate path processing with other authorization data.  =
Finally, a=20
trusted-server approach to certificate validation enables =
straightforward=20
design and implementation of a trust management system capable of =
immediate=20
response to certificate or authorization revocation.

The basic OCSP protocol [RFC2560] provides a simple mechanism for =
communi-
cating certificate revocation status and an extension mechanism for =
commu-
nicating additional types of certificate validation information. The =
exten-
sibility mechanism can accommodate advanced needs for certificate =
valida-
tion beyond simple revocation status.

This document defines Internet-standard OCSP extensions to ensure=20
interoperability among diverse PKI-based trust management systems or =
net-
works.

These extensions allow a client to delegate the tasks of deciding =
whether a=20
certificate should be relied upon and whether it is acceptable for a =
par-
ticular operation.

2 	Principal Applications

Before presenting the specific requirements for the extensions proposed =
we=20
first consider some applications whose needs have motivated this =
protocol.

2.1 Embedded Systems

We anticipate a substantial increase in the use of PKI by embedded =
systems.=20
In the short term this increase will be driven by the deployment of =
IPSEC=20
capable gateways such as routers and firewalls. In the longer term, how-
ever, it is to be expected that most embedded systems will support some=20
kind of security based on PKI.

Such devices are typically subject to significant constraints in the =
proc-
essing power and persistent storage that may be allocated to PKI =
support.=20
Support for operator interaction is limited, if indeed the device has =
any=20
I/O capability at all other than the network interface. Neither =
constraint=20
is likely to be affected by progress in technology since market demand=20
tends towards low cost devices.

Moreover, embedded devices are typically expected to have an operating=20
lifetime significantly longer than application software. Suppliers are =
con-
cerned to minimize the amount of maintenance required. Offloading =
certifi-
cate related processing functionality maximizes the useful lifetime of =
an=20
installed base of such devices while trust management technology moves =
for-
ward.

2.2	Wireless Devices

We also anticipate a substantial increase in the use of PKI enabled =
wire-
less devices. These devices share many of the constraints of embedded =
sys-
tems. Processing and memory resources are highly constrained, in this =
case=20
by battery lifetime as well as cost. Nor is it practical to support a =
com-
plex user interface on a handheld device.

It is possible for wireless devices to communicate directly with each=20
other. In a typical application however the wireless device communicates =

with a static base station which in turn is connected to a network. It =
is=20
highly desirable to offload processing tasks from the mobile unit to the =

base station.

2.3	Centralized Trust and Authorization Management

As previously discussed, determination of the acceptability of a =
certifi-
cate for a particular operation requires a substantial quantity of data, =

management of which is a complex task. In a large enterprise it is =
desir-
able to centralize this task, or at least restrict the number of systems =

performing it.

In addition to eliminating the need to distribute significant quantities =
of=20
data to relying applications, centralization of certificate acceptance=20
functions improves enterprise-wide consistency in the enforcement of =
poli-
cies relating to certificate acceptance.=20

Centralized management also yields advantages in auditing and control. =
Sus-
picious behavior patterns may be more readily detected if audit =
information=20
is centralized. If a suspicious behavior pattern is detected, further =
ac-
cess may be denied, either by automatic revocation or suspension of the=20
certificate, or by withdrawing authorization.

2.4	Use of Attribute Certificates

Attribute Certificates provide a means of distributing auxiliary =
informa-
tion which, for certain reasons, it is not desirable to include within a =

public key certificate. Such information is typically used to make =
authori-
zation decisions.

Attribute Certificates present the advantages of distributing =
authorization=20
information in a non-repudiable form. However, use of attribute certifi-
cates has been widely criticized as overburdening client =
implementations,=20
particularly since effective use of authorization certificates appears =
to=20
require application specific processing rules.

Delegating certificate-based access control decision functions, =
including=20
the processing of attribute certificate chains to an OCSP-X responder =
miti-
gates these objections. Client implementations need only implement the=20
OCSP-X request and response protocol. Sites may construct conventions =
and=20
processing rules of arbitrary complexity for enforcement of =
authorization=20
attributes and still rely on standard clients, regardless of the use or=20
non-use of attribute certificates.

2.5	Single Sign-On

A principal advantage for PKI based security is the ability to support =
sin-
gle sign-on. Password based authentication has the substantial =
disadvantage=20
that the authentication process itself requires the password to be =
revealed=20
to or previously known by the authenticating party. Public key based=20
authentication does not require a secret to be revealed or known in =
order=20
for the authenticating party to know that it is known.

Although PKI provides comprehensive support for authentication, access =
con-
trol requires both authentication and authorization to take place. It is =

not enough to know who a person is, it is equally important to know what =

that person is permitted to do.

Although many protocols already exist to support distribution of =
authoriza-
tion information there is considerable advantage to supporting =
delegation=20
to a single enterprise-level authority of all aspects of the access =
control=20
decision that require external data.

3	Requirements

The following requirements have been identified as important in the =
meeting=20
of the needs of the applications described above.

3.1	Support for Aggregation of Trust Information

On the basis of the prior analysis, there exists a need to aggregate at =
a=20
trusted server all information relevant to determining the acceptability =
of=20
a digital credential in a given context.  This information includes but =
is=20
not limited to:

*  End-user Public Key Certificates
*  CA public key certificates
*  Attribute Certificates
*  Certificate Revocation Lists or certificate status databases
*  Data provided by other OCSP and OCSP-X responders

The means by which this information is obtained by an OCSP-X server is =
be-
yond the scope of this specification.

3.2	Support for Intelligent Query

The extensions SHOULD support intelligent queries, that is queries which =

are specifically relevant to the client decision to trust a certificate.

This requirement is distinct from the type of query supported by =
directory=20
servers, including LDAP servers and X.500 servers. The data model upon=20
which these servers are designed does not support the specific types of=20
query required. Nevertheless it would be highly appropriate for a single =

server to support both OCSP-X and LDAP retrievals from a common =
database.

3.3	Delegated Trust Decision

The extensions SHOULD allow a client to delegate all aspects of deciding =

the authenticity and validity of a certificate.

It is NOT a requirement that every response be justified by providing =
in-
formation such as the certificate chain generated and relevant CRLs. The =

objective of OCSP-X is to permit a client to simplify certificate =
valida-
tion decisions by offloading them to an external client. This objective =
is=20
negated if the client is then required to duplicate the trust decision.

3.4	Delegated Authorization Decision

The extensions SHOULD support the delegation of authorization decisions =
to=20
the OCSP-X responder.

It is not however a requirement for that the OCSP-X responder provide =
in-
formation to the relying application so that the relying application may =

duplicate the authorization decision.

3.5	Support for Status Update Notification Protocols

In many circumstances it is necessary for an application to track =
changes=20
in the validity of a certificate after the initial decision to trust the =

certificate has been made.

A wide variety of architectural approaches are appropriate to meet this =
re-
quirement and the specification of a specific protocol for the purpose =
is=20
outside the scope of this particular draft. It is not therefore a =
require-
ment that these extensions propose a specific notification protocol but =
use=20
of such a protocol SHOULD be supported.

Pending the development of such a protocol, clients which need to track=20
changes in certificate validity may do so by polling the OCSP-X =
responder.=20
It is therefore a requirement that the protocol support this mode of use =

efficiently.

4	Non-Requirements

Support for the following features was considered but rejected.

4.1	Delegated Key Exchange

Support for delegation of key exchange processing was considered but re-
jected as being more appropriate for independent discussion.

A client relying on an OCSP server for trust path evaluation might also=20
delegate other aspects of a cryptographic negotiation scheme such as key =

exchange.

While it is highly desirable for embedded devices such as IPSEC routers =
to=20
offload complex processing tasks to other processors support for such a=20
feature would inevitably involve strong interdependencies with the key =
ex-
change protocols to be supported. The complexity of such a protocol =
would=20
therefore be considerable and it is not clear that a sufficient degree =
of=20
generality across protocols could be achieved.

4.2	Alternate Response Syntax

Support for an alternative response syntax was considered but rejected =
as=20
being more appropriate for independent discussion.

The advantage of an alternate response syntax is that it would permit =
de-
vices with limited processing capability to receive responses encoded in =
a=20
simpler syntax than ASN.1. While construction of an ASN.1 BER encoded =
re-
quest message is not unduly burdensome on a client implementation the =
pars-
ing of OCSP responses is considered unnecessarily complex by many.

4.3	Modification of Authorization Data

Support for client requests to modify authorization data was considered =
but=20
rejected as introducing an unacceptable degree of additional complexity=20
into the protocol.

Support for such a feature would permit implementation of client =
=91owner-
ship=92 of resources whose authorization data is managed by the OCSP-X=20
server. Such support would however require a considerably more detailed=20
definition of the authorization framework than specification of the re-
sources for which authorization is requested and the mode of access re-
quested. In particular it would be necessary to commit to a data model =
for=20
the authorization data.

While support for such a feature is likely to prove necessary in time, =
the=20
substantial degree of additional complexity involved strongly suggests =
that=20
it preferable to address the issue separately.

5  OCSP Message Framework

The OCSP message format is defined in RFC 2560. This section describes =
the=20
use made of the OCSP message format within this document.

5.1	Extension Framework

The OCSP extension framework permits additional data to be incorporated =
in=20
an OCSP message such that the extension data applies to an entire =
request=20
or to specific certificate in a response. Similarly the framework =
permits=20
extensions in a response to apply to either the response as a whole or =
to a=20
specific certificate in the response.

In this document we refer to extensions which apply to a message as a =
whole=20
as =91message extensions=92. Extensions which apply only to a specific =
certifi-
cate are referred to as =91certificate specific extensions=92.  =
Extensions that=20
MAY be employed in either manner are referred to as simply =
=91extensions=92.

These terms correspond to the ASN.1 structures defined in RFC 2560 as =
fol-
lows:

Identification                    Structure           Element

Response Message                  OCSPRequest     requestExtensions
Certificate Specific Response     Request         =
singleRequestExtensions=20
Reply Message                     ResponseData    responseExtensions
Certificate Specific Reply        SingleResponse  singleExtensions=20

5.2	Status Reporting

OCSP-X defines a number of extended response codes. It is intended that=20
these augment the response codes defined by RFC2560, providing =
additional=20
status information where needed.

OCSP-X extended status codes SHALL be reported using the id-pkix-ocspx-
status extension OID in the response as defined bellow.

6	Extension Elements

All extensions are tagged using OIDs formed of the existing OCSP arc.

id-pkix-oscpx		OBJECT IDENTIFIER ::=3D { id-pkix-ocsp [TBS] }

An OCSP client MAY signal support for OCSP response extensions by =
including=20
the id-pkix-ocspx-support OID as an OCSP acceptable response type. =
Alterna-
tively, clients that include OCSP extensions in their request SHALL be =
ca-
pable of support for OCSP response extensions in the manner defined by =
this=20
specification.

id-pkix-ocspx-support	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 1 }

A server MAY advertise that it supports the OCSP-X extensions by =
including=20
the id-pkix-ocspx-support OID as a message extension in any OCSP =
response.=20
The OID id-pkix-ocspx-support MUST NOT be included as a certificate spe-
cific extension.

If a server receives no signal from the client as defined above, it MAY =
in-
clude response extensions, but MUST be capable of basic OCSP as defined =
in=20
RFC2560.

Where extended status codes are defined these are returned as response =
ex-
tensions using the id-pkix-ocspx-status OID and ExtendedStatus =
structure:

id-pkix-ocspx-support	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 2 }

ExtendedStatus :=3D=3D SEQUENCE OF SingleExtendedStatus

SingleExtendedStatus :=3D=3D CHOICE {
    TRUST_NOT_SUPPORTED          [1] 	EXPLICIT NULL
    ROOT_NOT_ACCEPTABLE          [2] 	EXPLICIT NULL
    TRUST_ROOT_REQUIRED          [3] 	EXPLICIT NULL
    RULE_NOT_SUPPORTED           [4] 	EXPLICIT NULL
    TRUST_PATH_NOT_FOUND         [5] 	EXPLICIT NULL
    TRUST_PATH_VALIDATED         [6] 	EXPLICIT NULL
    CERTIFICATE_NOT_TRUSTED      [7] 	EXPLICIT NULL
    REGISTRATION_NOT_SUPPORTED   [8]	EXPLICIT NULL
    AUTHORIZATION_NOT_SUPPORTED  [9]	EXPLICIT NULL
    }

6.1	Specify Trust Root

The specify trust root extension is used to specify the trust root(s) =
for a=20
trust delegation request.

If the trust root is not specified in the request the selection of trust =

roots is delegated to the OCSP status server.

Request

id-pkix-ocspx-root	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 3 }

TrustRoot ::=3D SEQUENCE {
        certificates SEQUENCE OF CertID }

By including a specific trust root, client indicate a need to determine =
if=20
the certificate identified in the request is trusted by the server under =

the authority of the identified root.  An affirmative response from the=20
server confirms that the server has, among other functions, =
cryptographi-
cally proven by trust path logic that the signature on the subject =
certifi-
cate is valid under the indicated root.  The means by which the server =
ac-
quires the information necessary to arrive at this conclusion is beyond =
the=20
scope of this specification.  One means could be by prior acquisition of =

the appropriate cross-certificate.

Response

If the server is unable to develop a trust chain from the subject =
certifi-
cate to the indicated trust root, an error code is returned.

TRUST_NOT_SUPPORTED  Trust Root Processing is not supported
ROOT_NOT_ACCEPTABLE  The specified trust root is not known to the =
server-=20
TRUST_ROOT_REQUIRED  Explicit specification of the trust root is =
required    =20
                     to permit trust delegation.

6.2	Specify Processing Rules

In certain circumstances a client may require the OCSP server to apply a =

particular set of certificate path processing rules

Request

The client may specify the processing rules under which the trust chain =
is=20
to be constructed. If no trust rules are specified the responder SHOULD =
em-
ploy the processing rules specified by RFC2459.

id-pkix-ocspx-rules	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 4 }

Rules ::=3D SEQUENCE {
        rules 	SEQUENCE OF Rule }

Rule ::=3D SEQUENCE {
        oid		OBJECT IDENTIFIER}

Response

If the server is unable to support all of the path processing rules =
speci-
fied it MUST return an error.

RULE_NOT_SUPPORTED  The requested processing rules are not supported by =
the
                    server.

6.3	Evaluate Trust Path

The client requests that the OCSP-X responder attempt to construct a =
valid=20
trust path originating from a trust root. Optionally the client may =
request=20
that the responder return part or all of the data used to construct and=20
validate the certificate chain.

Request

id-pkix-ocspx-evaluate	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 5 }

Evaluate ::=3D SEQUENCE {
        reportTrustChain            [1] IMPLICIT NULL
        reportValidation            [2] IMPLICIT NULL
        returnTrustChain            [3] IMPLICIT NULL
        returnValidation           [4] IMPLICIT NULL }

Response

CERTIFICATE_NOT_TRUSTED          The certificate is not trusted
=20
TRUST_PATH_VALIDATED             The certificate is trusted
=20
TRUST_PATH_NOT_FOUND             The trust status of the certificate =
could
                                 not be determined.

6.4	Register Trust Path

A client may employ the register trust path extension to notify the =
server=20
that the validity of a trust path will be of ongoing significance to the =

client during a specified time interval A client MAY optionally request =
no-
tification if a certificate reported to the client as being valid is re-
voked during the specified time interval.

The specific actions to be taken if a trust path be invalidated while a=20
client is relying upon it are a matter for site specific policy. =20

OCSP-X responders MAY support the use of an OCSP response as a =
notification=20
mechanism. In this case the notifyUri member is present and specifies by =

means of a URI both the transfer protocol (e.g. HTTP) and the address to =

which the notification is to be sent.

The use of OCSP-X messages over HTTP as a notification protocol is =
vulner-
able to a denial of service attack however. An extension mechanism is =
sup-
ported to allow improved notification mechanisms to be specified in =
future=20
documents.

Request

id-pkix-ocspx-register	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 6 }

Register ::=3D SEQUENCE {
      until                     [0] EXPLICIT GeneralizedTime OPTIONAL
      notifyUri                 [1] EXPLICIT OCTET STRING OPTIONAL
      notificationExtensions    [2] EXPLICIT Extensions OPTIONAL}

Response

REGISTRATION_NOT_SUPPORTED        Registration is not supported

NOTIFICATION_NOT_SUPPORTED        Notification is not supported

6.5	Authorization Delegation

The basic OCSP response provides only authentication information. In =
many=20
applications it is desirable to supply both authentication and =
authoriza-
tion from a centralized source.

A request for authorization delegation must specify both the party which =

requests access and the resource for which access is requested. In =
addition=20
a request for authorization MAY present a chain of attribute =
certificates=20
containing information relevant to the authorization decision.

Resources are identified using URIs according to a convention chosen by =
the=20
client, the definition of which is outside this document. URIs provide a =

uniform syntax for identification of resources in a hierarchical =
fashion.

A request for authorization delegation need specify only the URI of the =
re-
source for which access is being requested and the specific mode of =
access=20
requested.

Four modes of access control are supported, GET, PUT, EXECUTE and LINK. =
The=20
GET and PUT and EXECUTE modes correspond respectively to the traditional =

Read and Write and EXECUTE modes supported by conventional operating =
sys-
tems. The LINK mode corresponds to a superset of the CONTROL mode of a =
con-
ventional operating system and when granted permits the recipient to =
spec-
ify and meta-information related to the resource, including =
authorization=20
information.

Where finer grained access control is required than is supported by =
these=20
four modes implementations may specify access control at an arbitrary=20
granularity by using an extended URI convention.

Each authorization request specifies one or more URIs that identify re-
sources for which authorization is requested. The convention by which =
URIs=20
refer to resources is discussed further in Appendix A. Specification of=20
this convention is outside the scope of this document.

The responder SHALL either return the extended response code=20
AUTHORIZATION_NOT_SUPPORTED or return an AuthorizationResponse =
certificate=20
specific extension.

The AuthorizationResponse SHALL consist of a number (possibly zero) of =
Re-
sourceResponse structures. Each ResourceResponse structure SHALL =
describe=20
the authorization status of the entity identified by the respective cer-
tificate with respect to the range of resources identified by the =
specified=20
URI.

The range of resources identified by the URIs in the authorization =
response=20
MAY be more specific, less specific or equally specific as the range =
speci-
fied in the request.

In cases where the party for whom authorization is requested has =
authoriza-
tion to access a broad range of resources and the client requests access =
to=20
a specific resource within that range the responder MAY specify the =
broader=20
range in its response. This permits the client to cache the =
authorization=20
response, eliminating the need for repeated authorization requests for=20
closely related resources.

In cases where the party for whom authorization is requested has =
authoriza-
tion to access a specific range of resources the and client requests =
access=20
to a broad range of resources which encompasses it the responder MAY =
spec-
ify the more specific range in its response. This permits the client to=20
provide navigation menus tailored to the specific set of resources to =
which=20
the party is permitted access.

Request

The request specifies a list of one or more resources for which =
authoriza-
tion is requested.

id-pkix-ocspx-authorize	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 7 }

AuthorizationRequest ::=3D {
      requests    SEQUENCE OF ResourceData
      certs       [0] EXPLICIT SEQUENCE OF Certificate
      }

ResourceData {
      uri         Uri
      mode        AuthorizationMode}

AuthorizationMode	::=3D SEQUENCE {
      get         [1] NULL
      put         [2] NULL
      execute     [3] NULL
      link        [4] NULL }

Uri   ::=3D OCTET STRING

Response

The id-pkix-ocspx-authorize-response certificate specific response =
exten-
sion specifies a sequence of one or more ResourceResponse structures =
each=20
of which reports the authorization status of the party identified in the =

respective certificate with respect to a range of resources.

The following authorization statuses may be reported:

permit      Access to the specified resource is permitted

deny        Access to the specified resource is denied

unknown     The responder does not know the authorization status of the
            resource.

refused     The responder refuses to disclose the authorization status
            of the resource.

id-pkix-ocspx-authorize-response
                       OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 8 }

AuthorizationResponse ::=3D SEQUENCE OF ResourceResponse

ResourceResponse :=3D=3D SEQUENCE {
      resource    ResourceData
      status      AuthorizationStatus }

AuthorizationStatus :=3D=3D CHOICE {
      permit      [1] EXPLICIT
      deny        [2] EXPLICIT=20
      unknown     [3] EXPLICIT
      refused     [4] EXPLICIT}

AUTHORIZATION_NOT_SUPPORTED	The OCSP-X responder does not support the=20
authorization extensions.

7	Security Issues

7.1	Security of the OCSP-X Responder

Compromise of an OCSP-X responder would severely impact the security of =
any=20
application relying upon it.

Centralized management of information required for trust path processing =

could potentially introduce the possibility of a denial of service =
attack.=20
The scope for denial of service attacks does not appear to be =
substantially=20
increased in the typical enterprise implementation scenarios however.

In the case where applications delegate any or all of the trust decision =

process itself to the OCSP-X responder, compromise of the OCSP-X =
responder=20
constitutes compromise of the application itself for all practical pur-
poses.

Both risks may if necessary be mitigated by means of deployment of =
multiple=20
OCSP-X servers configured in such a manner that the decisions made by =
each=20
server are audited by one or more other servers.

7.2	Audit

An OCSP-X server may be employed to enforce system audit requirements. =
In=20
such a configuration the use of wildcard responses in authorization re-
sponses must be carefully considered if the audit trail is to be suffi-
ciently detailed.

7.3 Notification Protocol Subject to Denial of Service Attack

The simple notification protocol described is vulnerable to a denial of=20
service attack. Nevertheless the protocol described has value in =
applica-
tions where either the possibility of a denial of service attack is not=20
present or where such an attack is prevented by a separate protocol, =
defi-
nition of which is outside the scope of this draft.

8	Collected Syntax

[To be specified]

9.  References

[RFC2560]  X.509 Internet Public Key Infrastructure Online Certificate
           Status Protocol, M. Myers, R. Ankney, A. Malpani, S. =
Galperin,
           C. Adams, RFC 2560, March 1999

10	Acknowledgements

The author would like to acknowledge the extensive contribution made to=20
this draft at an early stage by Michael Myers and Warwick Ford. In =
addition=20
some of the ideas presented were previously presented by Ambarish =
Malpani=20
and Paul Hoffman in their August 1999 Internet draft Simple Certificate=20
Validation Protocol (SCVP). This draft builds upon this earlier work and =
on=20
comments made on both documents and to the IETF mailing list by many =
people=20
including Carlisle Adams, Barbara Fox, Todd Glassey, Mack Hicks, Bob =
Juene-
man, Steve Kent, Dennis Pinkas, Brian LaMachia, Alan Lloyd, Rich Saltz, =
Pe-
ter Williams and Michael Zolotarev.

11	Author=92s Address

Dr Phillip M. Hallam-Baker
VeriSign Inc.
301 Edgewater Place
Wakefield
MA 01880
[e-mail]

Appendix A Authorization Example

	For either authorization or authentication to be performed in a uni-
form manner across a network it is of course essential that the relevant =

parties agree on a uniform namespace for 'who' and 'what'.

	The case of 'who' is already dealt with by X.509v3 / PKIX. The case=20
of 'what' is more complex since most of the resources to be identified =
are=20
local. Some form of abstract namespace is required. It is essential that =

the central database(s) in which authorization data is maintained and =
the=20
parties relying upon those databases have a common agreement as to whats =

what.

Example:

	Widgets 'R Us (wideget.test) has two departments, manufacturing and=20
sales. Both departments separately manage ERP systems which are =
primarily=20
for their own use but a limited number of personnel need access to both.

	The sales ERP system is maintained on a collection of servers called:
=20
	erp1.sales.widget.test
	erp2.sales.widget.test

	The ERP system supports three basic access levels, Salesman, Manager=20
and Administrator. These access levels are mapped onto URIs as follows:

	Salesperson		URN:sales-widget.test/erp/salesperson
	Manager		URN:sales-widget.test/erp/manager
	Administrator	URN:sales-widget.test/erp/administrator

	Note that the sysops have decided to hide the fact that the ERP sys-
tem is maintained on two separate systems since they want both to use =
iden-
tical=20

	In this particular case the delegation of authorization functions to=20
the central system is only partial. The ERP system accepts external =
input=20
that informs it of the seniority/access role of the individual concerned =
-=20
the type of information that would generally be handled by a corporate=20
admin and is usefully shared between applications.

	The ERP system is also tracking the ownership status of resources=20
created by its users. When a salesman creates a particular customer ac-
count, that salesman has 'ownership' of that resource and may well have=20
privileged access to it.

	What the central authorization system is doing is offloading the need=20
to create new user accounts in the ERP system as salespeople join and=20
leave. A typical interaction therefore is:

1. Alice is hired as a salesperson.
	1: She is issued a digital certificate	'alice'
	2: An authorization record is created of the form
		PERMIT alice URN:sales-widget-test/erp/salesperson

2. Alice accesses the ERP system for the first time
	1: There is no account for alice
	2: An OCSP-X request is made to see if alice is authorized
		[access URN:sales-widget-test/erp/salesperson/menu]
	   The responder reports Alice is authorized to do anything under
		URN:sales-widget-test/erp/salesperson
	3: The ERP application notes that alice is authorized to be
	a salesperson and creates an account for her.

3. Alice accesses the ERP system for the second (or nth) time
	1: The ERP system notes there is an account for alice
	2: An OCSP-X request is made to see if alice is still
		authorized [access URN:sales-widget-test/erp/salesperson]
	3: alice is still authorized - good!

4. Alice is promoted to manager
	1: Her entry in the OCSP-X server is modified to reflect her
		new status.

5. Alice is suspended after refusing to use the CSR system to report
	that the CSR system is down and not accepting reports.
	1: Her authorizations for operations are withdrawn at the=20
		OCSP-X system. Her certificate is neither revoked, nor
		suspended however since she still is Alice and she still
		needs access to her 401K plan (she is going to need it=20
		soon!)

6. Alice is fired
	1: Her certificate is revoked
	2: The OCSP-X server is informed

	3: OPTIONAL, if the notification process has been used the
	OCSP-X server could notify the certificate management system
	of any applications currently relying on the certificate for
	authorization]

7. Alice attempts to access the ERP system
	1: The ERP system notes there is an account for alice
	2: An OCSP-X request is made to see if alice is still
		authorized [access URN:sales-widget-test/erp/salesperson]
	3: alice is not authenticated - and refused access

There is a variant of this scenario which is worth mention. In this =
variant=20
it is important that Alice be only presented with menu items for which =
she=20
is permitted access. The relying application must therefore know her =
per-
missions without actually instigating an operation itself.

Requirement: Support some sort of generic query interface.

This may be supported by permitting a responder to reply with the least=20
specific mode of access permitted when an over-general request is made.

In this scenario the OCSP-X responder would generate its initial startup =

screen by requesting whether Alice had permission to access URN:sales-
widget-test/erp/ The responder would then reply that she only had =
permis-
sion to access URN:sales-widget-test/erp/salesperson


Example 2: Manufacturing server

The needs of manufacturing are slightly different. In this case there =
are=20
many applications which need to share authorization data between them. =
For=20
example, the machine shop contains a press and a lathe, each controlled =
by=20
a computer. Jobs are passed from the press to the lathe. Authorization =
data=20
attaches principally to the job and not to the specific machinery.

Bob is authorized to use the lathe, the press and the fleam. Carol is=20
authorized to use the lathe and the press

Bob owns jobs 1, 2, 5 and 6
Carol owns jobs 3, 4 and 7

The two sets of authorization data are tracked separately by
two separate OCSP-X servers. Access to the machinery is controlled by =
the=20
accreditation group who run exams in the use of the machinery. Ownership =
of=20
jobs is tracked by the job track and dispatch ERP system

Bob's authorizations are therefore:

URN:credit-widgets-test/machines/lathe
URN:credit-widgets-test/machines/press
URN:credit-widgets-test/machines/fleam

URN:shop-widgets-test/jobs/1
URN:shop-widgets-test/jobs/2
URN:shop-widgets-test/jobs/5
URN:shop-widgets-test/jobs/6

Conclusion:

Clearly configuration of such a system leaves much to the implementers =
who=20
must decide issues such as namespace conventions.

The objective is to permit application vendors to ship products in such =
a=20
manner that it is possible to readily support the decisions made by the =
en-
terprise without requiring custom code for each application - as use of =
API=20
toolkits tends to do.

The ERP applications in these examples establish the convention for the=20
lower level of the hierarchy [i.e. the suffix]. The enterprise =
establishes=20
the convention for the higher level of the hierarchy - the prefix.=20

Quite where the boundary should lie is probably best left to the enter-
prise. OCSP-X responders and applications should probably both provide a =

degree of flexibility. For example the sales ERP application could =
provide=20
no more flexibility than allowing the enterprise to specify the prefix =
and=20
a list of valid responder addresses with public keys to authenticate =
them=20
by:

OCSP-X
	Prefix =3D	URN:sales-widget-test/erp
	Server =3D	{
		url		http://ocspx1.sales.widget.test/
		priority	50
		[key info]	}
	Server	{
		url		http://ocspx2.sales.widget.test/
		priority	50
		[key info]	}

A more flexible approach however would allow each of the resources =
defined=20
to be mapped to URIs of the enterprise's choosing.

For example the enterprise may have already allocated roles for a =
particu-
lar project and it may be simplest to map these roles in the application =
as=20
opposed to the OCSP-X system.

OCSP-X
	Resources =3D	{
		salesperson		URN:sales-widget-test/erp/user
		manager		URN:sales-widget-test/erp/admin
		administrator	URN:sales-widget-test/erp/admin }
	Server =3D	{
		url		http://ocspx1.sales.widget.test/
		priority	50
		[key info]	}
	Server	{
		url		http://ocspx2.sales.widget.test/
		priority	50
		[key info]	}



------=_NextPart_000_0052_01BF14BE.CE077440--



Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA05107 for <[e-mail]>; Tue, 12 Oct 1999 08:44:25 -0700 (PDT)
From: [e-mail]
Received: by relay1.trustworks.com (8.8.5/1.4) id TAA01480; Tue, 12 Oct 1999 19:46:12 +0400 (MSD)
Message-Id: <[e-mail]>
Received: from tws123(212.114.5.15) by zuka via smap (V2.0) id xma001465; Tue, 12 Oct 99 19:45:45 +0400
To: "'Phillip M Hallam-Baker'" <[e-mail]>, Carlisle Adams <[e-mail]>
Date: Tue, 12 Oct 1999 19:48:06 +0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: Delta CRL Distribution Points
Reply-to: [e-mail]
CC: Trevor Freeman <[e-mail]>, "Pkix List (E-mail)"	 <[e-mail]>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.11)

On 5 Oct 99, at 11:35, Carlisle Adams wrote:

> Hi Phill,
> 
> > ----------
> > From: 	Phillip M Hallam-Baker[SMTP:[e-mail]]
> > Sent: 	Thursday, September 30, 1999 11:24 AM
> > To: 	Trevor Freeman; Pkix List (E-mail)
> > Subject: 	RE: Delta CRL Distribution Points
> > 
> > As I said earlier, delta CRLs are problematic and managing them is
> > intrinsically complex. Scope CRLs offer considerably more flexibility,
> > are intrinsically simpler and in many cases address the same need.
>  
> I don't understand your comment that deltas are problematic and that
> managing them is intrinsically complex.  Perhaps it stems from your earlier
> comment:
> 
> 	I believe that the root of the complexity in this case is attempting
> to
> 	manage a situation where multiple signed documents issued at
> different
> 	times must be combined to validate a certificate. This is an
> intrinsic
> 	problem with both Delta CRLs and Paul Kocher's CRTs. If the voulme
> of
> 	updates becomes large there is a scalability problem which manifests
> 	itself as a reliability issue as opposed to a performance issue.
> 
> In practice, there are not "multiple signed documents ... that must be
> combined to validate a certificate".  There's no real combining going on.  I
> have a base cached on my local system and I want to check an incoming
> certificate.  I retrieve the latest delta.  
	
Excuse me, in this point of CRL processing I have a question:
Say, a system has only baseCRL ( retrieved with certificate CRL 
distribution point ). Okay, certificate is checked and good. But
here is some doubt - Is it possible that certificate has been revoked 
in delta-CRL? Okay, let me think... look around what I have at the
moment: CRLDP and the same IDP in CRL (say it looks like 
http://somefirm/revokedcerts.crl). How can I find any information
where I can get deltaCRL? I see only one possibility:
	default distribution point - value of attribute deltaRevocationList
      in CA entry of Directory;

What have I miss?

> Is the cert serial number on the
> base?  (Yes or No.)  If not, is it on the delta?  (Yes or No.)
> 
> Conceptually, you can think of the relying party combining the base and
> delta into a single larger CRL and checking that, but in actual code nobody
> needs to combine these things at all.  A sequential check of the two lists
> is sufficient.  Checking two lists instead of one does not seem to me to be
> inherently "problematic" or an "intrinsically complex" management task.
> 
> What have I missed?
> 
> Carlisle.
> 
> P.S., Scopes are great, and offer wonderful flexibility.  But do they really
> help with the timeliness issue (which is where deltas are particularly
> intended to be useful)?  In other words, do scopes and deltas really address
> the same need in many cases?
> 
> 


____________
Pavel Krylov


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA28772 for <[e-mail]>; Tue, 12 Oct 1999 03:55:49 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08252; Tue, 12 Oct 1999 06:57:11 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ac509prof-01.txt
Date: Tue, 12 Oct 1999 06:57:10 -0400
Sender: [e-mail]

--NextPart

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

	Title		: An Internet Attribute Certificate Profile for         
                          Authorization
	Author(s)	: S. Farrell, R. Housley
	Filename	: draft-ietf-pkix-ac509prof-01.txt
	Pages		: 32
	Date		: 11-Oct-99
	
Authorization services are required for numerous Internet protocols,
including TLS, IPSec, and S/MIME. The X.509 Attribute Certificate
provides a structure that can form the basis for such services
[X.509]. This specification defines a profile for the use of X.509
Attribute Certificates to provide authorization services for
Internet protocols. Some optional features are also specified which
are not required for conformance to the base profile.

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA29794 for <[e-mail]>; Mon, 11 Oct 1999 05:34:46 -0700 (PDT)
Received: (from firewall@localhost) by firewall.andxor.it (8.8.7/8.8.7) id OAA02637 for <[e-mail]>; Mon, 11 Oct 1999 14:23:52 GMT
X-Authentication-Warning: firewall.andxor.it: firewall set sender to <[e-mail]> using -f
Received: from lello.andxor.it(195.223.2.223) by firewall.andxor.it via smap (V2.0) id xma002633; Mon, 11 Oct 99 14:23:44 GMT
Message-ID: <[e-mail]>
Date: Mon, 11 Oct 1999 14:35:26 +0200
From: Raffaello Galli <[e-mail]>
Organization: C&A
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Timestamp protocol and IssuerAndSerialNumber OID
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA41B5AFC6A262C68717B9F54"

This is a cryptographically signed message in MIME format.

--------------msA41B5AFC6A262C68717B9F54
Content-Type: multipart/mixed;
 boundary="------------D572F01FB8E51BA214420FB1"

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

Hi,

Since the PKIX Time Stamp protocol (draft) requires to include
"IssuerAndSerialNumber" as an authenticated attribute in a  "SignerInfo"

sequence our question is:

Any of you know which OID is bounded to IssuerAndSerialNumber ?

Thanks for your help

Raffaello and Thomas

--------------D572F01FB8E51BA214420FB1
Content-Type: text/x-vcard; charset=us-ascii;
 name="r.galli.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Raffaello Galli
Content-Disposition: attachment;
 filename="r.galli.vcf"

begin:vcard 
n:Galli;Raffaello
tel;fax:++.39.2.24791826
tel;home:Please call me at work.
tel;work:++.39.2.24791823
x-mozilla-html:FALSE
url:www.com-and.com
org:C & A   Improve Your Security
adr:;;Viale Fulvio testi 126 ;Cinisello Balsamo   (MI);ITALY;20092;ITALY
version:2.1
email;internet:[e-mail]
title:Responsabile Tecnologie
note;quoted-printable:-------------------------  Improving Your Security  -------------------------=0D=0ACertification Authority -  X509 V3  -  RSA Strong  =0D=0AWeb Server SSL3 Strong  - Proxy SSL =0D=0ACrypto Smart Card - PKCS#11=0D=0AKey Manager -  Time Manager=0D=0ATime Stamping Authority  -  Corba (IIOP over SSL)=0D=0A-------------------------  Improving Your Security  -------------------------
x-mozilla-cpt:;-1
end:vcard

--------------D572F01FB8E51BA214420FB1--

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

MIIF8QYJKoZIhvcNAQcCoIIF4jCCBd4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BBEwggQNMIIC9aADAgECAgIAizANBgkqhkiG9w0BAQQFADCBvDELMAkGA1UEBhMCSVQxDzAN
BgNVBAgTBk1JTEFOTzEVMBMGA1UEBxMMQ2luaXNlbGxvIEIuMRYwFAYDVQQKEw1DLiBhbmQg
QS4gc3JsMSwwKgYDVQQLEyNDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAoRGVtbyAyMDQ4KTEc
MBoGA1UEAxMTTWFzdGVyIC0gQy5hbmQgQS4gLTEhMB8GCSqGSIb3DQEJARYSbWFzdGVyQGNv
bS1hbmQuY29tMB4XDTk5MTAwMjEzMzUyNVoXDTAwMDMzMDE3MzUyNVowgZ0xCzAJBgNVBAYT
AklUMQ8wDQYDVQQIEwZNaWxhbm8xFTATBgNVBAcTDENpbmlzZWxsbyBCLjEQMA4GA1UEChMH
QyBhbmQgQTERMA8GA1UECxMIU2VjdXJpdHkxHTAbBgNVBAMTFEluZy4gUmFmZmFlbGxvIEdh
bGxpMSIwIAYJKoZIhvcNAQkBFhNyLmdhbGxpQGNvbS1hbmQuY29tMFwwDQYJKoZIhvcNAQEB
BQADSwAwSAJBALRuGV1VQvFpa5radJTTeG2Toz6eVDKvxr5rxyMqOwRUxbBLgh4p4ft4dgYn
afLbAKWNfyYosAd5ZJtlQRoBV4ECAwEAAaOB/TCB+jAuBglghkgBhvhCAQQEIRYfaHR0cDov
L3d3dy5jYW5kYS5jb20vY2EtY3JsLnBlbTCBtAYJYIZIAYb4QgENBIGmFoGjVGhpcyBpcyBh
IHN0YW5kYXJkICBYNTA5IFYuMyBDZXJ0aWZpY2F0ZSAoV2ViIGFuZCBFLW1haWwpICBzaWdu
ZWQgYnkgQyZBIHdpdGggdGhlIDIwNDggYml0cyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBD
ZXJ0aWZpY2F0ZS4gVGhpcyBDZXJ0aWZpY2F0ZSBpcyB2YWxpZCAxODAgZGF5czARBglghkgB
hvhCAQEEBAMCAKAwDQYJKoZIhvcNAQEEBQADggEBAChm3DmFw3/7jc+hWntzPKa8tVerWC8U
b99sZ+aIUzeBjZy+0nCHTA+L/VE9DZ3DRptl5BY5l14CUZ82nslPE1sV4n8WYy3BBVDgzF0j
ZOznN2CgiWPm81LZc9wh1vxsbGUG7+579GjwiRX/CqXgCOgo4EMdbrI8XzMIx10kUphpI87+
BG5JXVJy84ZLbwKg0SwdVz1oule0PzzBNoIElyqhCwHOnpedPq+TSr6FvsWAipi01ZK/Y2r2
6o5dNBp/LIzH4ixD0s/KHnsVqaG2q2Slmq45mhyfmHEhg8KLmyPAJORSg+gscaTO68uvuyfO
RMR64MWIzY7iLWwhEnCMvR0xggGoMIIBpAIBATCBwzCBvDELMAkGA1UEBhMCSVQxDzANBgNV
BAgTBk1JTEFOTzEVMBMGA1UEBxMMQ2luaXNlbGxvIEIuMRYwFAYDVQQKEw1DLiBhbmQgQS4g
c3JsMSwwKgYDVQQLEyNDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAoRGVtbyAyMDQ4KTEcMBoG
A1UEAxMTTWFzdGVyIC0gQy5hbmQgQS4gLTEhMB8GCSqGSIb3DQEJARYSbWFzdGVyQGNvbS1h
bmQuY29tAgIAizAJBgUrDgMCGgUAoH0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNOTkxMDExMTIzNTI2WjAeBgkqhkiG9w0BCQ8xETAPMA0GCCqGSIb3DQMC
AgEoMCMGCSqGSIb3DQEJBDEWBBSkeaBgttc5MPIrWmB4J+T01inw/DANBgkqhkiG9w0BAQEF
AARAWd1D4oh/NMCc5qAx/A3gDi/dBH9WFV8dzkD+YRoSGul56hOfTP7ThD2zfgWZ2XT5sahZ
mSggEQQjmYU0/xcMDw==
--------------msA41B5AFC6A262C68717B9F54--



Received: from relay.veriguard.com (relay.securify.com [207.5.63.61]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA03264 for <[e-mail]>; Wed, 6 Oct 1999 17:47:25 -0700 (PDT)
Received: by relay.veriguard.com; id RAA03579; Wed, 6 Oct 1999 17:46:25 -0700 (PDT)
Received: from unknown(10.5.63.6) by relay.veriguard.com via smap (4.1) id xma003549; Wed, 6 Oct 99 17:45:32 -0700
Received: from securify.com (psyche.securify.com [10.5.63.231]) by dude.veriguard.com (8.8.7/8.8.7) with ESMTP id RAA24320; Wed, 6 Oct 1999 17:45:27 -0700
Message-ID: <[e-mail]>
Date: Wed, 06 Oct 1999 17:46:00 -0700
From: "Kelly D. Lucas" <[e-mail]>
Organization: Kroll-O'Gara
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Stephen Kent <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Huge CRLs
References: <v04020a03b4002a7dc532@[128.89.0.111]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I think that ValiCert is addressing this problem, with their Global
Validation Authority Service.  It's currently in beta, and will bet
out soon.  Basically, they are acting as a consolidation point for
CA's, and Enterprises that run their own CA's, and then they are
sending this info to all subscribed.

Check out:

http://www.valicert.com/products/

and then look at the ValiCert Global VA Service.

kdl



Ed Gerck wrote:
> 
> Stephen Kent wrote:
> 
> > >Revocation is one of the most critical problems that must be addressed and
> > >tons of smart people are working on it.  Some of my team/partners/members are
> > >spending nearly all of their time trying to make revocation work the way we
> > >need it to work.   The financial services sector is providing significant
> > >input on requirements, technology, and resources to try to make PKI work for
> > >us.
> > >
> > >No offense intended, but the nature of our businesses and the limitations of
> > >the technology do not lend themselves to the use of CRLs.  The how and why
> > >will have to wait for a later message (tonight).
> >
> > Not all the world is the financial services sector.  Criticisms of CRL use
> > models based primarily on difficulties encountered in employing them in
> > that environment, or based on poor implementations, or based on poor
> > management parameter choices, etc.  do not necessarily mean that CRLs are
> > unworkable.
> 
> CRLs, which were first thought to be a positive aspect of relying on CAs
> as compared to PGP for instance, presents several unsolvable problems.
> 
> For example, there may be a considerable delay (no warranties can be
> found on on CAs contracts about upper limits for such delays) between the
> actual need to revoke a certificate and the reflection of this need in a
> certificate chain with different CAs.
> 
> Also, requiring the user to check with a CA before sending a message
> makes the use of multiple CAs much more difficult, unless they can be
> convinced to work together, an interesting problem for competing
> businesses.  Constant checking with a single CA also makes traffic
> analysis much easier. Even if the attacker cannot intercept the
> message which is sent, if the attacker can monitor the central CA
> (with a single administrative order and a GAKware system to circumvent
> any encryption), everyone's communication patterns can be seen.
> Also, an attacker can fool a CA into revoking a key -- a denial of service
> attack.
> 
> Further, the major X.509 security application today, SSL, does not
> check revocation lists -- so they are near to useless. Also, the user is
> not able to check server certificates (and certificates in the CA chains)
> against revocation lists.
> 
> An examplary case regarding  CRLs, is that they are a will to revoke but
> not an actual revocation. Few recognize that CRLS are a solution to a
> non-existent problem ... while the real problem is left utterly unsolved. The
> non-existent problem solved by CRLs is how to communicate that a
> certificate is no longer valid ... because if a certificate were really no
> longer valid (as it should be) then no one would need to find a CRL
> to know about it.
> 
> Cheers,
> 
> Ed Gerck
> ______________________________________________________________________
> Dr.rer.nat. E. Gerck                                    [e-mail]
> 
> +-------------------------------------------------------------+
> + For information about the cert-talk mailing list, including +
> + archives and how to subscribe and unsubscribe, visit:       +
> +          http://www.structuredarts.com/cert-talk            +
> +-------------------------------------------------------------+

-- 
Kelly D. Lucas            |  Kroll-O'Gara
Security Consultant       |  Information Security Group
[e-mail]          |  650-812-9400 x 117
"Any opinions that I state are my own, and not Kroll-O'Gara's"


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA01287 for <[e-mail]>; Wed, 6 Oct 1999 16:26:51 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id QAA00912; Wed, 6 Oct 1999 16:28:17 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id QAA18295; Wed, 6 Oct 1999 16:27:47 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: FW: DER encoding of OPTIONAL sequences with nothing
Date: Wed, 6 Oct 1999 16:31:11 -0700
Message-ID: <016d01bf1052$e09b2590$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>

This is mainly a style issue. I prefer tagging anything that is
part of a choice, so that if, in the future, somebody else adds
another thing in there, they don't screw it up by mistake.

You are absolutely right - the tag isn't required.

Regards,
Ambarish

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


> -----Original Message-----
> From: Magnus Nystrom [mailto:[e-mail]]
> Sent: Monday, October 04, 1999 11:58 PM
> To: Ambarish Malpani
> Cc: [e-mail]
> Subject: Re: FW: DER encoding of OPTIONAL sequences with nothing
> 
> 
> 
> Hi Ambarish,
> 
> On Mon, 4 Oct 1999, Ambarish Malpani wrote:
> 
> [...] 
> > but do them as:
> > 
> >  Top ::= SEQUENCE {
> >      i    INTEGER,
> >      something [0] EXPLICIT SEQUENCE SIZE (1..MAX) OF Foo OPTIONAL
> >  }
> 
> But why the [0] EXPLICIT? The tags (INTEGER, SEQUENCE) are 
> unique anyway.
> 
> -- Magnus
> Magnus Nystrom		Email: [e-mail]
> RSA Laboratories
> 


Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA25171 for <[e-mail]>; Wed, 6 Oct 1999 10:56:48 -0700 (PDT)
Received: by dfssl with Internet Mail Service (5.5.2650.21) id <426V2RL1>; Wed, 6 Oct 1999 10:57:42 -0700
Message-ID: <EAB5B8B61A04684198FF1D0C1B3ACD194A7037@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-dhpop-02.txt
Date: Wed, 6 Oct 1999 10:57:33 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

This draft was re-released for techinical reasons.  We have updated Appendix
B so that is now uses the Q parameter on the big-number for DH and DSS.
This is to bring it into line with RFC2459.  No other changes have been
made.

jim


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, October 06, 1999 3:56 AM
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dhpop-02.txt


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

	Title		: Diffie-Hellman Proof-of-Possession Algorithms
	Author(s)	: H. Prafullchandra, J. Schaad
	Filename	: draft-ietf-pkix-dhpop-02.txt
	Pages		: 21
	Date		: 05-Oct-99
	
This document describes two methods for producing a signature from a
Diffie-Hellman key pair.  This behavior is needed for such
operations as creating a signature of a PKCS #10 certification
request.  These algorithms are designed to provide a proof-of-
possession rather than general purpose signing.

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

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

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


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

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



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA11502 for <[e-mail]>; Wed, 6 Oct 1999 03:54:51 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01049; Wed, 6 Oct 1999 06:55:44 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dhpop-02.txt
Date: Wed, 06 Oct 1999 06:55:44 -0400
Sender: [e-mail]

--NextPart

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

	Title		: Diffie-Hellman Proof-of-Possession Algorithms
	Author(s)	: H. Prafullchandra, J. Schaad
	Filename	: draft-ietf-pkix-dhpop-02.txt
	Pages		: 21
	Date		: 05-Oct-99
	
This document describes two methods for producing a signature from a
Diffie-Hellman key pair.  This behavior is needed for such
operations as creating a signature of a PKCS #10 certification
request.  These algorithms are designed to provide a proof-of-
possession rather than general purpose signing.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dhpop-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from getafix.fcpl.co.in (getafix.fcpl.co.in [196.1.104.8]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id VAA29235 for <[e-mail]>; Tue, 5 Oct 1999 21:47:05 -0700 (PDT)
Received: from gate1 ([196.1.104.171]) by getafix.fcpl.co.in (post.office MTA v2.0 0613 ID# 291-17719) with SMTP id AAA64; Wed, 6 Oct 1999 10:23:05 +0530
Message-ID: <005701bf0fb6$d67639c0$[e-mail]>
From: "ani" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>, <[e-mail]>
Subject: Re: DER encoding of OPTIONAL sequences with nothing
Date: Wed, 6 Oct 1999 10:24:14 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

It is incorrect to say that this prevents 2 different DER encodings of a
*single object*. It is actually not a single object. The fact of an empty
SEQUENCE being present makes it a different object than the SEQUENCE being
absent. And DER, correctly, allows two different encodings to represent
these two data objects. It is worth noting that the the above two objects
could convey different meanings to the application looking at the encodings.

So, in general, there is nothing wrong with the first ASN.1 definition. The
ASN.1 toolset which an application developer uses should have the ability to
allow the developer to represent these two objects separately. For example,
if the toolset generates equivalent 'C' structures, the generated 'C'
structure should have a provision for specifying the empty SEQUENCE and an
absent SEQUENCE differently.

As an aside, another way of "disambiguating" the ASN.1 structure is to write
it as:

Top ::= SEQUENCE {
    i    INTEGER,
    something [0] EXPLICIT SEQUENCE OF Foo
}


Of course, as Magnus Nystrom put it, all the above arguments would hold even
if [0] EXPLICIT was not present.

Regards,

Ani

-------------------------------------------
Aniruddha P. Shrotri (ani)
VP, Software Development, E-Lock Technologies Inc.
[e-mail]
http://www.elock.com
-------------------------------------------

----- Original Message -----
From: Ambarish Malpani <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, October 05, 1999 12:21 AM
Subject: FW: DER encoding of OPTIONAL sequences with nothing


>
> Hi PKIX-land,
>     Just learnt something of the ASN.1 mailing list that I
> think will be of general interest.
>
> In a nutshell, try not to have definitions like:
>
>  Top ::= SEQUENCE {
>      i    INTEGER,
>      something [0] EXPLICIT SEQUENCE OF Foo OPTIONAL
>  }
>
> but do them as:
>
>  Top ::= SEQUENCE {
>      i    INTEGER,
>      something [0] EXPLICIT SEQUENCE SIZE (1..MAX) OF Foo OPTIONAL
>  }
>
>
> This prevents you from allowing 2 different DER encodings of a
> single object.
>
> Please ignore the mail if this was obvious.
>
> Regards,
> Ambarish
>
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of Ambarish Malpani
> > Sent: Monday, October 04, 1999 10:35 AM
> > To: [e-mail]
> > Subject: RE: DER encoding of OPTIONAL sequences with nothing
> >
> >
> >
> > Hi John,
> >     Okay, that clarifies the issue.
> >
> > Next time, I will make sure I specify top as:
> >
> > Top ::= SEQUENCE {
> >     i    INTEGER,
> >     something [0] EXPLICIT SEQUENCE SIZE (1..MAX) OF Foo OPTIONAL
> > }
> >
> > Some people do it this way and I had never figured out why.
> >
> > Thanks,
> > Ambarish
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                650.567.5457
> > ValiCert, Inc.                                  [e-mail]
> > 1215 Terra Bella Ave.                         http://www.valicert.com
> > Mountain View, CA 94043-1833
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]On Behalf Of John Larmouth
> > > Sent: Saturday, October 02, 1999 3:20 AM
> > > To: [e-mail]
> > > Subject: Re: DER encoding of OPTIONAL sequences with nothing
> > >
> > >
> > > I am afraid we need to discuss angels on pin-heads here!
> > The issue is
> > > the set of abstract values in Top.  DER guarantees a unique
> > > encoding for
> > > each separate abstract value,  but equally an application can put
> > > different semantics on different abstract values,  so all abstract
> > > values in the type have to have different endcodings.
> > >
> > > In the case of an OPTIONAL element (or whatever type),  ASN.1
> > > takes the
> > > view that a SEQUENCE value with an OPTIONAL element present is a
> > > different abstract value (carries different semantics) from
> > > one where it
> > > is absent.
> > >
> > > This is quite clearly correct in the general case.  It just looks a
> > > little funny in the case that you quote!
> > >
> > > So the principle is that a value of Top with something missing is a
> > > distinct abstract value (and may carry different semantics)
> > > from a value
> > > with something present as an empty sequence of.  DER
> > therefore allows
> > > (has to allow) different encodings for the two cases.
> > >
> > > John L
> > >
> > >
> > > Ambarish Malpani wrote:
> > > >
> > > > Hi Guys,
> > > >     A question was raised in the IETF PKIX working group that
> > > > would benefit from some input from this group.
> > > >
> > > > If I define
> > > >
> > > > Top ::= SEQUENCE {
> > > >     i    INTEGER,
> > > >     something [0] EXPLICIT SEQUENCE OF Foo OPTIONAL
> > > > }
> > > >
> > > > And I am trying to do a DER encoding of a top, where the
> > > > something contains no Foo's, is the right encoding to not put any
> > > > bytes, or to encode it as a tag 0, length 2, and sequence
> > > > of length 0?
> > > >
> > > > Is this a bug in the DER encoding rules (which promise a unique
> > > > encoding), or is the correct encoding specified in the rules?
> > > >
> > > > Regards,
> > > > Ambarish
> > > >
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > Ambarish Malpani
> > > > Architect
> > > 650.567.5457
> > > > ValiCert, Inc.
> > > [e-mail]
> > > > 1215 Terra Bella Ave.
> > http://www.valicert.com
> > > Mountain View, CA 94043-1833
> >
> > --
> > ==============================================================
> > ==========
> >                           Prof John Larmouth
> >    1 Blueberry Road,  Bowdon,  Altrincham,  Cheshire WA14
> > 3LS,  England.
> >      j.larmouth @ salford.ac.uk              Tel: [phone]
> >         Fax (work): [phone]  Tel (work): [phone]
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - - -
> >
> >




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.imc.org (8.9.3/8.9.3) with SMTP id PAA14162 for <[e-mail]>; Tue, 5 Oct 1999 15:38:19 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 05 Oct 1999 16:39:09 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Tue, 05 Oct 1999 16:38:58 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Nationality / country of citizenship attribute question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.imc.org id PAA14163

I could translate it for you, but then I'd have to shoot you. :-)

>>> Peter Gutmann <[e-mail]> 10/06/99 10:48AM >>>
[e-mail] writes:

>MIIj6QYJKoZIhvcNAQcCoIIj2jCCI9YCAQExCzAJBgUrDgMCGgUAMIIXiAYJKoZIhvcNAQcBoIIX
>eQSCF3VGcm9tOiBCSlVFTkVNQU5Abm92ZWxsLmNvbQ0KU3ViamVjdDogUmFN0RdhdGlvbmFsaXR5
>IC8gY291bnRyeSBvZiBjaXRpemVuc2hpcCBhdHRyaWJ1dGUgcXVlc3Rpb24NClRvOiAic2FtaWts
>b0BtaXNzaS5uY3NjLm1pbCIsIGlldGYtcGtpeEBpbDRinKCoCAcOlA50ZW50LVR5cGU6IG11bHRp
>cGFydC9taXhlZDsgYm91bmRhcnk9Il9fX19GVldIWlpLQ0VCTFlUQ0FFRkZBWV9

JvdXQgaXQsIHlvJlIGFyZSByZWFsbHkgdHdvIHF1ZXN0a.  ZSB0b28gbWFueSBleGNlcHRpb25zI
GNhdXNlIG - BhIGhvc3BpdGFsLCBiZSBhIG.  YXBhY2l0eT8iDQoNClRoZSBFbnRlcnByaXNlIE
lEIGlzIHV?

>LS1fX19fRlZXSFpaS0NFQkxZVENBRUZGQVlfX19fDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47
>IGNoFNOrDXQ9aXNvLTg4NTktMQ0KQ29udGVudC1UcmFuc2Zlci1FnoRdZGluZzogcXVvdGVkLXBy
>aW50YWJsZQ0KDQpTYW5keSwNCg0KUmVnYXJkaW5nIHRoZSBlbXBsb3ltZW50IHN0YXR1cyBhbmQg
>c2ltaWxhciBpc3N1ZXMgcmVsYXRlZCB0byAicmlnaH

BwYXRoIG9mID0NCmRlcGVuZGl!!!

>b2YgdGhlIEVudGVycHJpc2UgSUQgYXMgdXNlZCBpbiB0aGUgTm92ZWxsIFNlY3VyaXR5ID0NCkF0
>dHJpYnV

RzIiwgPQ0KY2hlY2sgb3V0IHRoZSB1c2Ug.  wZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJ
pYnV0, 0ZXMgKGh0dHA6Ly9kZXZlbG9.

>ZXMvY2VydGF0dHJzX3YxMD0NCi5odG0pLiA9MjANCg0KVGhlcmUgYXJlIGxvdHMgb2YgcG9zc2li
>bGUgYWIloVewINDowS4gcmVsYXRpb25zaGlwcyB0aGF0IG1pZ2h0IGV2ZW50dWFsbHkgPQ0KaGF2
>ZSB0byBiZSBleHByZXNzZWQuICBFbXBsb3ltZW50IGl

YmNvbnRyYWN0b3Igd29ya2luZ, zIG1lcmVseSBvbmUgb2YgdGhlbS4gIHNv, N1cml0eSBndWFyZ
CwgY2FmZXRlcmlhIHdvcmtlciwgdHJhdmVsIGFnZW5je.  gdGhlID0NClVuaXRlZCBTdGF0ZXMuI
CBXaGVu.

iB5b3UgdG,
Peter.




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.imc.org (8.9.3/8.9.3) with SMTP id OAA13432 for <[e-mail]>; Tue, 5 Oct 1999 14:50:51 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 05 Oct 1999 15:51:41 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Tue, 05 Oct 1999 15:51:36 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Bob Jueneman" <[e-mail]>
Subject: Re: Nationality / country of citizenship attribute question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.imc.org id OAA13433

I inadvertently clicked on the "sign" button, and compounded the 
problem because my default was set for base64 encoding.

Here is the message unencumbered, for those who are 
S/MIME challenged.

Bob


>>> <[e-mail]> 10/05/99 03:12PM >>>
Sandy,

Regarding the employment status and similar issues related to "rights", 
check out the use of the Enterprise ID as used in the Novell Security Attributes (http://developer.novell.com/repository/attributes/certattrs_v10.htm).  

There are lots of possible affiliation relationships that might eventually 
have to be expressed.  Employment is merely one of them.  Someone 
might be a visiting professor, have staff privileges at a hospital, be a 
contract or contingent worker, a subcontractor working on the 
premises (such as a security guard, cafeteria worker, travel agency employee).

So there are really two questions that have to be answered:  
(1) "Affiliated with whom?" and (2) "in what capacity?"

The Enterprise ID is unique to the given Enterprise, which 
answers the question "related to whom".

(If you think about it, you really don't want to go down the 
path of depending on the uniquely encoded name of the 
organization to represent the Enterprise -- there are too many 
exceptions cause by holding companies, Doing Business As 
and Trading As names, etc.  And that's just here in the 
United States.  When I was with GTE, for example, their 
corporate organization chart filled an 8-1/2x11 page with
blocks so small you could scarcely read the labels.  Because 
of state PUC requirements against cross-subsidization between 
states, every telephone company in every state was a 
separate corporation.)

(In  reality, most of the telco employees worked for say 
"GTE of Pennsylvania".  A relatively small number worked 
for the GTE Corporate staff, which had a "Group" (really an 
OU) called "GTE Telephone Operations".  Yet almost 
everyone who worked for the telephone side of the 
business had a business card that identified them as
 been "employed(?)" by "GTE Telephone Operations"
Is that sufficiently confusing? )

(The point is that the legal NAME of some organizations 
may be subject to legal and intellectual property constraints 
that aren't particularly meaningful or useful in answering 
other kinds of questions.  And I haven't even brought up the 
issue of multinational companies that have different legal 
names depending on what country they are operating in, or 
even dual or multiple names, as in Canada, Belgium, or 
(worst case) India, with 14 official languages and who 
knows how many dialects.)

The other bits in the Enterprise label, either at the 
Registry level or the Enterprise level, can answer 
the question of capacity, in the form of secrecy and 
integrity (read and write) levels and categories.]

If you stop to think about it, citizenship is merely another t
ype of affiliation.  It's really a pretty blunt instrument -- 
the real question is one of loyalty and national interest, 
not citizenship. But there is no reason in principle why 
the same type of encoding scheme could not be used.  
The Enterprise that one is affiliated with is a country, and 
the affiliation could take multiple forms -- citizen, permanent 
resident, student or work visa, temporary visitor, etc.

Bob

>>> "Miklos, Sue A." <[e-mail]> 10/01/99 12:51PM >>>

All, 
I have a requirement for an attribute to represent nationality (country of citizenship) with two constraining factors.  First, it must be multi-valued, as many nations permit dual-citizenship and second, it must be extensible to use the ISO-3166-1 trigraphs.  
Several multinational security policies expressly state that the Release To fields contain, in alphabetical order, a trigraph indication of those countries to which the information may be released.
I have looked at the nationality attribute in ACP 133 as well as the countryOfCitizenship attribute in the Qualified Certificates. They are both single valued and constrained to digraph usage only.
I would ask assistance in either modifying the existing attributes, or, creating (yet another) new one.  
Additionally, I have a requirement for an attribute that can represent the employment status of a given individual.  While initially thinking that a bit map would work, I quickly realized that although that would support access control processing more easily, it is not extensible.  I would like to propose a new attribute type that is (short sighted?) single valued and a Directory string, that indicates the status of one's employment.  For example, it woould contain a corporate name or country government affiliation.
Sandi Miklos 


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA13253 for <[e-mail]>; Tue, 5 Oct 1999 14:47:24 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id KAA13807 for <[e-mail]>; Wed, 6 Oct 1999 10:48:42 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <93916012115024>; Wed, 6 Oct 1999 10:48:41 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Nationality / country of citizenship attribute question
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 6 Oct 1999 10:48:41 (NZDT)
Message-ID: <[e-mail]>

[e-mail] writes:

>MIIj6QYJKoZIhvcNAQcCoIIj2jCCI9YCAQExCzAJBgUrDgMCGgUAMIIXiAYJKoZIhvcNAQcBoIIX
>eQSCF3VGcm9tOiBCSlVFTkVNQU5Abm92ZWxsLmNvbQ0KU3ViamVjdDogUmFN0RdhdGlvbmFsaXR5
>IC8gY291bnRyeSBvZiBjaXRpemVuc2hpcCBhdHRyaWJ1dGUgcXVlc3Rpb24NClRvOiAic2FtaWts
>b0BtaXNzaS5uY3NjLm1pbCIsIGlldGYtcGtpeEBpbDRinKCoCAcOlA50ZW50LVR5cGU6IG11bHRp
>cGFydC9taXhlZDsgYm91bmRhcnk9Il9fX19GVldIWlpLQ0VCTFlUQ0FFRkZBWV9

JvdXQgaXQsIHlvJlIGFyZSByZWFsbHkgdHdvIHF1ZXN0a.  ZSB0b28gbWFueSBleGNlcHRpb25zI
GNhdXNlIG - BhIGhvc3BpdGFsLCBiZSBhIG.  YXBhY2l0eT8iDQoNClRoZSBFbnRlcnByaXNlIE
lEIGlzIHV?

>LS1fX19fRlZXSFpaS0NFQkxZVENBRUZGQVlfX19fDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47
>IGNoFNOrDXQ9aXNvLTg4NTktMQ0KQ29udGVudC1UcmFuc2Zlci1FnoRdZGluZzogcXVvdGVkLXBy
>aW50YWJsZQ0KDQpTYW5keSwNCg0KUmVnYXJkaW5nIHRoZSBlbXBsb3ltZW50IHN0YXR1cyBhbmQg
>c2ltaWxhciBpc3N1ZXMgcmVsYXRlZCB0byAicmlnaH

BwYXRoIG9mID0NCmRlcGVuZGl!!!

>b2YgdGhlIEVudGVycHJpc2UgSUQgYXMgdXNlZCBpbiB0aGUgTm92ZWxsIFNlY3VyaXR5ID0NCkF0
>dHJpYnV

RzIiwgPQ0KY2hlY2sgb3V0IHRoZSB1c2Ug.  wZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJ
pYnV0, 0ZXMgKGh0dHA6Ly9kZXZlbG9.

>ZXMvY2VydGF0dHJzX3YxMD0NCi5odG0pLiA9MjANCg0KVGhlcmUgYXJlIGxvdHMgb2YgcG9zc2li
>bGUgYWIloVewINDowS4gcmVsYXRpb25zaGlwcyB0aGF0IG1pZ2h0IGV2ZW50dWFsbHkgPQ0KaGF2
>ZSB0byBiZSBleHByZXNzZWQuICBFbXBsb3ltZW50IGl

YmNvbnRyYWN0b3Igd29ya2luZ, zIG1lcmVseSBvbmUgb2YgdGhlbS4gIHNv, N1cml0eSBndWFyZ
CwgY2FmZXRlcmlhIHdvcmtlciwgdHJhdmVsIGFnZW5je.  gdGhlID0NClVuaXRlZCBTdGF0ZXMuI
CBXaGVu.

iB5b3UgdG,
Peter.



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.imc.org (8.9.3/8.9.3) with SMTP id OAA12743 for <[e-mail]>; Tue, 5 Oct 1999 14:12:14 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 05 Oct 1999 15:13:03 -0600
Mime-Version: 1.0
Date: Tue, 5 Oct 1999 15:12:00 -0600
X-Mailer: Groupwise 5.5.2.1
Subject: Re: Nationality / country of citizenship attribute question
To: "[e-mail]", [e-mail]
Content-Type: application/x-pkcs7-mime; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"; modification-date="Tue, 5 Oct 1999 15:12:38 -0600"

MIIj6QYJKoZIhvcNAQcCoIIj2jCCI9YCAQExCzAJBgUrDgMCGgUAMIIXiAYJKoZIhvcNAQcBoIIX
eQSCF3VGcm9tOiBCSlVFTkVNQU5Abm92ZWxsLmNvbQ0KU3ViamVjdDogUmU6IE5hdGlvbmFsaXR5
IC8gY291bnRyeSBvZiBjaXRpemVuc2hpcCBhdHRyaWJ1dGUgcXVlc3Rpb24NClRvOiAic2FtaWts
b0BtaXNzaS5uY3NjLm1pbCIsIGlldGYtcGtpeEBpbWMub3JnDQpDb250ZW50LVR5cGU6IG11bHRp
cGFydC9taXhlZDsgYm91bmRhcnk9Il9fX19GVldIWlpLQ0VCTFlUQ0FFRkZBWV9fX18iDQoNCg0K
LS1fX19fRlZXSFpaS0NFQkxZVENBRUZGQVlfX19fDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47
IGNoYXJzZXQ9aXNvLTg4NTktMQ0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXBy
aW50YWJsZQ0KDQpTYW5keSwNCg0KUmVnYXJkaW5nIHRoZSBlbXBsb3ltZW50IHN0YXR1cyBhbmQg
c2ltaWxhciBpc3N1ZXMgcmVsYXRlZCB0byAicmlnaHRzIiwgPQ0KY2hlY2sgb3V0IHRoZSB1c2Ug
b2YgdGhlIEVudGVycHJpc2UgSUQgYXMgdXNlZCBpbiB0aGUgTm92ZWxsIFNlY3VyaXR5ID0NCkF0
dHJpYnV0ZXMgKGh0dHA6Ly9kZXZlbG9wZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJpYnV0
ZXMvY2VydGF0dHJzX3YxMD0NCi5odG0pLiA9MjANCg0KVGhlcmUgYXJlIGxvdHMgb2YgcG9zc2li
bGUgYWZmaWxpYXRpb24gcmVsYXRpb25zaGlwcyB0aGF0IG1pZ2h0IGV2ZW50dWFsbHkgPQ0KaGF2
ZSB0byBiZSBleHByZXNzZWQuICBFbXBsb3ltZW50IGlzIG1lcmVseSBvbmUgb2YgdGhlbS4gIHNv
bWVvbmUgbWlnaHQgYmUgPQ0KYSB2aXNpdGluZyBwcm9mZXNzb3IsIGhhdmUgc3RhZmYgcHJpdmls
ZWdlcyBhdCBhIGhvc3BpdGFsLCBiZSBhIGNvbnRyYWN0ID0NCm9yIGNvbnRpbmdlbnQgd29ya2Vy
LCBhIHN1YmNvbnRyYWN0b3Igd29ya2luZyBvbiB0aGUgcHJlbWlzZXMgKHN1Y2ggYXMgYSA9DQpz
ZWN1cml0eSBndWFyZCwgY2FmZXRlcmlhIHdvcmtlciwgdHJhdmVsIGFnZW5jeSBlbXBsb3llZSku
DQoNClNvIHRoZXJlIGFyZSByZWFsbHkgdHdvIHF1ZXN0aW9ucyB0aGF0IGhhdmUgdG8gYmUgYW5z
d2VyZWQ6ICAoMSkgIkFmZmlsaWF0ZT0NCmQgd2l0aCB3aG9tPyIgYW5kICgyKSAiaW4gd2hhdCBj
YXBhY2l0eT8iDQoNClRoZSBFbnRlcnByaXNlIElEIGlzIHVuaXF1ZSB0byB0aGUgZ2l2ZW4gRW50
ZXJwcmlzZSwgd2hpY2ggYW5zd2VycyB0aGUgPQ0KcXVlc3Rpb24gInJlbGF0ZWQgdG8gd2hvbSIu
DQoNCihJZiB5b3UgdGhpbmsgYWJvdXQgaXQsIHlvdSByZWFsbHkgZG9uJ3Qgd2FudCB0byBnbyBk
b3duIHRoZSBwYXRoIG9mID0NCmRlcGVuZGluZyBvbiB0aGUgdW5pcXVlbHkgZW5jb2RlZCBuYW1l
IG9mIHRoZSBvcmdhbml6YXRpb24gdG8gcmVwcmVzZW50ID0NCnRoZSBFbnRlcnByaXNlIC0tIHRo
ZXJlIGFyZSB0b28gbWFueSBleGNlcHRpb25zIGNhdXNlIGJ5IGhvbGRpbmcgY29tcGFuaWVzLD0N
CiBEb2luZyBCdXNpbmVzcyBBcyBhbmQgVHJhZGluZyBBcyBuYW1lcywgZXRjLiAgQW5kIHRoYXQn
cyBqdXN0IGhlcmUgaW4gdGhlID0NClVuaXRlZCBTdGF0ZXMuICBXaGVuIEkgd2FzIHdpdGggR1RF
LCBmb3IgZXhhbXBsZSwgdGhlaXIgY29ycG9yYXRlID0NCm9yZ2FuaXphdGlvbiBjaGFydCBmaWxs
ZWQgYW4gOC0xLzJ4MTEgcGFnZSB3aXRoIGJsb2NrcyBzbyBzbWFsbCB5b3UgY291bGQgPQ0Kc2Nh
cmNlbHkgcmVhZCB0aGUgbGFiZWxzLiAgQmVjYXVzZSBvZiBzdGF0ZSBQVUMgcmVxdWlyZW1lbnRz
IGFnYWluc3QgPQ0KY3Jvc3Mtc3Vic2lkaXphdGlvbiBiZXR3ZWVuIHN0YXRlcywgZXZlcnkgdGVs
ZXBob25lIGNvbXBhbnkgaW4gZXZlcnkgc3RhdGUgPQ0Kd2FzIGEgc2VwYXJhdGUgY29ycG9yYXRp
b24uKQ0KDQooSW4gIHJlYWxpdHksIG1vc3Qgb2YgdGhlIHRlbGNvIGVtcGxveWVlcyB3b3JrZWQg
Zm9yIHNheSAiR1RFIG9mIFBlbm5zeWx2YW49DQppYSIuICBBIHJlbGF0aXZlbHkgc21hbGwgbnVt
YmVyIHdvcmtlZCBmb3IgdGhlIEdURSBDb3Jwb3JhdGUgc3RhZmYsIHdoaWNoID0NCmhhZCBhICJH
cm91cCIgKHJlYWxseSBhbiBPVSkgY2FsbGVkICJHVEUgVGVsZXBob25lIE9wZXJhdGlvbnMiLiAg
WWV0ID0NCmFsbW9zdCBldmVyeW9uZSB3aG8gd29ya2VkIGZvciB0aGUgdGVsZXBob25lIHNpZGUg
b2YgdGhlIGJ1c2luZXNzIGhhZCBhID0NCmJ1c2luZXNzIGNhcmQgdGhhdCBpZGVudGlmaWVkIHRo
ZW0gYXMgYmVlbiAiZW1wbG95ZWQoPykiIGJ5ICJHVEUgVGVsZXBob25lID0NCk9wZXJhdGlvbnMi
DQpJcyB0aGF0IHN1ZmZpY2llbnRseSBjb25mdXNpbmc/ICkNCg0KKFRoZSBwb2ludCBpcyB0aGF0
IHRoZSBsZWdhbCBOQU1FIG9mIHNvbWUgb3JnYW5pemF0aW9ucyBtYXkgYmUgc3ViamVjdCB0byA9
DQpsZWdhbCBhbmQgaW50ZWxsZWN0dWFsIHByb3BlcnR5IGNvbnN0cmFpbnRzIHRoYXQgYXJlbid0
IHBhcnRpY3VsYXJseSA9DQptZWFuaW5nZnVsIG9yIHVzZWZ1bCBpbiBhbnN3ZXJpbmcgb3RoZXIg
a2luZHMgb2YgcXVlc3Rpb25zLiAgQW5kIEkgaGF2ZW4ndCA9DQpldmVuIGJyb3VnaHQgdXAgdGhl
IGlzc3VlIG9mIG11bHRpbmF0aW9uYWwgY29tcGFuaWVzIHRoYXQgaGF2ZSBkaWZmZXJlbnQgPQ0K
bGVnYWwgbmFtZXMgZGVwZW5kaW5nIG9uIHdoYXQgY291bnRyeSB0aGV5IGFyZSBvcGVyYXRpbmcg
aW4sIG9yIGV2ZW4gZHVhbCA9DQpvciBtdWx0aXBsZSBuYW1lcywgYXMgaW4gQ2FuYWRhLCBCZWxn
aXVtLCBvciAod29yc3QgY2FzZSkgSW5kaWEsIHdpdGggMTQgPQ0Kb2ZmaWNpYWwgbGFuZ3VhZ2Vz
IGFuZCB3aG8ga25vd3MgaG93IG1hbnkgZGlhbGVjdHMuKQ0KDQpUaGUgb3RoZXIgYml0cyBpbiB0
aGUgRW50ZXJwcmlzZSBsYWJlbCwgZWl0aGVyIGF0IHRoZSBSZWdpc3RyeSBsZXZlbCBvciA9DQp0
aGUgRW50ZXJwcmlzZSBsZXZlbCwgY2FuIGFuc3dlciB0aGUgcXVlc3Rpb24gb2YgY2FwYWNpdHks
IGluIHRoZSBmb3JtIG9mID0NCnNlY3JlY3kgYW5kIGludGVncml0eSAocmVhZCBhbmQgd3JpdGUp
IGxldmVscyBhbmQgY2F0ZWdvcmllcy5dDQoNCklmIHlvdSBzdG9wIHRvIHRoaW5rIGFib3V0IGl0
LCBjaXRpemVuc2hpcCBpcyBtZXJlbHkgYW5vdGhlciB0eXBlIG9mID0NCmFmZmlsaWF0aW9uLiAg
SXQncyByZWFsbHkgYSBwcmV0dHkgYmx1bnQgaW5zdHJ1bWVudCAtLSB0aGUgcmVhbCBxdWVzdGlv
biA9DQppcyBvbmUgb2YgbG95YWx0eSBhbmQgbmF0aW9uYWwgaW50ZXJlc3QsIG5vdCBjaXRpemVu
c2hpcC4gQnV0IHRoZXJlIGlzIG5vID0NCnJlYXNvbiBpbiBwcmluY2lwbGUgd2h5IHRoZSBzYW1l
IHR5cGUgb2YgZW5jb2Rpbmcgc2NoZW1lIGNvdWxkIG5vdCBiZSA9DQp1c2VkLiAgVGhlIEVudGVy
cHJpc2UgdGhhdCBvbmUgaXMgYWZmaWxpYXRlZCB3aXRoIGlzIGEgY291bnRyeSwgYW5kIHRoZSA9
DQphZmZpbGlhdGlvbiBjb3VsZCB0YWtlIG11bHRpcGxlIGZvcm1zIC0tIGNpdGl6ZW4sIHBlcm1h
bmVudCByZXNpZGVudCwgPQ0Kc3R1ZGVudCBvciB3b3JrIHZpc2EsIHRlbXBvcmFyeSB2aXNpdG9y
LCBldGMuDQoNCkJvYg0KDQo+Pj4gIk1pa2xvcywgU3VlIEEuIiA8c2FtaWtsb0BtaXNzaS5uY3Nj
Lm1pbD4gMTAvMDEvOTkgMTI6NTFQTSA+Pj4NCg0KQWxsLD0yMA0KSSBoYXZlIGEgcmVxdWlyZW1l
bnQgZm9yIGFuIGF0dHJpYnV0ZSB0byByZXByZXNlbnQgbmF0aW9uYWxpdHkgKGNvdW50cnkgb2Yg
PQ0KY2l0aXplbnNoaXApIHdpdGggdHdvIGNvbnN0cmFpbmluZyBmYWN0b3JzLiAgRmlyc3QsIGl0
IG11c3QgYmUgbXVsdGktdmFsdWVkPQ0KLCBhcyBtYW55IG5hdGlvbnMgcGVybWl0IGR1YWwtY2l0
aXplbnNoaXAgYW5kIHNlY29uZCwgaXQgbXVzdCBiZSBleHRlbnNpYmxlPQ0KIHRvIHVzZSB0aGUg
SVNPLTMxNjYtMSB0cmlncmFwaHMuID0yMA0KU2V2ZXJhbCBtdWx0aW5hdGlvbmFsIHNlY3VyaXR5
IHBvbGljaWVzIGV4cHJlc3NseSBzdGF0ZSB0aGF0IHRoZSBSZWxlYXNlID0NClRvIGZpZWxkcyBj
b250YWluLCBpbiBhbHBoYWJldGljYWwgb3JkZXIsIGEgdHJpZ3JhcGggaW5kaWNhdGlvbiBvZiB0
aG9zZSA9DQpjb3VudHJpZXMgdG8gd2hpY2ggdGhlIGluZm9ybWF0aW9uIG1heSBiZSByZWxlYXNl
ZC4NCkkgaGF2ZSBsb29rZWQgYXQgdGhlIG5hdGlvbmFsaXR5IGF0dHJpYnV0ZSBpbiBBQ1AgMTMz
IGFzIHdlbGwgYXMgdGhlID0NCmNvdW50cnlPZkNpdGl6ZW5zaGlwIGF0dHJpYnV0ZSBpbiB0aGUg
UXVhbGlmaWVkIENlcnRpZmljYXRlcy4gVGhleSBhcmUgPQ0KYm90aCBzaW5nbGUgdmFsdWVkIGFu
ZCBjb25zdHJhaW5lZCB0byBkaWdyYXBoIHVzYWdlIG9ubHkuDQpJIHdvdWxkIGFzayBhc3Npc3Rh
bmNlIGluIGVpdGhlciBtb2RpZnlpbmcgdGhlIGV4aXN0aW5nIGF0dHJpYnV0ZXMsIG9yLCA9DQpj
cmVhdGluZyAoeWV0IGFub3RoZXIpIG5ldyBvbmUuID0yMA0KQWRkaXRpb25hbGx5LCBJIGhhdmUg
YSByZXF1aXJlbWVudCBmb3IgYW4gYXR0cmlidXRlIHRoYXQgY2FuIHJlcHJlc2VudCB0aGUgPQ0K
ZW1wbG95bWVudCBzdGF0dXMgb2YgYSBnaXZlbiBpbmRpdmlkdWFsLiAgV2hpbGUgaW5pdGlhbGx5
IHRoaW5raW5nIHRoYXQgYSA9DQpiaXQgbWFwIHdvdWxkIHdvcmssIEkgcXVpY2tseSByZWFsaXpl
ZCB0aGF0IGFsdGhvdWdoIHRoYXQgd291bGQgc3VwcG9ydCA9DQphY2Nlc3MgY29udHJvbCBwcm9j
ZXNzaW5nIG1vcmUgZWFzaWx5LCBpdCBpcyBub3QgZXh0ZW5zaWJsZS4gIEkgd291bGQgbGlrZSA9
DQp0byBwcm9wb3NlIGEgbmV3IGF0dHJpYnV0ZSB0eXBlIHRoYXQgaXMgKHNob3J0IHNpZ2h0ZWQ/
KSBzaW5nbGUgdmFsdWVkIGFuZCA9DQphIERpcmVjdG9yeSBzdHJpbmcsIHRoYXQgaW5kaWNhdGVz
IHRoZSBzdGF0dXMgb2Ygb25lJ3MgZW1wbG95bWVudC4gIEZvciA9DQpleGFtcGxlLCBpdCB3b291
bGQgY29udGFpbiBhIGNvcnBvcmF0ZSBuYW1lIG9yIGNvdW50cnkgZ292ZXJubWVudCA9DQphZmZp
bGlhdGlvbi4NClNhbmRpIE1pa2xvcz0yMA0KDQotLV9fX19GVldIWlpLQ0VCTFlUQ0FFRkZBWV9f
X18NCkNvbnRlbnQtVHlwZTogdGV4dC94LXZjYXJkOyBjaGFyc2V0PXdpbmRvd3MtMTI1MjsgbmFt
ZT0iQm9iIEp1ZW5lbWFuLnZjZiINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1w
cmludGFibGUNCkNvbnRlbnQtRGlzcG9zaXRpb246IGF0dGFjaG1lbnQ7IGZpbGVuYW1lPSJCb2Ig
SnVlbmVtYW4udmNmIjsNCgltb2RpZmljYXRpb24tZGF0ZT0iVHVlLCA1IE9jdCAxOTk5IDE1OjEx
OjIwIC0wNjAwIg0KDQpCRUdJTjpWQ0FSRA0KVkVSU0lPTjoyLjENClgtR1dUWVBFOlVTRVINCkZO
OlJvYmVydCBSLiBKdWVuZW1hbg0KVEVMO1dPUks6ODAxLTg2MS03Mzg3DQpPUkc6Tm92ZWxsLCBJ
bmMuO05ldHdvcmsgU2VjdXJpdHkgRGV2ZWxvcG1lbnQNClRFTDtQUkVGO0ZBWDo4MDEtODYxLTI1
MjINCkVNQUlMO1dPUks7UFJFRjtOR1c6QkpVRU5FTUFOQG5vdmVsbC5jb20NCk46SnVlbmVtYW47
Qm9iDQpUSVRMRTpDb25zdWx0YW50IEVuZ2luZWVyDQpBRFI7SU5UTDtXT1JLO1BBUkNFTDtQT1NU
QUw6O1BSVi1GMzMxOzEyMiBFLiAxNzAwIFNvdXRoO1Byb3ZvO1V0YWg7ODQ2MDY7VVM9DQpBDQpM
QUJFTDtJTlRMO1dPUks7UEFSQ0VMO1BPU1RBTDtFTkNPRElORz0zRFFVT1RFRC1QUklOVEFCTEU6
Um9iZXJ0IFIuID0NCkp1ZW5lbWFuPTNEMEE9M0QNClBSVi1GMzMxPTNEMEE9M0QNCjEyMiBFLiAx
NzAwIFNvdXRoPTNEMEE9M0QNClByb3ZvLCBVdGFoICA4NDYwNj0zRDBBPTNEDQpVU0ENCkxBQkVM
O0RPTTtXT1JLO1BBUkNFTDtQT1NUQUw7RU5DT0RJTkc9M0RRVU9URUQtUFJJTlRBQkxFOlJvYmVy
dCBSLiA9DQpKdWVuZW1hbj0zRDBBPTNEDQpQUlYtRjMzMT0zRDBBPTNEDQoxMjIgRS4gMTcwMCBT
b3V0aD0zRDBBPTNEDQpQcm92bywgVXRhaCAgODQ2MDYNClRFTDtIT01FOjEtODAxLTc2NS00Mzc4
DQpURUw7Q0VMTDoxLTgwMS0zNjEtMTQxMA0KVEVMO1BSRUY6MS04MDEtODYxLTczODcsIDEtODAw
LTQ1My0xMjY3DQpYLUdXVVNFUklEOkJKVUVORU1BTg0KRU5EOlZDQVJEDQoNCg0KLS1fX19fRlZX
SFpaS0NFQkxZVENBRUZGQVlfX19fLS0NCqCCCpUwggU3MIIEH6ADAgECAhoCFAAAEkTN/Xy4aAyx
F/Pe3Fb2/LcuAgIICjANBgkqhkiG9w0BAQUFADBYMSEwHwYDVQQLFBhOTyBMSUFCSUxJVFkgLS0g
VEVTVCBDQSExHDAaBgNVBAsTE05vdmVsbCBFbXBsb3llZSAgQ0ExFTATBgNVBAoTDE5vdmVsbCwg
SW5jLjAeFw05OTA5MjMyMjUwMDBaFw0wMDA5MjMyMjUwMDBaMEIxEjAQBgNVBAMTCUJKVUVORU1B
TjENMAsGA1UECxMETlNSRDEMMAoGA1UECxMDUFJWMQ8wDQYDVQQKEwZub3ZlbGwwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDeUuuHUNzD5zUHoZJE9f1yMXh99Ulu/Ub4D9rzm2WUnrCM
axqlAct1UnAfcWe9m+6kOcqQofLMS7TrA2QA+t+EStjUQRfBx8JEprcrEJoZrQtVXGNGmMerJlul
4cmhpREOKdJrAxJFxjyCF2Cp5C/q/a2HXKL/peENLR48u9kFWuxFrEFfKLvCCPYuzzNL4CeSaxM5
w5tSnmx34RhGa90bhAjMJRIEdxD8mzeqUEig2bS/roGzKjH+4zMZDAn1NKyn8YRuoXP79VUbawMr
YgIGyvtklf3zTKUhvVYCVkEJJnm7viECBOa/YZd8aeGmFm2A+vhmfoySMOX5f23k/9B/AgMBAAGj
ggIHMIICAzAMBgNVHSMEBTADgAEBMCIGA1UdEQEBAAQYMBaBFEJKVUVORU1BTkBOb3ZlbGwuY29t
MIIBzQYLYIZIAYb4NwEJBAEBAQAEggG5MIIBtQQCAQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRy
aWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1
dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBRqAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEB
ADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpogYCARQBAf+jggECoFoCAQICAgD/AgEAAw0AgAAAAAAA
AAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBACAQACCH//////
////AQEAAgQG8N9IMFShVAIBAgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAWMBAC
AQACCH//////////AQEAAgISRDAWMBACAQACCH//////////AQEAAgISRKJOMEwCAQICAQACAgD/
Aw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwEjAQAgEAAgh//////////wEBADASMBACAQACCH//
////////AQEAMA0GCSqGSIb3DQEBBQUAA4IBAQAfKty8JoOhYhADVJJpQ9JQmxjYpXNMP2C8cOA7
n/58/SyhgtfAEkDCIbBiGKoMLM7308ZZbaX10P1AGriwZxiOtx4RWoo5knjqiI0UtC9IIa9YAb3A
qtxjf8Cx/rUzMzv5I2Nb1GvYdyHTBn+KTRKWyMvrS8GuwNawPks580F50MjGlAXtZEuRsPZDeI0w
Lf6+mMu8TjcwLNWFuHRj5sh6gl+aJzObs0oaHNjBr2NWS75B2Fyq5rXKd9L+hDux9+tMC3fE2pUY
psiC8ynYlsVhiZb8xLmRRLsTwuzgqS8jmiHJijay7JTobPt634e9uFA0JRHneYYgipqrElez6bqW
MIIFVjCCBD6gAwIBAgIaAhQAABJEzf18uGgMsRfz3txW9vy3LgICB/4wDQYJKoZIhvcNAQEFBQAw
WDEhMB8GA1UECxQYTk8gTElBQklMSVRZIC0tIFRFU1QgQ0EhMRwwGgYDVQQLExNOb3ZlbGwgRW1w
bG95ZWUgIENBMRUwEwYDVQQKEwxOb3ZlbGwsIEluYy4wHhcNOTkwOTIzMTg1MzAwWhcNMDEwOTIz
MTg1MzAwWjBYMSEwHwYDVQQLFBhOTyBMSUFCSUxJVFkgLS0gVEVTVCBDQSExHDAaBgNVBAsTE05v
dmVsbCBFbXBsb3llZSAgQ0ExFTATBgNVBAoTDE5vdmVsbCwgSW5jLjCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBANPQnhFoD1LtUs/RNwyLar4DI++lYdFF8eVS17Tihhb7tDaE0gnmHlpv
unsymvAv4BCir5miJJdu4/fyR+NXshblhOlqhuV4dGwnyv6G5wRnEyGH6Pf/JDOrTUVfE9vLgusz
DOncLsn6dbtip7OYpHMhm6sA/yziXe801MDWyjyS05jVfJ1W8/+kBB5hDgHV4jIxh8g44EGlmtOv
nRhcocECfTfXcAqsQNzgpOxyaZc+uXxIlV0qXg7dWOXIFW4BhkvNIPTg3URaSU6c/yM79sRG02Cj
Erg0WbQrB0c8cZBzP2tb3uAU3HfN65sExZYD7eoq1WsPWmbiZSU5w4iuI0kCAwEAAaOCAhAwggIM
MAoGA1UdDgQDBAEBMAwGA1UdIwQFMAOAAQEwDwYDVR0TAQEABAUwAwEB/zAOBgNVHQ8BAQAEBAMC
AQYwggHNBgtghkgBhvg3AQkEAQEBAASCAbkwggG1BAIBAAEB/xMdTm92ZWxsIFNlY3VyaXR5IEF0
dHJpYnV0ZSh0bSkWQ2h0dHA6Ly9kZXZlbG9wZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJp
YnV0ZXMvY2VydGF0dHJzX3YxMC5odG0wggFGoBoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaEa
AQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmiBgIBGAEB/6OCAQKgWgIBAgICAP8CAQADDQCAAAAA
AAAAAAAAAAADCQCAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQG8N9IMBgwEAIBAAIIf///
//////8BAQACBAbw30gwVKFUAgECAgIA/wIBAAMNAEAAAAAAAAAAAAAAAAMJAEAAAAAAAAAAMBYw
EAIBAAIIf/////////8BAQACAhJEMBYwEAIBAAIIf/////////8BAQACAhJEok4wTAIBAgICAP8C
AQADDQCA//////////////8DCQCA/////////zASMBACAQACCH//////////AQH/MBIwEAIBAAII
f/////////8BAf8wDQYJKoZIhvcNAQEFBQADggEBACC04Ku0rSXsknWxF9nF4rYTFBimeE6ypXlz
fNvVPCsEdBbPHHpG7Glnw83ZRQ2qW0qMvFUtI95Dh4xvz0ZTSsmxmMYiJ4MVVTYZI78mx1AJL02I
SO7V7M+829d7ivPdjns0/3lzsKj+hg8//eBnV+MdKiFtt7/PHtLszsBRF7CqlkdCoujSpNY9o9Tz
8G8YYGqPuY/MqL48b8mNURjq1qQNojH6Lp4+V7cqTB5oTHWdCN4gr6rKI+npWQhk0nE2eVqkIIp7
xJTSMlAiQOs+MfpIBxAjZ8fAT1BiHjx0iZyxumeNlnpgItvQzHcPH0IxL/UBlntFl9W1ZgUKpBGi
QJQxggGdMIIBmQIBATB2MFgxITAfBgNVBAsUGE5PIExJQUJJTElUWSAtLSBURVNUIENBITEcMBoG
A1UECxMTTm92ZWxsIEVtcGxveWVlICBDQTEVMBMGA1UEChMMTm92ZWxsLCBJbmMuAhoCFAAAEkTN
/Xy4aAyxF/Pe3Fb2/LcuAgIICjAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIIBABIXw2DD+5tY
7h+sG8uS1qj5sZcRIuJIP5d+E9PxnVIT8CtxCO1cAJl1SbG3fADSSxwNSaCUGu8Z+6RdWS6csA6y
hkGdRG1plxFThak5e8duuj2ByJEbgB/erxXX5dJ593zQAj8G3cKCGkVQLMFVQi7CRtyFZTTPiJEc
6GYcR6ZFlj3v6ouJqjJVs1deJZc9irIe9Zm5F1z5pIPiYIBNCjPgkmMHSF35thp1DEJsSCriZejC
kZE88W81qa5hBPmSZVqIHCOBJI5kgxylEf8Qe5zqHtjdRVi9+d4W1EjG35RVefpBM3NQZc//r2xr
p9/pkIQd4m+DBqxSEPWK7yz7OQE=


Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.imc.org (8.9.3/8.9.3) with SMTP id IAA08409 for <[e-mail]>; Tue, 5 Oct 1999 08:34:41 -0700 (PDT)
Received: 	id LAA03527; Tue, 5 Oct 1999 11:32:28 -0400
Received: by gateway id <TXM3R9F9>; Tue, 5 Oct 1999 11:35:08 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Phillip M Hallam-Baker'" <[e-mail]>
Cc: Trevor Freeman <[e-mail]>, "Pkix List (E-mail)" <[e-mail]>
Subject: RE: Delta CRL Distribution Points
Date: Tue, 5 Oct 1999 11:35:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Hi Phill,

> ----------
> From: 	Phillip M Hallam-Baker[SMTP:[e-mail]]
> Sent: 	Thursday, September 30, 1999 11:24 AM
> To: 	Trevor Freeman; Pkix List (E-mail)
> Subject: 	RE: Delta CRL Distribution Points
> 
> As I said earlier, delta CRLs are problematic and managing them is
> intrinsically complex. Scope CRLs offer considerably more flexibility,
> are intrinsically simpler and in many cases address the same need.
 
I don't understand your comment that deltas are problematic and that
managing them is intrinsically complex.  Perhaps it stems from your earlier
comment:

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

In practice, there are not "multiple signed documents ... that must be
combined to validate a certificate".  There's no real combining going on.  I
have a base cached on my local system and I want to check an incoming
certificate.  I retrieve the latest delta.  Is the cert serial number on the
base?  (Yes or No.)  If not, is it on the delta?  (Yes or No.)

Conceptually, you can think of the relying party combining the base and
delta into a single larger CRL and checking that, but in actual code nobody
needs to combine these things at all.  A sequential check of the two lists
is sufficient.  Checking two lists instead of one does not seem to me to be
inherently "problematic" or an "intrinsically complex" management task.

What have I missed?

Carlisle.

P.S., Scopes are great, and offer wonderful flexibility.  But do they really
help with the timeliness issue (which is where deltas are particularly
intended to be useful)?  In other words, do scopes and deltas really address
the same need in many cases?



Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by mail.imc.org (8.9.3/8.9.3) with SMTP id XAA14398 for <[e-mail]>; Mon, 4 Oct 1999 23:56:56 -0700 (PDT)
Received: (qmail 41986 invoked from network); 5 Oct 1999 06:58:12 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 5 Oct 1999 06:58:12 -0000
Received: (qmail 14851 invoked from network); 5 Oct 1999 06:58:11 -0000
Received: from storas08.dynas.se (HELO MNYSTROM-LAP) (10.129.29.108) by spirit.dynas.se with SMTP; 5 Oct 1999 06:58:11 -0000
Date: Tue, 5 Oct 1999 08:57:42 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[e-mail]>
Reply-To: [e-mail]
To: Ambarish Malpani <[e-mail]>
cc: [e-mail]
Subject: Re: FW: DER encoding of OPTIONAL sequences with nothing
In-Reply-To: <001401bf0e99$713b2570$[e-mail]>
Message-ID: <[e-mail]>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Ambarish,

On Mon, 4 Oct 1999, Ambarish Malpani wrote:

[...] 
> but do them as:
> 
>  Top ::= SEQUENCE {
>      i    INTEGER,
>      something [0] EXPLICIT SEQUENCE SIZE (1..MAX) OF Foo OPTIONAL
>  }

But why the [0] EXPLICIT? The tags (INTEGER, SEQUENCE) are unique anyway.

-- Magnus
Magnus Nystrom		Email: [e-mail]
RSA Laboratories



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA08367 for <[e-mail]>; Mon, 4 Oct 1999 22:30:55 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial02.spyrus.com [207.212.34.122]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id WAA01157; Mon, 4 Oct 1999 22:24:31 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 04 Oct 1999 13:13:45 -0400
To: Robert Moskowitz <[e-mail]>, "David P. Kemp" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: ASN.1 question on 2459
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <006d01bf0925$64c64aa0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Bob:

The use of SIZE (1..MAX) says that zero items are not allowed, just one or 
more.  Thus, when zero is a possibility, OPTIONAL means that the item 
should be absent if there are zero items.

By using these two together, there is only one legal way to represent zero 
items.  Our intent was to reduce complexity by not admitting multiple ways 
to include zero items.

Dave:

The use of NULL parameters with several algorithms has to do with the way 
that they were registered.  When the 1988 syntax for AlgorithmIdentifier 
was translated to the 1997 syntax, the OPTIONAL associated with the 
parameters got lost.  Later, via a defect report, it was recovered.  So, 
many people thought that algorithm parameters were mandatory.  If algorithm 
parameters were mandatory and there was nothing useful to include, NULL is 
a reasonable selection.

Russ

At 09:24 AM 9/30/99 -0400, Robert Moskowitz wrote:
>At 05:10 PM 9/29/1999 -0400, Robert Moskowitz wrote:
> >What is the difference between the following two structures:
> >
> >::= SEQUENCE SIZE (1..MAX) OF
> >
> >::= SET OF
> >
>Thank you all of you that answered.
>
>In 2459, SET seems to be used only in Name things.  SEQUENCE SIZE is used
>most of the time, and it always starts with 1..
>
>But some of them are 'optional':
>
>         policyQualifiers   SEQUENCE SIZE (1..MAX) OF
>                                 PolicyQualifierInfo OPTIONAL }
>
>
>Again this is a bit confusing to the casual reader.  The only LOGICAL
>interpretation is a SEQUENCE of SIZE 0 is different in the cert than not
>present and this is desireable.  OK.
>
>Some of this stuff is wicked.
>
>
>Robert Moskowitz
>ICSA
>Security Interest EMail: [e-mail]



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA13184 for <[e-mail]>; Mon, 4 Oct 1999 11:46:42 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id LAA15273 for <[e-mail]>; Mon, 4 Oct 1999 11:47:57 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id LAA24097 for <[e-mail]>; Mon, 4 Oct 1999 11:47:57 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>
Subject: FW: DER encoding of OPTIONAL sequences with nothing
Date: Mon, 4 Oct 1999 11:51:17 -0700
Message-ID: <001401bf0e99$713b2570$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Hi PKIX-land,
    Just learnt something of the ASN.1 mailing list that I
think will be of general interest.

In a nutshell, try not to have definitions like:

 Top ::= SEQUENCE {
     i    INTEGER,
     something [0] EXPLICIT SEQUENCE OF Foo OPTIONAL
 }

but do them as:

 Top ::= SEQUENCE {
     i    INTEGER,
     something [0] EXPLICIT SEQUENCE SIZE (1..MAX) OF Foo OPTIONAL
 }


This prevents you from allowing 2 different DER encodings of a
single object.

Please ignore the mail if this was obvious.

Regards,
Ambarish


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


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Ambarish Malpani
> Sent: Monday, October 04, 1999 10:35 AM
> To: [e-mail]
> Subject: RE: DER encoding of OPTIONAL sequences with nothing
> 
> 
> 
> Hi John,
>     Okay, that clarifies the issue.
> 
> Next time, I will make sure I specify top as:
> 
> Top ::= SEQUENCE {
>     i    INTEGER,
>     something [0] EXPLICIT SEQUENCE SIZE (1..MAX) OF Foo OPTIONAL
> }
> 
> Some people do it this way and I had never figured out why.
> 
> Thanks,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On Behalf Of John Larmouth
> > Sent: Saturday, October 02, 1999 3:20 AM
> > To: [e-mail]
> > Subject: Re: DER encoding of OPTIONAL sequences with nothing
> > 
> > 
> > I am afraid we need to discuss angels on pin-heads here!  
> The issue is
> > the set of abstract values in Top.  DER guarantees a unique 
> > encoding for
> > each separate abstract value,  but equally an application can put
> > different semantics on different abstract values,  so all abstract
> > values in the type have to have different endcodings.
> > 
> > In the case of an OPTIONAL element (or whatever type),  ASN.1 
> > takes the
> > view that a SEQUENCE value with an OPTIONAL element present is a
> > different abstract value (carries different semantics) from 
> > one where it
> > is absent.
> > 
> > This is quite clearly correct in the general case.  It just looks a
> > little funny in the case that you quote!
> > 
> > So the principle is that a value of Top with something missing is a
> > distinct abstract value (and may carry different semantics) 
> > from a value
> > with something present as an empty sequence of.  DER 
> therefore allows
> > (has to allow) different encodings for the two cases.
> > 
> > John L
> > 
> > 
> > Ambarish Malpani wrote:
> > > 
> > > Hi Guys,
> > >     A question was raised in the IETF PKIX working group that
> > > would benefit from some input from this group.
> > > 
> > > If I define
> > > 
> > > Top ::= SEQUENCE {
> > >     i    INTEGER,
> > >     something [0] EXPLICIT SEQUENCE OF Foo OPTIONAL
> > > }
> > > 
> > > And I am trying to do a DER encoding of a top, where the
> > > something contains no Foo's, is the right encoding to not put any
> > > bytes, or to encode it as a tag 0, length 2, and sequence
> > > of length 0?
> > > 
> > > Is this a bug in the DER encoding rules (which promise a unique
> > > encoding), or is the correct encoding specified in the rules?
> > > 
> > > Regards,
> > > Ambarish
> > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > Ambarish Malpani
> > > Architect                                                
> > 650.567.5457
> > > ValiCert, Inc.                                  
> > [e-mail]
> > > 1215 Terra Bella Ave.                         
> http://www.valicert.com
> > Mountain View, CA 94043-1833
> 
> -- 
> ==============================================================
> ==========
>                           Prof John Larmouth
>    1 Blueberry Road,  Bowdon,  Altrincham,  Cheshire WA14 
> 3LS,  England.
>      j.larmouth @ salford.ac.uk              Tel: [phone]
>         Fax (work): [phone]  Tel (work): [phone]
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> - - - - -
> 
> 


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.imc.org (8.9.3/8.9.3) with SMTP id LAA13107 for <[e-mail]>; Mon, 4 Oct 1999 11:46:11 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Mon, 04 Oct 1999 14:46:15 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 04 Oct 1999 14:45:34 -0400
To: [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Requested change for 2459
Cc: Tim Polk <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <006d01bf0925$64c64aa0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Change to validityDate Choice rule:

Background:

in 

4.1.2.4  Issuer

We set a 'flag date' of 1/1/2004:

   The DirectoryString type is defined as a choice of PrintableString,
   TeletexString, BMPString, UTF8String, and UniversalString.  The
   UTF8String encoding is the preferred encoding, and all certificates
   issued after December 31, 2003 MUST use the UTF8String encoding of
   DirectoryString (except as noted below).  Until that date, conforming
   CAs MUST choose from the following options when creating a
   distinguished name, including their own:

Then in

4.1.2.5  Validity

we set a very indeterminant date with:

   CAs conforming to this profile MUST always encode certificate
   validity dates through the year 2049 as UTCTime; certificate validity
   dates in 2050 or later MUST be encoded as GeneralizedTime.

So sometime around 2040 or earlier, long-live root certs will start
appearing using GeneralizedTime, long after most of us are out of this
business.  I propose the following change to 4.1.2.5:

   CAs conforming to this profile MUST always encode certificate
   validity dates using GeneralizedTime for all certificates
   issued after December 31, 2003.  Y2K proccessing of UTCTime will
   assume century 19 if UTCTime is greater than 49 and century 20 if
   UTCTime is less than 50.

This gives PKIX one clear flag date for both UTF8String and GeneralizedTime
support.

It also makes sure that all of the programmers and product managers are
still around to answer to any failures....


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


Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.imc.org (8.9.3/8.9.3) with SMTP id GAA05413 for <[e-mail]>; Mon, 4 Oct 1999 06:50:29 -0700 (PDT)
Received: from lynn.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP  id <[e-mail]>; Mon, 4 Oct 1999 14:51:15 +0100
To: Peter Lewis <[e-mail]>
cc: ietf-pkix <[e-mail]>, [e-mail]
Subject: Re: From Firewall to IPSec VPNs
In-reply-to: Your message of "Mon, 04 Oct 1999 15:19:18 +0200." <006301bf0e6b$10ab1400$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 04 Oct 1999 14:51:13 +0100
Message-ID: <[e-mail]>
From: Peter KIRSTEIN <[e-mail]>

In message <006301bf0e6b$10ab1400$[e-mail]>you write:
>This is a multi-part message in MIME format.
>
>------=_NextPart_000_0060_01BF0E7B.D3AD9D00
>Content-Type: text/plain;
>	charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>Security services and protection mechanisms
>IPv6 promises regarding IPSec
>Certification infrastructure
>Standardization update
>Case Studies: ISPs, carriers, private networks
>AH and ESP protocols description
>Possible future extensions and modifications of the IKE protocol
>Complementarity between IPSec and firewalls
>Global Site-to-Site IPSec VPN's with End-to-End SLA's
>Managing widespread IPSEC virtual private networks
>Solving IPSec VPNs scalability
>Results of some interoperability tests
>IPSec architectures and non-standardized aspects of IPSec
>Adding IPSec VPN functions in an existing router network
>Impact of fragmentation on the performance of IPSec coding
>
>IPSEC 99 Conference
>From Firewall to IPSec VPNs
>
>October 26, 27, 28, 29, 1999
>Paris - France
>
>More infos: www.upperside.fr/baipsec.htm
>
Do you have a student rate? I am considering sending a graduate
student, but there is no relevant rate shown.

Peter Kirstein
X*********************************************************************X
* Prof Peter Kirstein		   Telephone:  [phone]	
* Department of Computer Science   Fax:        [phone]
* University College London        Telex:      28722
* Gower Street                     Internet:   [e-mail]
* London 
* WC1E 6BT                      
* U.K			URL    : http://www.cs.ucl.ac.uk/staff/kirstein
X*********************************************************************X



Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA04509 for <[e-mail]>; Mon, 4 Oct 1999 06:18:09 -0700 (PDT)
Received: from Dell  (dyn-1-1-229.Cor.dialup.oleane.fr [62.161.8.229])  by s2.smtp.oleane.net  with SMTP id PAA83763 for <[e-mail]>; Mon, 4 Oct 1999 15:19:21 +0200 (CEST)
Message-ID: <006301bf0e6b$10ab1400$[e-mail]>
From: "Peter Lewis" <[e-mail]>
To: <[e-mail]>
Subject: From Firewall to IPSec VPNs
Date: Mon, 4 Oct 1999 15:19:18 +0200
Organization: Upperside
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01BF0E7B.D3AD9D00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0060_01BF0E7B.D3AD9D00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Security services and protection mechanisms
IPv6 promises regarding IPSec
Certification infrastructure
Standardization update
Case Studies: ISPs, carriers, private networks
AH and ESP protocols description
Possible future extensions and modifications of the IKE protocol
Complementarity between IPSec and firewalls
Global Site-to-Site IPSec VPN's with End-to-End SLA's
Managing widespread IPSEC virtual private networks
Solving IPSec VPNs scalability
Results of some interoperability tests
IPSec architectures and non-standardized aspects of IPSec
Adding IPSec VPN functions in an existing router network
Impact of fragmentation on the performance of IPSec coding

IPSEC 99 Conference
>From Firewall to IPSec VPNs

October 26, 27, 28, 29, 1999
Paris - France

More infos: www.upperside.fr/baipsec.htm



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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV>Security services and protection mechanisms<BR>IPv6 promises =
regarding=20
IPSec<BR>Certification infrastructure<BR>Standardization update<BR>Case =
Studies:=20
ISPs, carriers, private networks<BR>AH and ESP protocols =
description<BR>Possible=20
future extensions and modifications of the IKE =
protocol<BR>Complementarity=20
between IPSec and firewalls<BR>Global Site-to-Site IPSec VPN's with =
End-to-End=20
SLA's<BR>Managing widespread IPSEC virtual private networks<BR>Solving =
IPSec=20
VPNs scalability<BR>Results of some interoperability tests<BR>IPSec=20
architectures and non-standardized aspects of IPSec<BR>Adding IPSec VPN=20
functions in an existing router network<BR>Impact of fragmentation on =
the=20
performance of IPSec coding<BR><BR>IPSEC 99 Conference<BR>From Firewall =
to IPSec=20
VPNs<BR><BR>October 26, 27, 28, 29, 1999<BR>Paris - France<BR><BR>More =
infos: <A=20
href=3D"http://www.upperside.fr/baipsec.htm">www.upperside.fr/baipsec.htm=
</A></DIV>
<DIV>&nbsp;</DIV></FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0060_01BF0E7B.D3AD9D00--



Received: from sand4.global.net.uk (sand4.global.net.uk [194.126.80.248]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id XAA26694 for <[e-mail]>; Sat, 2 Oct 1999 23:49:29 -0700 (PDT)
Received: from pe4s10a07.client.global.net.uk ([195.147.234.229] helo=rincewind) by sand4.global.net.uk with smtp (Exim 2.12 #1) id 11XfTY-0000HK-00; Sun, 3 Oct 1999 07:50:28 +0100
Message-ID: <006701bf0d6b$442b1880$e5ea93c3@rincewind>
From: "nKrypt-IT Ltd." <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Tony Selmes" <[e-mail]>, "Bigbadbob" <[e-mail]>
Subject: Registartion Authority Functionality
Date: Sun, 3 Oct 1999 07:48:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211

I am not sure this has a place here, but comments/ suggestions would be
useful.

Microsoft have recently 'requested' the abrogation of international
standards for Chat or Instant messaging.

Our product includes encrypted chat messaging and also encrypted voice over
IP and video messaging using public key protection.

One of the major problems here, is knowing the IP addresses of users
connected using a dial-up connection with dynamic IP address allocation.
Could this not be a function of the Registration Authority and, if so could
the appropriate message structures be added to those given in RFC2510 ?

The registration authority would certainly be in a position to determine the
'right' of another user to be given a specific users on-line connection
details.

As I mention above, I am not sure that this is appropriate or may well be
supported in other areas of the proposed pkix standards.

Any comments, further information, suggestions would be appreciated.

Martin Anderson,
Senior Developer
nKrypt-IT Ltd.
http://www.nKrypt-IT.co.uk




Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA23280 for <[e-mail]>; Fri, 1 Oct 1999 14:30:06 -0700 (PDT)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id VAA09278; Fri, 1 Oct 1999 21:30:41 GMT
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id WAA25193; Fri, 1 Oct 1999 22:31:06 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Oct 1999 22:30:40 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.6 [en-gb] (WinNT; I)
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: "'Phillip M Hallam-Baker'" <[e-mail]>, "Pkix List (E-mail)" <[e-mail]>
Subject: Re: Publishing Base CRL's & replicating publication mechanisms
References: <2F2DC5CE035DD1118C8E00805FFE354C0F526707@RED-MSG-56>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Trevor Freeman wrote:
> 
> As a group of practical people, the futility of mandating creating something
> which has no intrinsic benefit is plain for all to see. So I hope we don't
> end up there, and I am open to any creative wordsmith input for
> alternatives.

Is that really a problem? No-one will buy something that is useless, but
you can't dictate how it should be made useful in this case, so why
worry?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi


Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mail.imc.org (8.9.3/8.9.3) with SMTP id OAA22883 for <[e-mail]>; Fri, 1 Oct 1999 14:14:48 -0700 (PDT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 01 Oct 1999 13:16:09 -0700 (Pacific Daylight Time)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id <TTX9PWAK>; Fri, 1 Oct 1999 13:16:09 -0700
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0F526708@RED-MSG-56>
From: Trevor Freeman <[e-mail]>
To: "'David A. Cooper'" <[e-mail]>
Cc: "Pkix List (E-mail)" <[e-mail]>
Subject: RE: Publishing Base CRLs
Date: Fri, 1 Oct 1999 13:15:59 -0700 
X-Mailer: Internet Mail Service (5.5.2524.0)

I have looked there and CRLscope is not an extension I would want to
consider at this time due to its complexity.
Perhaps we should name these efforts Lightweight Delta CRL's

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]
Sent: Friday, October 01, 1999 1:10 PM
To: Trevor Freeman; Pkix List (E-mail)
Subject: Re: Publishing Base CRLs


At 11:51 AM 10/1/99 -0700, Trevor Freeman wrote:
>Therefore my proposal is to remove the current mandate that a base CRL be
>published every time a delta CRL is published.
>Trevor

I would suggest looking at the X.509 FPDAM on certificate extensions
(available
at ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.doc
or
ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.pdf).

In particular, look at the proposed text for the CRL scope field (section
12.5.2.5) and
the delta CRL indicator field (section 12.6.3.3). Also look at section
12.6.4.

Dave



Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.imc.org (8.9.3/8.9.3) with SMTP id NAA22329 for <[e-mail]>; Fri, 1 Oct 1999 13:55:57 -0700 (PDT)
Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 01 Oct 1999 13:10:58 -0700 (Pacific Daylight Time)
Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id <4C293WH8>; Fri, 1 Oct 1999 13:10:57 -0700
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0F526707@RED-MSG-56>
From: Trevor Freeman <[e-mail]>
To: "'Phillip M Hallam-Baker'" <[e-mail]>, "Pkix List (E-mail)" <[e-mail]>
Subject: RE: Publishing Base CRL's & replicating publication mechanisms
Date: Fri, 1 Oct 1999 13:10:50 -0700 
X-Mailer: Internet Mail Service (5.5.2650.21)

As a group of practical people, the futility of mandating creating something
which has no intrinsic benefit is plain for all to see. So I hope we don't
end up there, and I am open to any creative wordsmith input for
alternatives.
I don't know why this has been mandated, and it may be that this kind of
scenario was not foreseen when the stipulation was laid down. 
Multiple servers with replicating information is a proven solution for the
customer need for high availability so I don't think we can back off this
issue.

Original Message-----
From: Phillip M Hallam-Baker [mailto:[e-mail]]
Sent: Friday, October 01, 1999 12:50 PM
To: Trevor Freeman; Pkix List (E-mail)
Subject: RE: Publishing Base CRL's & replicating publication mechanisms


I believe the answer lies in your reading of the term 'published' which
as has previously been established cannot be mandated by the spec.

I believe that last time we looked at this it was decided that the spec
could mandate CREATION of a base CRL each time a delta was created but
could not mandate that it be sent anywhere! So an implementation that
'published' the CRL straight to /dev/null could be seen as 'compliant'!

This tends to support the idea that mandating a base update is not a
reasonable requirement since it cannot be enforced.

I believe that the motivation for this requirement was to allow
implementation of delta CRLs to be made optional since some consider
systems in which two CRLs (base and delta) must be obtained and
corellated to be intrinsically more complicated than systems in which
only one CRL (base) need be obtained.

		Phill


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Friday, October 01, 1999 2:52 PM
> To: Pkix List (E-mail)
> Subject: Publishing Base CRL's & replicating publication mechanisms
>
>
> Partitioned CRL's helps the client out by reducing the size of the
> individual CRL that needs to be downloaded. It may seem an obvious
> observation, but it does nothing to help out the impact on the
> infrastructure if you have a replicating publication mechanism.
> If a CA has
> 100K revocations on its list, then the impact of publishing new revocation
> data on the infrastructure is pretty much the same if you have 1 or 1K
> CRL's. The underlying infrastructure is understandably oblivious to the
> details of the change, only to the fact that a change has been made and
> needs to be replicated.  Publishing a delta CRL without publishing a base
> CRL would address this problem. More current revocation
> information can then
> be published, while minimizing the impact on the infrastructure.
> Therefore my proposal is to remove the current mandate that a base CRL be
> published every time a delta CRL is published.
> Trevor
>


Received: from csmes.ncsl.nist.gov ([129.6.54.2]) by mail.imc.org (8.9.3/8.9.3) with SMTP id NAA21543 for <[e-mail]>; Fri, 1 Oct 1999 13:09:57 -0700 (PDT)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with ESMTP id QAA05990; Fri, 1 Oct 1999 16:10:47 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 01 Oct 1999 16:10:00 -0400
To: Trevor Freeman <[e-mail]>, "Pkix List (E-mail)" <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: Publishing Base CRLs
In-Reply-To: <2F2DC5CE035DD1118C8E00805FFE354C0F526704@RED-MSG-56>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:51 AM 10/1/99 -0700, Trevor Freeman wrote:
>Therefore my proposal is to remove the current mandate that a base CRL be
>published every time a delta CRL is published.
>Trevor

I would suggest looking at the X.509 FPDAM on certificate extensions (available
at ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.doc or
ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.pdf).

In particular, look at the proposed text for the CRL scope field (section 12.5.2.5) and
the delta CRL indicator field (section 12.6.3.3). Also look at section 12.6.4.

Dave




Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA21171 for <[e-mail]>; Fri, 1 Oct 1999 12:47:56 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id MAA19668; Fri, 1 Oct 1999 12:46:40 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA04721; Fri, 1 Oct 1999 12:48:24 -0700 (PDT)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SF5SL5AY; Fri, 1 Oct 1999 12:48:25 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, "Pkix List (E-mail)" <[e-mail]>
Subject: RE: Publishing Base CRL's & replicating publication mechanisms
Date: Fri, 1 Oct 1999 15:49:47 -0400
Message-ID: <002601bf0c46$1d7df020$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <2F2DC5CE035DD1118C8E00805FFE354C0F526704@RED-MSG-56>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal

I believe the answer lies in your reading of the term 'published' which
as has previously been established cannot be mandated by the spec.

I believe that last time we looked at this it was decided that the spec
could mandate CREATION of a base CRL each time a delta was created but
could not mandate that it be sent anywhere! So an implementation that
'published' the CRL straight to /dev/null could be seen as 'compliant'!

This tends to support the idea that mandating a base update is not a
reasonable requirement since it cannot be enforced.

I believe that the motivation for this requirement was to allow
implementation of delta CRLs to be made optional since some consider
systems in which two CRLs (base and delta) must be obtained and
corellated to be intrinsically more complicated than systems in which
only one CRL (base) need be obtained.

		Phill


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Friday, October 01, 1999 2:52 PM
> To: Pkix List (E-mail)
> Subject: Publishing Base CRL's & replicating publication mechanisms
>
>
> Partitioned CRL's helps the client out by reducing the size of the
> individual CRL that needs to be downloaded. It may seem an obvious
> observation, but it does nothing to help out the impact on the
> infrastructure if you have a replicating publication mechanism.
> If a CA has
> 100K revocations on its list, then the impact of publishing new revocation
> data on the infrastructure is pretty much the same if you have 1 or 1K
> CRL's. The underlying infrastructure is understandably oblivious to the
> details of the change, only to the fact that a change has been made and
> needs to be replicated.  Publishing a delta CRL without publishing a base
> CRL would address this problem. More current revocation
> information can then
> be published, while minimizing the impact on the infrastructure.
> Therefore my proposal is to remove the current mandate that a base CRL be
> published every time a delta CRL is published.
> Trevor
>



Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mail.imc.org (8.9.3/8.9.3) with SMTP id LAA20113 for <[e-mail]>; Fri, 1 Oct 1999 11:51:30 -0700 (PDT)
Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 01 Oct 1999 11:52:00 -0700 (Pacific Daylight Time)
Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id <T9F2VCJ2>; Fri, 1 Oct 1999 11:52:00 -0700
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0F526704@RED-MSG-56>
From: Trevor Freeman <[e-mail]>
To: "Pkix List (E-mail)" <[e-mail]>
Subject: Publishing Base CRL's & replicating publication mechanisms
Date: Fri, 1 Oct 1999 11:51:52 -0700 
X-Mailer: Internet Mail Service (5.5.2650.21)

Partitioned CRL's helps the client out by reducing the size of the
individual CRL that needs to be downloaded. It may seem an obvious
observation, but it does nothing to help out the impact on the
infrastructure if you have a replicating publication mechanism. If a CA has
100K revocations on its list, then the impact of publishing new revocation
data on the infrastructure is pretty much the same if you have 1 or 1K
CRL's. The underlying infrastructure is understandably oblivious to the
details of the change, only to the fact that a change has been made and
needs to be replicated.  Publishing a delta CRL without publishing a base
CRL would address this problem. More current revocation information can then
be published, while minimizing the impact on the infrastructure. 
Therefore my proposal is to remove the current mandate that a base CRL be
published every time a delta CRL is published.
Trevor


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA20064 for <[e-mail]>; Fri, 1 Oct 1999 11:49:54 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA10836 for <[e-mail]>; Fri, 1 Oct 1999 14:51:20 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id OAA10831 for <[e-mail]>; Fri, 1 Oct 1999 14:51:19 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id OAA27531 for <[e-mail]>; Fri, 1 Oct 1999 14:50:39 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (avenger53.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Fri, 01 Oct 1999 14:51:06 -0400
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <TZ04ZVTY>; Fri, 1 Oct 1999 14:51:08 -0400
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: [e-mail]
Subject: Nationality / country of citizenship attribute question
Date: Fri, 1 Oct 1999 14:51:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF0C3D.EBCD2CF6"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF0C3D.EBCD2CF6
Content-Type: text/plain;
	charset="iso-8859-1"

All,

I have a requirement for an attribute to represent nationality (country of
citizenship) with two constraining factors.  First, it must be multi-valued,
as many nations permit dual-citizenship and second, it must be extensible to
use the ISO-3166-1 trigraphs.  

Several multinational security policies expressly state that the Release To
fields contain, in alphabetical order, a trigraph indication of those
countries to which the information may be released.

I have looked at the nationality attribute in ACP 133 as well as the
countryOfCitizenship attribute in the Qualified Certificates. They are both
single valued and constrained to digraph usage only.

I would ask assistance in either modifying the existing attributes, or,
creating (yet another) new one.  

Additionally, I have a requirement for an attribute that can represent the
employment status of a given individual.  While initially thinking that a
bit map would work, I quickly realized that although that would support
access control processing more easily, it is not extensible.  I would like
to propose a new attribute type that is (short sighted?) single valued and a
Directory string, that indicates the status of one's employment.  For
example, it woould contain a corporate name or country government
affiliation.

Sandi Miklos


------_=_NextPart_001_01BF0C3D.EBCD2CF6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<P><FONT SIZE=3D2>All,</FONT>
</P>

<P><FONT SIZE=3D2>I have a requirement for an attribute to represent =
nationality (country of citizenship) with two constraining =
factors.&nbsp; First, it must be multi-valued, as many nations permit =
dual-citizenship and second, it must be extensible to use the =
ISO-3166-1 trigraphs.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Several multinational security policies expressly =
state that the Release To fields contain, in alphabetical order, a =
trigraph indication of those countries to which the information may be =
released.</FONT></P>

<P><FONT SIZE=3D2>I have looked at the nationality attribute in ACP 133 =
as well as the countryOfCitizenship attribute in the Qualified =
Certificates. They are both single valued and constrained to digraph =
usage only.</FONT></P>

<P><FONT SIZE=3D2>I would ask assistance in either modifying the =
existing attributes, or, creating (yet another) new one.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Additionally, I have a requirement for an attribute =
that can represent the employment status of a given individual.&nbsp; =
While initially thinking that a bit map would work, I quickly realized =
that although that would support access control processing more easily, =
it is not extensible.&nbsp; I would like to propose a new attribute =
type that is (short sighted?) single valued and a Directory string, =
that indicates the status of one's employment.&nbsp; For example, it =
woould contain a corporate name or country government =
affiliation.</FONT></P>

<P><FONT SIZE=3D2>Sandi Miklos</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF0C3D.EBCD2CF6--


Received: from btec-fw.certco.com (btec-fw.certco.com [209.2.102.3]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA17396 for <[e-mail]>; Fri, 1 Oct 1999 08:57:50 -0700 (PDT)
From: [e-mail]
Received: from nycertco-srv1.ny.certco.com (nycertco-srv1.certco.com [10.100.24.12]) by btec-fw.certco.com (Postfix) with ESMTP id 957F432DDB; Fri,  1 Oct 1999 11:58:33 -0400 (EDT)
Received: by nycertco-srv1.certco.com with Internet Mail Service (5.5.2448.0) id <TTNDAKDY>; Fri, 1 Oct 1999 11:58:46 -0400
Message-ID: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: ASN.1 question on 2459
Date: Fri, 1 Oct 1999 11:58:43 -0400 
X-Mailer: Internet Mail Service (5.5.2448.0)

I meant to add the following.

David Kemp wrote, "the only reason to encode an optional element as a NULL
would
be, as Peter says, to bulk up your certificates"

The reason to encode an optional element as a NULL is because the
specification says to do so. Below are examples of specifications that say
to do so.

Frank

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, October 01, 1999 11:42 AM
To: [e-mail]; [e-mail]; [e-mail]
Subject: RE: ASN.1 question on 2459


ASN.1 is unusual in that it formally defines a type for null (i.e., NULL).

In the case of AlgorithmIdentifier for an RSA signature, PKCS #1 specifies
what to do in section 11:

<quote>
These object identifiers are intended to be used in the algorithm field of a
value of type AlgorithmIdentifier. The parameters field of that type, which
has the algorithm-specific syntax ANY DEFINED BY algorithm, would have ASN.1
type NULL for these algorithms.
</quote>

RFC 2459 describes the same thing in section 7.2.1:

<quote>
When any of these three OIDs appears within the ASN.1 type
AlgorithmIdentifier, the parameters component of that type shall be the
ASN.1 type NULL.
</quote>

Most of this stuff makes sense. You just need to dig a little.

Frank Balluffi
CertCo

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Thursday, September 30, 1999 4:33 PM
To: [e-mail]; [e-mail]
Subject: RE: ASN.1 question on 2459



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


The RFC 2459 definition of Algorithm Identifier is:

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

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

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

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

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

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


Received: from btec-fw.certco.com (btec-fw.certco.com [209.2.102.3]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA17029 for <[e-mail]>; Fri, 1 Oct 1999 08:41:22 -0700 (PDT)
From: [e-mail]
Received: from nycertco-srv1.ny.certco.com (nycertco-srv1.certco.com [10.100.24.12]) by btec-fw.certco.com (Postfix) with ESMTP id 80AF532DDC; Fri,  1 Oct 1999 11:42:03 -0400 (EDT)
Received: by nycertco-srv1.certco.com with Internet Mail Service (5.5.2448.0) id <TTNDAKCA>; Fri, 1 Oct 1999 11:42:16 -0400
Message-ID: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: ASN.1 question on 2459
Date: Fri, 1 Oct 1999 11:42:14 -0400 
X-Mailer: Internet Mail Service (5.5.2448.0)

ASN.1 is unusual in that it formally defines a type for null (i.e., NULL).

In the case of AlgorithmIdentifier for an RSA signature, PKCS #1 specifies
what to do in section 11:

<quote>
These object identifiers are intended to be used in the algorithm field of a
value of type AlgorithmIdentifier. The parameters field of that type, which
has the algorithm-specific syntax ANY DEFINED BY algorithm, would have ASN.1
type NULL for these algorithms.
</quote>

RFC 2459 describes the same thing in section 7.2.1:

<quote>
When any of these three OIDs appears within the ASN.1 type
AlgorithmIdentifier, the parameters component of that type shall be the
ASN.1 type NULL.
</quote>

Most of this stuff makes sense. You just need to dig a little.

Frank Balluffi
CertCo

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Thursday, September 30, 1999 4:33 PM
To: [e-mail]; [e-mail]
Subject: RE: ASN.1 question on 2459



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


The RFC 2459 definition of Algorithm Identifier is:

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

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

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

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

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

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


Received: from mystic.trustcenter.de (mystic.trustcenter.de [194.64.226.89]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id CAA02343 for <[e-mail]>; Fri, 1 Oct 1999 02:16:41 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 01 Oct 1999 11:14:25 +0200
From: Peter Biltzinger <[e-mail]>
Organization: TC TrustCenter for Security in Data Networks GmbH
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: CMP-polling
References: <005901bf0aaf$aa2bb950$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms827920EF4A00B5D95C669059"

This is a cryptographically signed message in MIME format.

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

Dear Amit,

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

In the case of sending a signed pkiMsg by the CA
to the attacker you are in principle right, but
all the difficulties regarding the account between the RA and CA
are avoidable when using signed pollReq:
(1) In the case of a snooped signed pollReq the CA would
be able to recognize the attack as replay attack and
(2) in the case of a signed pollMsg signing with a wrong certificate,
    the CA would be able to recognize this also.

In the case of sending only a new pollingReferenceNumber by
the CA to the attacker, your argument regarding the missing
signed confirmation message accesses not, because the CA
expected no such message. The RA sends  a wrong
(not current) pollingReferenceNumber to CA and gets a
error message which again avoidable (by using signed pollReq)
difficulties implies.

This attack is a too easy way to disturb a CA.


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

The same arguments as in point a). All difficulties
regarding the account between the RA and CA
are avoidable when using signed pollReq. This attack
is also a too easy way to disturb a CA.


> >
> > c) The attacker sends unsigned pollReq with snooped
> >    old pollingReferenceNumbers or with random numbers to
> >    the CA and the CA sends signed pkiMsg or unsigned
> >    pollRep to the attacker. In the case of a hard attack
> >    of this kind the CA can be overloaded which is equal
> >    to a denial-of-service attack. (A signed pollReq would have
> >    the advantage, that the verification of the RSA signature
> >    is very much faster than the generation of the
> >    RSA signature regarding the CA-pkiMsg to be generated
> >    and perhaps to be encrypted.)
> >    Nevertheless, in the case of signed pollReq (PKIMessages which
> >    should contain the pollingReferenceNumber) the attacker can
> >    snoop a signed RA-pollReq and send this one to the CA. But in
> >    this case, the CA can verify the recipNonce in this kind of
> >    PKIMessage and would be able to recognize a replay attack.
> >
> > Are these attacks not conceivable?
> >
> 
>         The end entity not getting the new polling reference number
>         is feasible without a attack also.  Say, I send a IR, get
>         back a poll response, send a poll request, and the poll
>         response (with a new poll reference) is lost on the
>         network.  Both sides, client and server, have to be
>         aware of this and be ready to take suitable action.
> 
>         You are completely correct in that all the above attacks
>         are feasible.  However, these are denial of service attacks
>         and if someone wants to really do that, they do not have
>         to go to such pains as snooping, trying to get in the
>         middle.  I would just send tons of signed certificate
>         requests and let the server verify them and realize it
>         does not know me, wasting lots of processor bandwidth.
>         Or even send incorrectly encoded PKIMessages or even
>         signed poll requests or create TCP connections or ...
> 

In this point you are right, there are a lot of possible
denial-of-service attacks.
But a CA have to protect itself in the best way as possible. So, why
still add
further possible denial-of-service attacks?

The loss of messages in the network is possible, but this is
a rare event and must be handled. I mean a systematically
disturbance of the communication between the RA and CA
in a way, that the CA and RA cannot do their job in a
correctly and securely way over a long period with a
very high frequency of requests AND only minimal human
interventions.

Perhaps you can tell me why all messages are optional signed (depending
on
the CA policy) except the pollRep and pollReq? And why is the assignment
of new pollingReferenceNumbers intended, if the response by the CA
regarding
a pollReq is not yet finished ( in contrast to using always the same
pollingReferenceNumber regarding a given EE/RA-request )?


regards,

            Peter

----------------------------- 
Peter Biltzinger
TC TrustCenter for Security in Data Networks GmbH
Am Werder 1, 22073 Hamburg, Germany    
http://www.trustcenter.de
mailto:[e-mail]
--------------ms827920EF4A00B5D95C669059
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIFjAYJKoZIhvcNAQcCoIIFfTCCBXkCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
A3YwggNyMIIC26ADAgECAgMB87YwDQYJKoZIhvcNAQEEBQAwgbwxCzAJBgNVBAYTAkRFMRAw
DgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVzdENl
bnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBU
cnVzdENlbnRlciBDbGFzcyAzIENBMSkwJwYJKoZIhvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVz
dGNlbnRlci5kZTAeFw05OTAzMjkxMzI4MzZaFw0wMDAzMjgxMzI4MzZaMHoxCzAJBgNVBAYT
AkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMR0wGwYDVQQDExREci4g
UGV0ZXIgQmlsdHppbmdlcjEoMCYGCSqGSIb3DQEJARYZYmlsdHppbmdlckB0cnVzdGNlbnRl
ci5kZTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC1d3+m63a2oLTklvmyIPKB5XkkvD9pDBTl
gS9E2iyeYX2Fp1DrpLLxP/6PXzZEChor3OSLFuK3DSOH/i9T9dsTAgMBAAGjggEFMIIBATBH
BglghkgBhvhCAQMEOhY4aHR0cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVj
ay1yZXYuY2dpLzAxRjNCNj8wPAYJYIZIAYb4QgEHBC8WLWh0dHBzOi8vd3d3LnRydXN0Y2Vu
dGVyLmRlL2NnaS1iaW4vUmVuZXcuY2dpPzA+BglghkgBhvhCAQgEMRYvaHR0cDovL3d3dy50
cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzL2luZGV4Lmh0bWwwJQYJYIZIAYb4QgENBBgWFlRD
IFRydXN0Q2VudGVyIENsYXNzIDMwEQYJYIZIAYb4QgEBBAQDAgCgMA0GCSqGSIb3DQEBBAUA
A4GBABwEQcJSlH7tVvqWUcYga2NVq/bgDhGUxftFvCSSZcaBGDy1X4wyKcWNoof5lKKhkOy4
9oMuV9EmWX0UVyUnlwSGpz7PzbtoukbZgOfj4h3kyQkMgpVHVj2NkVzvzHj4AIkP6AEP+Xpv
q/md7e3hKInG3RooximeyVTJ2dcaumNkMYIB3jCCAdoCAQEwgcQwgbwxCzAJBgNVBAYTAkRF
MRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVz
dENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlU
QyBUcnVzdENlbnRlciBDbGFzcyAzIENBMSkwJwYJKoZIhvcNAQkBFhpjZXJ0aWZpY2F0ZUB0
cnVzdGNlbnRlci5kZQIDAfO2MAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMDAxMDkxNDI3WjAjBgkqhkiG9w0BCQQxFgQUnnA3
bwKcZyCdGk5EsFNoVqk6nEMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG
9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZI
hvcNAQEBBQAEQGa89/SrFs9RJ1jbEmxMbF/zBLBVMGZnLtHk6F9VBvmC+jwch8U4IN9uZRJ5
8O/7yBIulJk4kA6WLjiHw4VT3RU=
--------------ms827920EF4A00B5D95C669059--