RE: SCVP-15

["Michael Myers" <[e-mail]>]

3379's definitions work well for 3379, but I think the document should
say that with respect to 3379, "DPD" in this document (i.e. SCVP) means
a request where:

1. certChecks contains at most id-stc-build-pkc-path; AND

2. wantBack contains at most either one or both of
   {id-swb-pkc-cert-path, id-swb-pkc-revocation-info}.

while "DPV" means a request that includes any of the other values
defined for use in these two elements.

Mike

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Trevor Freeman
Sent: Friday, July 30, 2004 10:38 PM
To: Michael Myers; [e-mail]
Subject: RE: SCVP-15



Hi Mike,
Sorry for the slow response but I am on vacation so am not reading mail
as frequently as normal. I agree with your point on needing clear
definitions for DPD and DPV but I think the ones provided in 3379 are
adequate. That would simply require adding references to sections 2 and
3 of the RFC.

Do you agree?
Trevor

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Michael Myers
* Sent: Thursday, July 22, 2004 11:43 AM
* To: [e-mail]
* Subject: Re: SCVP-15
*
*
* Trevor,
*
* Section 3.2.10, extracted below, is a good step forward to closure on
* the issue.  Given its definition as a BOOLEAN in Query syntax, I am
* comfortable with its default to TRUE.
*
* The second paragraph however needs an implementable definition of DPD
* vice DPV with respect to SCVP ASN.1 in order to assert that that a
* request is in error if it asks for a validation assertion in the
context
* of signResponse set to FALSE.
*
* Mike
*
*
*
*
* 3.2.10 signResponse
*
*   The signResponse specifies if the client requires the server to
*   sign a response to the validation request. If the client is
*   performing full chain validation on the response and it is not
*   concerned about the authenticity of the source of the data, then
*   the client does not benefit from the signature on the response in
*   which case it can indicate to the server that the signature is
*   unnecessary via the signResponse value.
*
*   SCVP clients that support DPD MUST support setting this value to
*   FALSE. Since DPV responses must be signed, DPV only SCVP clients
*   MUST NOT to support this value. SCVP servers SHOULD support
*   returning unsigned responses. It is a local policy decision on the
*   part of the server to return signed or unsigned responses if this
*   value is set to FALSE.
*







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VF8K4O074524; Sat, 31 Jul 2004 08:08:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VF8KM3074523; Sat, 31 Jul 2004 08:08:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VF8JfJ074517 for <[e-mail]>; Sat, 31 Jul 2004 08:08:19 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6VF8I892619; Sat, 31 Jul 2004 08:08:18 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, <[e-mail]>
Subject: RE: SCVP-15
Date: Sat, 31 Jul 2004 08:07:31 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

3379's definitions work well for 3379, but I think the document should
say that with respect to 3379, "DPD" in this document (i.e. SCVP) means
a request where:

1. certChecks contains at most id-stc-build-pkc-path; AND

2. wantBack contains at most either one or both of
   {id-swb-pkc-cert-path, id-swb-pkc-revocation-info}.

while "DPV" means a request that includes any of the other values
defined for use in these two elements.

Mike

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Trevor Freeman
Sent: Friday, July 30, 2004 10:38 PM
To: Michael Myers; [e-mail]
Subject: RE: SCVP-15



Hi Mike,
Sorry for the slow response but I am on vacation so am not reading mail
as frequently as normal. I agree with your point on needing clear
definitions for DPD and DPV but I think the ones provided in 3379 are
adequate. That would simply require adding references to sections 2 and
3 of the RFC.

Do you agree?
Trevor

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Michael Myers
* Sent: Thursday, July 22, 2004 11:43 AM
* To: [e-mail]
* Subject: Re: SCVP-15
*
*
* Trevor,
*
* Section 3.2.10, extracted below, is a good step forward to closure on
* the issue.  Given its definition as a BOOLEAN in Query syntax, I am
* comfortable with its default to TRUE.
*
* The second paragraph however needs an implementable definition of DPD
* vice DPV with respect to SCVP ASN.1 in order to assert that that a
* request is in error if it asks for a validation assertion in the
context
* of signResponse set to FALSE.
*
* Mike
*
*
*
*
* 3.2.10 signResponse
*
*   The signResponse specifies if the client requires the server to
*   sign a response to the validation request. If the client is
*   performing full chain validation on the response and it is not
*   concerned about the authenticity of the source of the data, then
*   the client does not benefit from the signature on the response in
*   which case it can indicate to the server that the signature is
*   unnecessary via the signResponse value.
*
*   SCVP clients that support DPD MUST support setting this value to
*   FALSE. Since DPV responses must be signed, DPV only SCVP clients
*   MUST NOT to support this value. SCVP servers SHOULD support
*   returning unsigned responses. It is a local policy decision on the
*   part of the server to return signed or unsigned responses if this
*   value is set to FALSE.
*






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V8EcFW004596; Sat, 31 Jul 2004 01:14:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V8EcWo004595; Sat, 31 Jul 2004 01:14:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V8Ebjx004586 for <[e-mail]>; Sat, 31 Jul 2004 01:14:37 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 31 Jul 2004 01:14:37 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 31 Jul 2004 01:14:37 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 31 Jul 2004 01:14:37 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.247]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 31 Jul 2004 01:14:22 -0700
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-ietf-pkix-scvp-15.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Sat, 31 Jul 2004 01:14:39 -0700
Message-ID: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-pkix-scvp-15.txt
thread-index: AcR0y61O5+JpFJqhSoqtt96FZBiJaAB9Sekw
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 31 Jul 2004 08:14:22.0556 (UTC) FILETIME=[62C7D9C0:01C476D6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6V8Ebjx004588
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Denis,
Sorry for the delayed response but I am on vacation. Comments below.
Trevor

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Denis Pinkas
* Sent: Wednesday, July 28, 2004 10:10 AM
* To: pkix
* Subject: Comments on draft-ietf-pkix-scvp-15.txt
* 
* 
* Comments on draft-ietf-pkix-scvp-15.txt
* Simple Certificate Validation Protocol (SCVP) alias
* Complex Certificate Validation Protocol (CCVP).
* 
* 1. The abstract is still omitting to use the term "validation policy".
A
* certificate can only be valid according to a validation policy. A
* certification
* path can only be constructed according to a validation policy.
* 
* The current abstract is:
* 
*   SCVP allows a client to offload certificate handling to a server.
*   The server can provide the client with a variety of valuable
*   information about the certificate, such as whether the certificate
*   is valid, a certification path to a trust anchor, and revocation
*   status.  SCVP has many purposes, including simplifying client
*   implementations and allowing companies to centralize trust and
*   policy management.
* 
* Change the abstract into:
* 
*   SCVP allows a client to offload certificate handling to a server.
*   The server can provide the client with a variety of valuable
*   information about the certificate, such as whether the certificate
*   is valid according to a validation policy, a certification path to
*   one of the trust anchors from a validation policy, and revocation
*   status of every element from a certification path. SCVP has many
*   purposes, including simplifying client implementations and allowing
*   companies to centralize trust and policy management.

[TF] How about

SCVP allows a client to offload certificate handling to a server. The
server can provide the client with a variety of valuable information
about the certificate, such as whether the certificate is valid
according to a validation policy i.e. a certification path to one of the
policies trust anchors, and revocation status of every element from a
certification path conforms to the policy requirements. SCVP has many
purposes, including simplifying client implementations and allowing
companies to centralize trust and policy management.


* 
* 2. Section 1. Introduction
* 
* Some text in this section is incorrect.
* 
* "  The first class of application wants just two things. First, they
*   want confirmation that the public key belongs to the identity named
*   in the certificate.  Second, they want to know if the public key
*   can be used for the intended purpose.  The client completely
*   delegates certification path construction and validation to the
*   SCVP server".
* 
* The rational of the first sentence has noting to do with the second
* sentence.
* Simply looking at the content of the certificate allows to answer the
two
* questions. There is no need to use a server to get that information.


[TF] I disagree that they are unrelated. It is perfectly legitimate to
ask the serve to check aspects of the certificate since this is a minor
increment to the path validation. 

* 
* 
* 3. In section 1.3 Validation Policies the text states:
* 
* " In SCVP, a validation policy can be explicitly expressed by passing
*   all the parameters in the request where the request comprises of a
*   validation algorithm for certificate path processing and the input
*   parameters to the algorithm. Alternatively a validation policy can
*   be indirectly referenced by a mutually agreed value such as an OID
*   or URL where the value indicates either are a partial or full set
*   of parameters necessary to complete the validation."
* 
* The two alternatives should be at the same level, or emphasis should
* even be
* placed on the second alternative.

[TF] you comments makes no sense to me. Can you rephrase.
* 
* In order to support thing clients, it is necessary to be able to
simply
* use an
* OID 

[TF] I disagree that it is necessary for this clients to use an OID.
Untimely is a deployment and implementation decision.

(forget about instable / temporary URLs) which either tells
* everything to
* the server, or if no OID is being used by the client, an OID supplied
by
* the
* server which tells every to the client.

[TF] OIDs are supported in SCVP15 so I don't understand you point.


* 
* Note: URNs could be used, but not URLs.
[TF] URLs are easier and simpler. 
* 
* There is a major difference between a validation policy and a
validation
* algorithm. A validation policy is a set of rules which includes many
* algorithms
* and their associated parameters.
* 
* ValidationAlg is currently defined as:
* 
*     ValidationAlg ::= SEQUENCE {
*       valAlgId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valAlgId OPTIONAL }
* 
* A parameter, called validationPol should be introduced in the query to
* allow the
* use of a simple OID to reference a full policy or to define a
validation
* policy,

[TF] ValidationPolRef allows the use of a simple OID as you describe.
THE request support all common parameters required by pkix and is
extensible. Is there a requirement in 3379 that SCVP 15 does not
support?

* i.e. first a validation algorithm compliant with [PKIX-1] section 6.1
* coming
* with its associated parameters and additional algorithms coming with
their
* associated parameters.

[TF] I missed making validationAlg optional. Once that is corrected I
don't see an issue that requires making the other changes to Validation
policy you discuss..

* 
* ValidationPol should be defined as :
* 
*   ValidationPol ::= CHOICE {
*       valPolRef             OBJECT IDENTIFIER,
*       valPolDef             ValPolRef }
* 
*   ValPolDef ::= SEQUENCE {
*       valPolId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valPolId OPTIONAL }
* 
* When using valPolRef, all algorithms and parameters are fixed.
* When using valPolDef, some parameters may be dynamic.
* 
* The current structure of ValPolicy defined in section 4.11 on page 38,
* would be
* used for the parameters of a specific validation policy defined in
this
* document, i.e. id-svp-defaultValAlg OBJECT IDENTIFIER ::= { id-svp 1 }
* 
* The text should thus not state:
* 
* "When the id-svp-defaultValAlg appears as an valAlgId, the
* parameters MUST be absent."

[TF] Given that all parameters assonated with the default policy can be
expressed elsewhere in the request this is appropriate. As a general
principal since the validation policy is a deployment specific decision,
I don't see how you proposal is workable. Clients cannot be expected to
support any arbitrary set of parameters in order to implement a given
deployment.


* 
* The parameters for the default validation policy shall be the
parameters
* of
* ValPolDef. The overall structure of the request would be greatly
* simplified.
* 
* Note also that the ValidationAlg parameter has been omitted to be
* described at
* the right place, i.e. in sequence after section 3.2.4, but is
described in
* section 3.2.12 as:
* 
* 3.2.12 validationAlg
* 
*   The validationAlg item, defines the validation algorithm to be used
*   by the SCVP server during certificate validation.  The value of
*   this item can be determined by agreement between the client and the
*   server, and is represented as an object identifier.  The server
*   might want to assign additional object identifiers that indicate
*   that some settings are used in addition to others given in the
*   request.  In this way, the validation algorithm object identifier
*   can be a shorthand for some SCVP options, but not others.
* 
*   The validationAlg item uses the ValidationAlg type, which has the
*   following syntax:
* 
*     ValidationAlg ::= SEQUENCE {
*       valAlgId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valAlgId OPTIONAL }
* 
* Path processing is only one of the many checks that can be done, since
* many
* additional checks about the content of the certificate can be done in
* addition
* to the certificate path processing algorithm defined by [PKIX-1] in
* section
* 6.1.1.
* 
* It is thus inappropriate to limit in general the parameters to those
of
* section
* 6.1.1., thus why all parameters associated with a given validation
* algorithm

[TF] SCVP does not limit the parameters to the path processing
parameters. However since those parameters are a common set of
parameters it standardized their  use so they can be reused across
multiple validation policies or validation algorithms use while leaving
room for other to be defined.

* shall always be included in the parameters of ValPolDef.
* 
* The text also states:
* 
* "The SCVP server can assign validation algorithm object identifiers
*   which indicate that some predefined settings are used in addition
*   to values provided in the SCVP request."

[TF] This is true for both the policy and algorithm so this needs to be
expanded to include both in the text.

* 
* Why this ? If the client specifies a validation policy either the
server
* supports it or returns an error. If the client does not specify a
* validation
* policy in its request, then the server has to return the default
* validation
* policy which it has been used (and which may have nothing to do with
the
* so-
* called default validation policy defined in section 3.2.12.1.)
* 
* The following text extracted from the document, highlights the
confusion
* between
* a validation policy and a validation algorithm.
* 
* " For a certification path to be considered valid under a particular
*   validation policy, it MUST be a valid certification path as defined
*   in [PKIX-1] and all validation policy constraints that apply to the
*   certification path MUST be verified.  Applications MAY place
*   additional requirements on the validation algorithm."

[TF] I don't see that as a problem. In the example validation algorithm
given a application such as an email client can be configured to use a
specific validation algorithm because it always wants the name
comparison to be performed. That is totally independent of broader the
validation policy

* 
* 
* 4. In section 3 Validation Request, the text states:
* 
* " All SCVP clients MUST support SignedData for signed requests and
*   responses."
* 
* For certification path discovery signed responses are not necessary,
nor
* are
* signed requests necessary. For certificate validation according to a
* validation
* policy signed responses are necessary, but signed requests are not
* necessary. So
* this requirement should be modified.

[TF] If you read 3.2.10 you will see that a client can request that the
response not be signed. However it is a local policy decision on the
server to sign if this value is set. So a DPD only client has to deal
with signed responses even it is only to decode the response. It is not
required to validate the signature.

* 
* 
* 5. Similar considerations apply for authenticatedData for signed
* requests and
* responses.
* 
* 
* 6. The current query, which is far too complicated, is currently
* composed of 21
* items as follows:
* 
*     Query ::= SEQUENCE {
*      queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
*      checks                   CertChecks,
*      wantBack                 WantBack,
*      validationAlg            ValidationAlg,
*      requestRefHash           BOOLEAN DEFAULT TRUE,
*      fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
*      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
*      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
*      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
*      IsCA                 [4] BOOLEAN DEFAULT FALSE,
*      SignResponse         [5] BOOLEAN DEFAULT TRUE,
*      serverContextInfo    [6] OCTET STRING OPTIONAL,
*      validityTime         [7] GeneralizedTime OPTIONAL,
*      trustAnchors         [8] TrustAnchors OPTIONAL,
*      intermediateCerts    [9] CertBundle OPTIONAL,
*      revInfos            [10] RevocationInfos OPTIONAL,
*      keyUsage            [11] KeyUsage OPTIONAL,
*      extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
*      queryExtensions     [13] Extensions OPTIONAL
*      producedAt          [14] GeneralizedTime OPTIONAL
*      validationPolRef    [15] ValidationPolRef OPTIONAL}
* 
* Taking into consideration the move of the so-called parameters of the
* default
* validation algorithm :
* 
*      validationPol            ValidationPol,
*      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
*      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
*      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
*      IsCA                 [4] BOOLEAN DEFAULT FALSE,
*      trustAnchors         [8] TrustAnchors OPTIONAL,
*      keyUsage            [11] KeyUsage OPTIONAL,
*      extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
* 
* 
* In fact as set of parameters is defined on page 38 as:
* 
*   ValPolicy ::=SEQUENCE  {
*      validationAlg            ValidationAlg,
*      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
*      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
*      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
*      isCA                 [4] BOOLEAN DEFAULT FALSE,
*      trustAnchors         [5] TrustAnchors,
*      keyUsage             [6] KeyUsage OPTIONAL,
*      extendedKeyUsage     [7] ExtKeyUsageSyntax OPTIONAL}
* 
* and it would make sense to use that structure which groups them and
use
* it as
* the parameters to be associated with id-svp 1.
* 
* The query could then be simplified as follows:
* 
*     Query ::= SEQUENCE {
*      queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
*      checks                   CertChecks,
*      wantBack                 WantBack,
*      requestRefHash           BOOLEAN DEFAULT TRUE,
*      fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
*      signResponse         [1] BOOLEAN DEFAULT TRUE,
*      serverContextInfo        OCTET STRING OPTIONAL,
*      validationPol            ValidationPol OPTIONAL,
*      -- if missing in the query, then MUST be present in the response
*      validityTime             GeneralizedTime OPTIONAL,
*      intermediateCerts        CertBundle OPTIONAL,
*      revInfos                 RevocationInfos OPTIONAL,
*      queryExtensions      [2] Extensions OPTIONAL,
*      producedAt           [3] GeneralizedTime OPTIONAL
* }
* 
* Below the new definition of ValidationPol is copied again.
* 
*   ValidationPol ::= CHOICE {
*       valPolRef             OBJECT IDENTIFIER,
*       valPolDef             ValPolDef }
* 
*     ValPolDef ::= SEQUENCE {
*       valPolId              OBJECT IDENTIFIER,
*       parameters            ANY DEFINED BY valPolId OPTIONAL }
* 


[TF] Given that many of the parameters are either defaulted or optional,
I don't agree that moving them around achieves anything other than
document churn. This is a stylistic rater than a technical issue.

* 
* 7. The SCVP response is currently defined on page 27 as follows:
* 
*     CVResponse ::= SEQUENCE {
*       scvpVersion           INTEGER,
*       policyID              INTEGER,
*       producedAt            GeneralizedTime,
*       responseStatus        ResponseStatus,
*       requestRef            RequestReference,
*       requestor         [1] OCTET STRING OPTIONAL,
*       responder         [2] OCTET STRING OPTIONAL,
*       replyObjects      [3] ReplyObjects OPTIONAL,
*       requestNonce      [4] OCTET STRING OPTIONAL,
*       serverContextInfo [5] OCTET STRING OPTIONAL,
*       valPolResponse    [6] ValPolicy OPTIONAL,
*       validationPolRef  [7] ValidationPolicyRef OPTIONAL
*       respExtensions    [8] Extensions OPTIONAL }
* 
* policyID is mandatory and does not make sense when a validation policy
* reference
* is being used. It should be deleted.

[TF] The relevance of the policyID depends on the validation policy so
rather than have the server figure our that dependency, its simpler to
mandate the policyID be present.

* 
* responder is for SCVP server relay only and the text omits to mention
it.

[TF] I will add text to that effect.
* 
* requestor is primarily for SCVP server relay and that this parameter
* should not
* have to be supported by a client.

[TF] A server who relays a request is by definition also a client. Any
client who is not concerned with these values can ignore them. 

* 
* Defining these two parameters as respExtensions would only thin
clients
* and non
* relaying servers to simply forget about them.
* 
* It is thus proposed to simplify the structure as follows:
* 
*     CVResponse ::= SEQUENCE {
*       scvpVersion           INTEGER,
*       requestNonce          OCTET STRING OPTIONAL,
*       producedAt            GeneralizedTime,
*       requestRef            RequestReference,
*       validationPol         ValidationPol OPTIONAL,
*       -- if missing in the query, then MUST be present
*       responseStatus        ResponseStatus,
*       replyObjects      [1] ReplyObjects OPTIONAL,
*       serverContextInfo [2] OCTET STRING OPTIONAL,
*       respExtensions    [3] Extensions OPTIONAL }
* 
* 
* 8. The Server Policies Request is currently defined on page 40 as
follows:
* 
*     PolRequest ::= SEQUENCE {
*       scvpVersion                INTEGER }
* 
* The current idea is to use a mechanisms similar to the CRL mechanism
to
* detect
* if the response is current or is a replay. It should be able to
support
* a nonce.
* 
* The structure should thus be changed to:
* 
*     PolRequest ::= SEQUENCE {
*       scvpVersion                INTEGER,
*       requestNonce               OCTET STRING OPTIONAL }


[TF] Agreed.

* 
* 
* 9. The Server Policies Response is currently defined on page 40 as
* follows:
* 
*     PoliciesResponse ::= SEQUENCE {
*       scvpVersion                INTEGER,
*       DefaultPolicyID            INTEGER,
*       thisUpdate                 GeneralizedTime,
*       nextUpdate                 GeneralizedTime,
*       trustAnchors               TrustAnchors,
*       validationPolices          SEQUENCE OF ValidationPolRef,
*       validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
*       authPolicies               SEQUENCE OF AuthPolicy,
*       responseTypes              ResponseTypes,
*       defaultValPol              ValPolicy,
*       clockSkew                  INTEGER OPTIONAL,
*       authDataCert               Certificate OPTIONAL }
* 
* 
* DefaultPolicyID and defaultValPol do not need to be present, 

[TF] The PolicyID is the server policy so needs to be present.

* default
* policy may simply be the first policy of the SEQUENCE of validation
* policies
* that is returned.
* 
* nextUpdate should be OPTIONAL since a server may choose to always send
a
* fresh
* response.
[TF] simply omitting the nextUpdate by itself is ambiguous sine the
client cannot tell if the policy is in response to the request or has
infinite lifetime. If the client submits a nonce then the server can
either return a fresh policy or the cached version. If the client omits
the nonce then the server MUST return the cached version with the
nextUpdate.

* 
* trustAnchors is a parameter of one specify validation policy and thus
* should not
* be present at that level.

[TF] Clients are not mandated to use validation policy so this is
appropriate at this level

* 
* validationPolices should be used to define a sequence of validation
policy
* references and/or a sequence of validation policy definitions. See
below.
* 
* validationAlgs may be inner component of validation policy definition.

[TF] Again validation policies are not mandatory in deployments.

* 
* authPolicies is unclear, since all responses MUST be signed. 

[TF] This is for auth to the server.

Deleted for
* simplification.
* 
* defaultValPol is not needed, if the default policy is simply the first
* policy of
* the SEQUENCE of validation policies that is returned.
* 
* The name of authDataCert should be changed into serverCert.

[TF] The authDataCert is the certificate used for the authenticated data
requests/responses. The name differentiates it form the signing cert
returned in the CMS envelope.

* 
* The structure should thus be changed to:
* 
*     PoliciesResponse ::= SEQUENCE {
*       scvpVersion                INTEGER,
*       responseNonce              OCTET STRING OPTIONAL,
*       thisUpdate                 GeneralizedTime,
*       nextUpdate                 GeneralizedTime OPTIONAL,
*       validationPolicies         SEQUENCE OF ValidationPol,
*       -- the default validation policy is the first of the sequence
*       responseTypes              ResponseTypes,
*       clockSkew                  INTEGER OPTIONAL,
*       serverCert                 Certificate OPTIONAL }

[TF] The revised SCVP server policy response is now

PoliciesResponse ::= SEQUENCE {
    scvpVersion                INTEGER,
    DefaultPolicyID            INTEGER,
    thisUpdate                 GeneralizedTime,
    nextUpdate                 GeneralizedTime OPTIONAL,
    trustAnchors               TrustAnchors,
    validationPolices          SEQUENCE OF ValidationPolRef,
    validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
    authPolicies               SEQUENCE OF AuthPolicy,
    responseTypes              ResponseTypes,  
    defaultValPol              ValPolicy,           
    clockSkew                  INTEGER OPTIONAL,
    requestNonce               OCTET STRING OPTIONAL,
    authDataCert               Certificate OPTIONAL }
* 
* 
* Denis
* 
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V5bepj050162; Fri, 30 Jul 2004 22:37:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V5beg4050160; Fri, 30 Jul 2004 22:37:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V5bdPR050127 for <[e-mail]>; Fri, 30 Jul 2004 22:37:39 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 30 Jul 2004 22:37:44 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Jul 2004 22:37:44 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Jul 2004 22:37:43 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jul 2004 22:38:12 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP-15
Date: Fri, 30 Jul 2004 22:37:42 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP-15
thread-index: AcRwIL4Nn5hmHS3ES22EU5RBR7YtVAGnz2kQ
From: "Trevor Freeman" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 31 Jul 2004 05:38:12.0782 (UTC) FILETIME=[91F5CCE0:01C476C0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6V5bdPR050152
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Mike,
Sorry for the slow response but I am on vacation so am not reading mail
as frequently as normal. I agree with your point on needing clear
definitions for DPD and DPV but I think the ones provided in 3379 are
adequate. That would simply require adding references to sections 2 and
3 of the RFC.

Do you agree?
Trevor

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Michael Myers
* Sent: Thursday, July 22, 2004 11:43 AM
* To: [e-mail]
* Subject: Re: SCVP-15
* 
* 
* Trevor,
* 
* Section 3.2.10, extracted below, is a good step forward to closure on
* the issue.  Given its definition as a BOOLEAN in Query syntax, I am
* comfortable with its default to TRUE.
* 
* The second paragraph however needs an implementable definition of DPD
* vice DPV with respect to SCVP ASN.1 in order to assert that that a
* request is in error if it asks for a validation assertion in the
context
* of signResponse set to FALSE.
* 
* Mike
* 
* 
* 
* 
* 3.2.10 signResponse
* 
*   The signResponse specifies if the client requires the server to
*   sign a response to the validation request. If the client is
*   performing full chain validation on the response and it is not
*   concerned about the authenticity of the source of the data, then
*   the client does not benefit from the signature on the response in
*   which case it can indicate to the server that the signature is
*   unnecessary via the signResponse value.
* 
*   SCVP clients that support DPD MUST support setting this value to
*   FALSE. Since DPV responses must be signed, DPV only SCVP clients
*   MUST NOT to support this value. SCVP servers SHOULD support
*   returning unsigned responses. It is a local policy decision on the
*   part of the server to return signed or unsigned responses if this
*   value is set to FALSE.
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UDN08i061442; Fri, 30 Jul 2004 06:23:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UDN0kf061440; Fri, 30 Jul 2004 06:23:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan03.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6UDMnn9061407 for <[e-mail]>; Fri, 30 Jul 2004 06:22:49 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 17902 invoked by alias); 30 Jul 2004 13:22:42 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 17892 invoked by alias); 30 Jul 2004 13:22:41 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 30 Jul 2004 13:22:41 -0000
Received: (qmail 23911 invoked from network); 30 Jul 2004 13:22:41 -0000
Received: from unknown (HELO ?192.168.1.5?) (172.30.253.98) by mail with SMTP; 30 Jul 2004 13:22:41 -0000
Date: Fri, 30 Jul 2004 22:22:48 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, [e-mail]
Subject: multi-domain PKI unofficial BoF
Cc: [e-mail]
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.11.02 [ja]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

# Sorry for any cross-postings.

I am going to hold a unofficial BoF for Best Current Practice (BCP) of multi-domain
PKI in the 60th IETF meeting at San Diego.

Date/Time and Room are not decided yet, but it will be held at Aug 4 or
5. If you have interest in this issue, please check your mailing list and
board at IETF reception. I will announce additional information there.

Purpose of this BoF is to make a consensus of the following:
* What is the multi-domain PKI?
* What is the problem in multi-domain PKI?
* Shall we solve this problem?

Summary:
There are many PKIs in the actual world, and they have of course
different architectures and different policies.
So when some PKIs assemble, it will bring some problems.
Assembling the PKIs is hard problem because it may require full understanding of not only PKI but LDAP and so on.
Therefore, I think that we should show some technical idea about assembling PKIs.

My opinion for this theme is described in my following personal I-D:
    http://www.jnsa.org/mpki/draft-shimaoka-multidomain-pki-04-20040730r1.txt

If we make a rough consensus, following this discussion I would like to
review my I-D with you.


Thanks,
shima

-----
Masaki SHIMAOKA

SECOM Trust.net
Tel: [phone] (ext.3635); Mitaka
Tel: [phone] (ext.3485); Harajuku
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U6NAnZ041918; Thu, 29 Jul 2004 23:23:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6U6NApB041917; Thu, 29 Jul 2004 23:23:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon1-mail-1.visp.demon.net (IDENT:[e-mail] [193.195.70.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U6MuSV041770 for <[e-mail]>; Thu, 29 Jul 2004 23:23:09 -0700 (PDT) (envelope-from [e-mail])
Received: from salford.ac.uk (adslbcn-1-139.easynet.es [62.93.178.139] (may be forged)) by lon1-mail-1.visp.demon.net (MOS 3.4.6-GR) with ESMTP id BMC16460 (AUTH [e-mail]); Fri, 30 Jul 2004 07:11:27 +0100 (BST)
Message-ID: <[e-mail]>
Date: Fri, 30 Jul 2004 07:09:52 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Chadwick CHADWICK <[e-mail]>
Subject: 8th IFIP TC-6 TC-11 Conference on Communications and Multimedia Security
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry for any cross postings, but it is the last few days for reduced
registration fees,
regards
David

======================================
Eighth IFIP TC-6 TC-11 Conference on
Communications and Multimedia Security
======================================

15-18 September 2004

CALL FOR PARTICIPATION

Please register online at:
https://venables-0179.salford.ac.uk/eCMS2004/

A discount is available for early registration (before July 31st 2004).

The Eighth IFIP Conference on Communications and Multimedia Security
will be held at the Beech Hill Hotel, overlooking Lake Windermere in the
beautiful Emglish Lake District.

The opening keynote speech will be given by Karl-Heinz Brandenburg, the
inventor of MP3, who will talk about Digital Rights Management issues.

En exciting programme has been organised, with Sessions:

- - Privacy/Anonymity
- - Mobile Security
- - Digital Signatures
- - Cryptography
- - Multimedia Security
- - Application Level Security

A panel session will be ogranised on "Security in Microsoft .Net"

On the final day (Saturday) walks will be arranged around the lakes or,
for the more intrepid participants, over the mountains.

A full programme may be found on the conference website at:

http://sec.isi.salford.ac.uk/cms2004/Program/index.html

The conference is organized by the Informatics Research Institute and
the Information Systems Security Research Group at the University of
Salford.

Informal enquiries may be addressed to: [e-mail]

We look forward to hearing from you and seeing you in September.

Best wishes,

Professor David Chadwick: Programme Chair
Professor Grahame Cooper: Organizing Chair



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TKPUIs003103; Thu, 29 Jul 2004 13:25:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TKPUnC003102; Thu, 29 Jul 2004 13:25:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TKPT3n003096 for <[e-mail]>; Thu, 29 Jul 2004 13:25:29 -0700 (PDT) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6TKNG53029575 for <[e-mail]>; Thu, 29 Jul 2004 14:23:16 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 29 Jul 2004 16:25:33 -0400 (EDT)
Received: from sun.com (dhcp-ubur02-75-154.East.Sun.COM [129.148.75.154]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Thu, 29 Jul 2004 16:25:33 -0400 (EDT)
Date: Thu, 29 Jul 2004 16:15:14 -0400
From: Steve Hanna <[e-mail]>
Subject: Re: New I-D on Intl Strings in Certs
In-reply-to: <[e-mail]>
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=------------ms050700070501020205040605
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031111
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Russ Housley wrote:
 > I would like to see an additional section in this document.  When
 > otherName forms are registered, some of these will in include text
 > strings.  However, they will probably not make use of GeneralName or
 > Name.  Therefore, I think it would be useful to list the ASN.1 types
 > where these rules should be applied.  UTF8String is obvious.  What
 > else?

In my experience, many name forms have their own matching
rules. For instance, DNS names are case-insensitive.
RFC822Names use receiver-specific matching conventions in
the localpart and case-insensitive matching for the domain.

I'd be reluctant to specify any rules for future name forms,
but maybe we can come up with some guidelines. For instance,
we could say that name forms that include Unicode strings
(BMPString, UnicodeString, or UTF8String) SHOULD consider
using a variant of the stringprep algorithm and MUST specify
a clear, well-defined algorithm for name matching or
prohibit the use of these name forms in name constraints.

Would that address your concern?

Thanks,

Steve

P.S. Maybe this document should describe how to handle
international characters when matching DNS names, URIs,
and RFC 822 names in certificates (in name constraints).
But I'd be inclined to specify these in separate documents,
especially since internationalization of email addresses
is not settled yet.

--------------ms050700070501020205040605
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJNzCC
AvYwggJfoAMCAQICAww3ZDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDI4MjEwMTE0WhcNMDUwNDI4MjEwMTE0
WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYDVQQDExJT
dGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1bi5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC11rLYp70KnKGmV6pNTFRhWBwq47mV
4hU6EaZxo6I3Vw96Rd3E4TH3SAthIl5N4/tpiMPtlTBiJOU6QHSlz1DgTCclmTK6taqtEyLq
amez8vYgSdOEnOFRYILptjbEwpE+yeUmFKOmZ7zSwBMqRQatMHMaLVUJJ3Ygw1V7fKSwvVU0
OJ8c+c3sJRtRyDLxq/vMzYQP+wyqRqlJPTHGFqVuMp0FZIV5X76z+O+W90m9jXjirz91Jz+W
N6rwqmPi8Qy0uxBKm6NKT1371p+WYaK9OfGk8vGbJ8ZsTP3DyQhuuemYPbkKPtoII6WnHIGT
/DOy2G7gff7GOIhUrs7PziddAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhhbm5hQHN1
bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB++aOP6sZVYlqBGc92hZ61
FHST+OqnKZHRGkqEO94RoxdeaSUFKVO2IaKLMBmqNzmh3N3pIsIKiLhJNvDgLhlRrMRVfR29
uixjTsprR26AacMx/gCiCstGIjkzTb83xAvZay5hnzUmlt/LSNX8e6jTNav6LP64WC+C7Tul
fM/PzDCCAvYwggJfoAMCAQICAww3ZDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDI4MjEwMTE0WhcNMDUwNDI4
MjEwMTE0WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYD
VQQDExJTdGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1
bi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC11rLYp70KnKGmV6pNTFRh
WBwq47mV4hU6EaZxo6I3Vw96Rd3E4TH3SAthIl5N4/tpiMPtlTBiJOU6QHSlz1DgTCclmTK6
taqtEyLqamez8vYgSdOEnOFRYILptjbEwpE+yeUmFKOmZ7zSwBMqRQatMHMaLVUJJ3Ygw1V7
fKSwvVU0OJ8c+c3sJRtRyDLxq/vMzYQP+wyqRqlJPTHGFqVuMp0FZIV5X76z+O+W90m9jXji
rz91Jz+WN6rwqmPi8Qy0uxBKm6NKT1371p+WYaK9OfGk8vGbJ8ZsTP3DyQhuuemYPbkKPtoI
I6WnHIGT/DOy2G7gff7GOIhUrs7PziddAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhh
bm5hQHN1bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB++aOP6sZVYlqB
Gc92hZ61FHST+OqnKZHRGkqEO94RoxdeaSUFKVO2IaKLMBmqNzmh3N3pIsIKiLhJNvDgLhlR
rMRVfR29uixjTsprR26AacMx/gCiCstGIjkzTb83xAvZay5hnzUmlt/LSNX8e6jTNav6LP64
WC+C7TulfM/PzDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG
SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBa
Fw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs
dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRw
nd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn
8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg
t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0
dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1Ud
DwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJ
KoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A
9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH
1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDDdkMAkGBSsOAwIa
BQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcy
OTIwMTUxNFowIwYJKoZIhvcNAQkEMRYEFAlmvyUikceHTB3a/dextANXkKYmMFIGCSqGSIb3
DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG
BSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMN2QwegYLKoZIhvcNAQkQAgsxa6Bp
MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu
MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDDdkMA0G
CSqGSIb3DQEBAQUABIIBADzCm5StxmcokSbrFPQ22HwXkM7mOdYc6ko7bIhBo0eigXdhK9Uh
kKFNc53Q6FjqJUzPlIvxkO0mdlKJM9MxsgboLsP0Bs3pRCy3UIvk+G6HpC38yVrWyKkd8Dyh
mploKUlkPi4nvs+ncNv72qOhR4iytGaGH8UCBkMDlTvo8nLPxsTC/jniDP6qBHTpd30tX803
0uz5ti0uKidCXyMyHszqWBrx8Wrb2TPDV2p8VDWO1Vfz8xelbitiX8hYTktmzuX0jYIl5+nf
JH8yLULiG0ffDk0M8OYT45IjqeTuhS29YldhglL2Z+EV/TIaKNOZ8DHCGM3BBVtC3e/DweL4
7tQAAAAAAAA=
--------------ms050700070501020205040605--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TKPPw4003084; Thu, 29 Jul 2004 13:25:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6TKPPIl003083; Thu, 29 Jul 2004 13:25:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TKPLXx003067 for <[e-mail]>; Thu, 29 Jul 2004 13:25:22 -0700 (PDT) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6TKN757029503 for <[e-mail]>; Thu, 29 Jul 2004 14:23:08 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 29 Jul 2004 16:25:25 -0400 (EDT)
Received: from sun.com (dhcp-ubur02-75-154.East.Sun.COM [129.148.75.154]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Thu, 29 Jul 2004 16:25:25 -0400 (EDT)
Date: Thu, 29 Jul 2004 16:15:05 -0400
From: Steve Hanna <[e-mail]>
Subject: Re: New I-D on Intl Strings in Certs
In-reply-to: <E1BlUgC-00059V-CV@medusa01>
To: Peter Gutmann <[e-mail]>
Cc: [e-mail], Steve Hanna <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=------------ms000908030802010008090303
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031111
References: <E1BlUgC-00059V-CV@medusa01>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Peter,

I apologize for taking so long to respond to
your email. I'm changing jobs (moving from
Sun to a small software company, Funk Software).
Arranging the changeover has kept me busy.
Unfortunately, I won't be able to attend
IETF 60 next week since that will be my first
week at Funk. But I hope things will continue
smoothly on Monday. My new email address will
be [e-mail]. Anyway, on to business.
Let me respond to your comments.

Peter Gutmann wrote:
> Steve Hanna <[e-mail]> writes:
>>Path validation will fail when a relying party uses binary comparison to
>>match X.500 names that differ slightly if the match is performed as part of
>>subject-issuer name chaining or permittedSubtrees processing.
> 
> This begs the question of "Why the &*^#&$# would any CA in its right mind ever
> issue a certificate where the issuer.suject DN gratuitously differs from the
> subject.issuer DN by an extra space or something similar?".  You'd have to
> deliberately add code to break the DN as it goes from parent to child.  Why
> not say:
> 
>   Any CA that issues certificates where the issuer.suject DN gratuitously
>   differs from the subject.issuer DN should be considered broken, with
>   handling of its certs not guaranteed by this specification.
> 
> (you can rephrase that as MUST and whatnot if you want).

In general, I agree that it's best to avoid any
differences between the subject name of one
certificate and the issuer name of the next.
However, there are times when such a difference
is inevitable. For example, some CAs require
(because of technical or policy reasons) that
a particular encoding be used in all certs
that they issue. This encoding may differ from
the one used by other CAs for the same names.

More important is the problem of name constraints.
It's common for a certificate to include a name
constraint which applies to subject names and
subject alternative names in many other certificates.
These certificates may use different encodings for
those subject names and subject alternative names
than the one used in the name constraint. They may
also have minor differences in capitalization or
spacing. Therefore, it's important to support matching
distinguished names while ignoring unimportant
differences (as described in X.509).

 >>This algorithm SHOULD NOT be used for matching CRL
 >>distribution point names or cRLIssuer. A binary
 >>comparison SHOULD be used for such mapping.
 >
 > Is there any reason why binary comparison is OK for finding
 > who issued a CRL, but not for who issued a cert?

As you said above, its better to use binary matching
when possible. In this case, I don't see any reason
not to. A CA should easily be able to provide an
exact binary value for CRL distribution point name
and cRLIssuer. Also, the only binding between a
certificate and its CRL issuer is the name (cRLIssuer).
With subject-issuer name chaining, the subject public
key of a certificate must verify the signature on the
subsequent certificate. This reinforces the need to
avoid malicious or accidental mismatches with cRLIssuer.

>>More substantial problems can occur if a relying party uses binary comparison
>>to determine that an X.500 name does not match excludedSubtrees and the CA
>>expected that it would match because of the more lenient processing.
> 
> It doesn't matter what algorithm they use, you can always escape
> excludedSubtrees by clever encoding of your DNs (see the X.509 style guide for
> the details).  The draft should warn (like the RFC currently does) that you
> can't rely on excludedSubtrees to exclude certs from non-cooperating cert
> issuers (that is, ones that will create DNs with strings encoded so as to
> avoid the exclusion).

I agree that using excludedSubTrees is not a good idea.
We'll strengthen the wording in the next revision.

Thanks,

Steve

--------------ms000908030802010008090303
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJNzCC
AvYwggJfoAMCAQICAww3ZDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDI4MjEwMTE0WhcNMDUwNDI4MjEwMTE0
WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYDVQQDExJT
dGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1bi5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC11rLYp70KnKGmV6pNTFRhWBwq47mV
4hU6EaZxo6I3Vw96Rd3E4TH3SAthIl5N4/tpiMPtlTBiJOU6QHSlz1DgTCclmTK6taqtEyLq
amez8vYgSdOEnOFRYILptjbEwpE+yeUmFKOmZ7zSwBMqRQatMHMaLVUJJ3Ygw1V7fKSwvVU0
OJ8c+c3sJRtRyDLxq/vMzYQP+wyqRqlJPTHGFqVuMp0FZIV5X76z+O+W90m9jXjirz91Jz+W
N6rwqmPi8Qy0uxBKm6NKT1371p+WYaK9OfGk8vGbJ8ZsTP3DyQhuuemYPbkKPtoII6WnHIGT
/DOy2G7gff7GOIhUrs7PziddAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhhbm5hQHN1
bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB++aOP6sZVYlqBGc92hZ61
FHST+OqnKZHRGkqEO94RoxdeaSUFKVO2IaKLMBmqNzmh3N3pIsIKiLhJNvDgLhlRrMRVfR29
uixjTsprR26AacMx/gCiCstGIjkzTb83xAvZay5hnzUmlt/LSNX8e6jTNav6LP64WC+C7Tul
fM/PzDCCAvYwggJfoAMCAQICAww3ZDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDI4MjEwMTE0WhcNMDUwNDI4
MjEwMTE0WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYD
VQQDExJTdGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1
bi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC11rLYp70KnKGmV6pNTFRh
WBwq47mV4hU6EaZxo6I3Vw96Rd3E4TH3SAthIl5N4/tpiMPtlTBiJOU6QHSlz1DgTCclmTK6
taqtEyLqamez8vYgSdOEnOFRYILptjbEwpE+yeUmFKOmZ7zSwBMqRQatMHMaLVUJJ3Ygw1V7
fKSwvVU0OJ8c+c3sJRtRyDLxq/vMzYQP+wyqRqlJPTHGFqVuMp0FZIV5X76z+O+W90m9jXji
rz91Jz+WN6rwqmPi8Qy0uxBKm6NKT1371p+WYaK9OfGk8vGbJ8ZsTP3DyQhuuemYPbkKPtoI
I6WnHIGT/DOy2G7gff7GOIhUrs7PziddAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhh
bm5hQHN1bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB++aOP6sZVYlqB
Gc92hZ61FHST+OqnKZHRGkqEO94RoxdeaSUFKVO2IaKLMBmqNzmh3N3pIsIKiLhJNvDgLhlR
rMRVfR29uixjTsprR26AacMx/gCiCstGIjkzTb83xAvZay5hnzUmlt/LSNX8e6jTNav6LP64
WC+C7TulfM/PzDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG
SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBa
Fw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs
dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRw
nd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn
8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg
t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0
dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1Ud
DwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJ
KoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A
9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH
1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDDdkMAkGBSsOAwIa
BQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcy
OTIwMTUwNVowIwYJKoZIhvcNAQkEMRYEFK9VFo8ULZtVOlT7HDWyIbT10gRiMFIGCSqGSIb3
DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG
BSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMN2QwegYLKoZIhvcNAQkQAgsxa6Bp
MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu
MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDDdkMA0G
CSqGSIb3DQEBAQUABIIBABtujhoDdQn729OTDg/NAVyknc1qAy8YKxTYr66tSZmq8Twuzfq/
jM10M3/z3GtUJHu9pm1a6b94jNEAnnqQT3pUVZuhel4WhgH5dZ/7NwQUC873JhD1uTvhZ+J4
1euZZ0+t8fg5d4K6239xrBwIaJRuTuoJJmZE0MZafysGOWKvKwumEsjDDx8kQrs0p/OXjbtm
/5KNb5xcbCWgGjuAVdskQnvBujzb4ziPEXJjrSnJVA9OqAFLJzR7HUO/Ee8youQuz/mZSAxU
cgoD49GLDOz62iLcl8YrDlFDeTWCbYiCxryZkVJJmYJMO8lSoZZ5UpSkDpiYaVG3FicJLFUF
3sgAAAAAAAA=
--------------ms000908030802010008090303--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T77DI2078369; Thu, 29 Jul 2004 00:07:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6T77D4I078368; Thu, 29 Jul 2004 00:07:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T77B9T078314 for <[e-mail]>; Thu, 29 Jul 2004 00:07:12 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA22342; Thu, 29 Jul 2004 09:17:31 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA24252; Thu, 29 Jul 2004 09:07:05 +0200
Message-ID: <[e-mail]>
Date: Thu, 29 Jul 2004 09:05:43 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Comments on SCVP15
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

I am in general agreement with the *technical* comments you sent.

The current version of SCVP is still not compliant with RFC 3379.
A large amount of work still needs to be done on this draft.

It is also a pitty that the new draft (15) has only be officially 
distributed on July 20.

On May 17, Trevor said: "I will be posting SCVP 15 shortly so you can review 
the latest draft." I replied: "An extract of the proposal sent to the 
mailing list and targeted to this problem would probably save another round."

Should I undertstand that, for Trevor, "shortly" practically means "more 
than 2 months" ?

Now awaiting SCVP-16 ... or much better, before issuing it, a response to 
the many technical comments raised on this mailing list on SCVP-15.

Denis

(as "someone participating in this list who agrees with something or 
considers it as useful").


> it seems to me that some of the results of discussions between
> the editor and me have been forgotten or so.
> 
> 
> I still think that the scvp is not conformant to RFC 3379
> and/or the editors has not done something as announced.
> 
> 1) RFC 3379 says: 
>    The DPV request MUST allow the client to request that the server
>    include in its response additional information which will allow
>    relying parties not trusting the DPV server to be confident that the
>    certificate validation has correctly been performed.  Such
>    information may (not necessarily exclusively) consist of a
>    certification path, revocation status information from authorized CRL
>    issuers or authorized OCSP responders, revocation status information
>    from CRL issuers or OCSP responders trusted under the validation
>    policy, time-stamp tokens from TSAs responders trusted under the
>    validation policy, or a DPV response from a DPV server that is
>                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> 
>    trusted under the validation policy.  When the certificate is valid
>    according to the validation policy, the server MUST, upon request,
>    include that information in the response.  However, the server MAY
>    omit that information when the certificate is invalid or when it
>    cannot determine the validity.
> 
>    ==> no provision (as far as I see).
> 
> 
> 2) RFC 3379 says:
>    When the DPV request is authenticated, the client SHOULD be able to
>    include a client identifier in the request for the DPV server to copy
>    into the response.  Mechanisms for matching this identifier with the
>    authenticated identity depends on local DPV server conditions and/or
>    the validation policy.  The DPV server MAY choose to blindly copy the
>    identifier, omit the identifier, or return an error response.
> 
> The current text is SCVP says: 
> 
>   The OPTIONAL requestor item is used to identify the requestor.  The 
>   value is only of local significance to the requestor.  If the SCVP 
>   client includes a requestor value in the request, then the SCVP 
>   server MUST return the same value if the server is generating a 
>   specific response. 
> 
> 
> tf also said:
> 
> 
>>Given there are plenty of ways a client can generate a "unique" as well
>>as other behaviors like it can encode a DN in the octet sting if it
>>likes I don't see a problem. Its down to the client to do what it thinks
>>fit. The value is simply replayed by the server so it is treated a
>>binary blob.
> 
> 
> There is nothing else possible for the server except copying, or,
> no mechanisms to match this with the some authenticated entity 
> can be safely developped if it is solely 'up to the client to encode whatever'. 
> 
> I had proposed two changes to the logic of 0 terminated octet strings by: 
> 
> - a sequence of octet strings allowing a real opaque string.
> - a choice of generalname
> 
> I.e.
> 
>    Identifiers ::= SEQUENCE OF { 
>           CHOICE {
>                opaqueId OCTET STRING,
>                nameId GeneralName
>           }
> 
> No comment to this proposition as far as I remember. 
> 
> 3) In May 204 trevor wrote:
> 
> 
>>I think we can use the Cert sign bit in key usage so the is CA bit can
>>be removed from SCVP15
> 
> 
> which was not done. 
> 
> 4) Somewhat related to this, and to the provisions to search in DPD or validate
>    in DPV several types of extensions, I had proposed to opetionally search
>    for the pathlength basicconstraint. if for example a client has a
>    cert and a CA cert then one could use it to search only for CAs that
>    have at least a pathlength of 1.
>   
> 
> I seem to understand that the rule in this WG is:
> 
> - editor, chairmen, iesg says something ==> accepted if no response
> - others ==> rejected if no response from anyone.
> 
> all totally independant of the content of the comment. 
> 
> At least point 3 doesn't fit into this rule.
> 
> I'd like to to see whether there is someone participating
> in this list who agrees with something or considers it as useful ...
> 
> Thanks for consideration
> Peter 
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T3aXas088625; Wed, 28 Jul 2004 20:36:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6T3aXNN088624; Wed, 28 Jul 2004 20:36:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T3aVaY088588 for <[e-mail]>; Wed, 28 Jul 2004 20:36:32 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 8D1941CD922; Thu, 29 Jul 2004 15:34:09 +1200 (NZST)
Received: from pgut001 by medusa01 with local (Exim 4.32) id 1Bq1ia-0003Eg-I7; Thu, 29 Jul 2004 15:36:32 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Time-Stamp Protocol (TCP-based protocol)
In-Reply-To: <[e-mail]>
Message-Id: <E1Bq1ia-0003Eg-I7@medusa01>
Date: Thu, 29 Jul 2004 15:36:32 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

mario ivkovic <[e-mail]> writes:

>If the client sends a tsaMsg to a tsa server and the server answers with
>partialMsgRep, who is responsible for closing the tcp/ip connection? (client
>or server)

Whoever puts "Connection: Close" in the HTTP header.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SH78EY035600; Wed, 28 Jul 2004 10:07:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SH78pw035599; Wed, 28 Jul 2004 10:07:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SH76s3035551 for <[e-mail]>; Wed, 28 Jul 2004 10:07:07 -0700 (PDT) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA48790 for <[e-mail]>; Wed, 28 Jul 2004 19:17:24 +0200
Received: from bull.net ([129.181.81.11]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004072819065685:2079 ; Wed, 28 Jul 2004 19:06:56 +0200 
Message-ID: <[e-mail]>
Date: Wed, 28 Jul 2004 19:09:47 +0200
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Comments on draft-ietf-pkix-scvp-15.txt
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/07/2004 19:06:59, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/07/2004 19:07:01, Serialize complete at 28/07/2004 19:07:01
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments on draft-ietf-pkix-scvp-15.txt
Simple Certificate Validation Protocol (SCVP) alias
Complex Certificate Validation Protocol (CCVP).

1. The abstract is still omitting to use the term "validation policy". A
certificate can only be valid according to a validation policy. A 
certification
path can only be constructed according to a validation policy.

The current abstract is:

  SCVP allows a client to offload certificate handling to a server.  
  The server can provide the client with a variety of valuable
  information about the certificate, such as whether the certificate
  is valid, a certification path to a trust anchor, and revocation
  status.  SCVP has many purposes, including simplifying client
  implementations and allowing companies to centralize trust and
  policy management.

Change the abstract into:

  SCVP allows a client to offload certificate handling to a server.  
  The server can provide the client with a variety of valuable
  information about the certificate, such as whether the certificate
  is valid according to a validation policy, a certification path to
  one of the trust anchors from a validation policy, and revocation
  status of every element from a certification path. SCVP has many
  purposes, including simplifying client implementations and allowing
  companies to centralize trust and policy management.


2. Section 1. Introduction

Some text in this section is incorrect.

"  The first class of application wants just two things. First, they
  want confirmation that the public key belongs to the identity named
  in the certificate.  Second, they want to know if the public key
  can be used for the intended purpose.  The client completely
  delegates certification path construction and validation to the
  SCVP server".

The rational of the first sentence has noting to do with the second 
sentence.
Simply looking at the content of the certificate allows to answer the two
questions. There is no need to use a server to get that information.


3. In section 1.3 Validation Policies the text states:

" In SCVP, a validation policy can be explicitly expressed by passing
  all the parameters in the request where the request comprises of a
  validation algorithm for certificate path processing and the input
  parameters to the algorithm. Alternatively a validation policy can
  be indirectly referenced by a mutually agreed value such as an OID
  or URL where the value indicates either are a partial or full set
  of parameters necessary to complete the validation."

The two alternatives should be at the same level, or emphasis should 
even be
placed on the second alternative.

In order to support thing clients, it is necessary to be able to simply 
use an
OID (forget about instable / temporary URLs) which either tells 
everything to
the server, or if no OID is being used by the client, an OID supplied by 
the
server which tells every to the client.

Note: URNs could be used, but not URLs.

There is a major difference between a validation policy and a validation
algorithm. A validation policy is a set of rules which includes many 
algorithms
and their associated parameters.

ValidationAlg is currently defined as:

    ValidationAlg ::= SEQUENCE {
      valAlgId              OBJECT IDENTIFIER,
      parameters            ANY DEFINED BY valAlgId OPTIONAL }

A parameter, called validationPol should be introduced in the query to 
allow the
use of a simple OID to reference a full policy or to define a validation 
policy,
i.e. first a validation algorithm compliant with [PKIX-1] section 6.1 
coming
with its associated parameters and additional algorithms coming with their
associated parameters.

ValidationPol should be defined as :

  ValidationPol ::= CHOICE {
      valPolRef             OBJECT IDENTIFIER,
      valPolDef             ValPolRef }

  ValPolDef ::= SEQUENCE {
      valPolId              OBJECT IDENTIFIER,
      parameters            ANY DEFINED BY valPolId OPTIONAL }

When using valPolRef, all algorithms and parameters are fixed.
When using valPolDef, some parameters may be dynamic.

The current structure of ValPolicy defined in section 4.11 on page 38, 
would be
used for the parameters of a specific validation policy defined in this
document, i.e. id-svp-defaultValAlg OBJECT IDENTIFIER ::= { id-svp 1 }

The text should thus not state:

"When the id-svp-defaultValAlg appears as an valAlgId, the
parameters MUST be absent."

The parameters for the default validation policy shall be the parameters of
ValPolDef. The overall structure of the request would be greatly 
simplified.

Note also that the ValidationAlg parameter has been omitted to be 
described at
the right place, i.e. in sequence after section 3.2.4, but is described in
section 3.2.12 as:

3.2.12 validationAlg

  The validationAlg item, defines the validation algorithm to be used
  by the SCVP server during certificate validation.  The value of
  this item can be determined by agreement between the client and the
  server, and is represented as an object identifier.  The server
  might want to assign additional object identifiers that indicate
  that some settings are used in addition to others given in the
  request.  In this way, the validation algorithm object identifier
  can be a shorthand for some SCVP options, but not others.

  The validationAlg item uses the ValidationAlg type, which has the
  following syntax:

    ValidationAlg ::= SEQUENCE {
      valAlgId              OBJECT IDENTIFIER,
      parameters            ANY DEFINED BY valAlgId OPTIONAL }

Path processing is only one of the many checks that can be done, since many
additional checks about the content of the certificate can be done in 
addition
to the certificate path processing algorithm defined by [PKIX-1] in section
6.1.1.

It is thus inappropriate to limit in general the parameters to those of 
section
6.1.1., thus why all parameters associated with a given validation 
algorithm
shall always be included in the parameters of ValPolDef.

The text also states:

"The SCVP server can assign validation algorithm object identifiers
  which indicate that some predefined settings are used in addition
  to values provided in the SCVP request."

Why this ? If the client specifies a validation policy either the server
supports it or returns an error. If the client does not specify a 
validation
policy in its request, then the server has to return the default validation
policy which it has been used (and which may have nothing to do with the so-
called default validation policy defined in section 3.2.12.1.)

The following text extracted from the document, highlights the confusion 
between
a validation policy and a validation algorithm.

" For a certification path to be considered valid under a particular
  validation policy, it MUST be a valid certification path as defined
  in [PKIX-1] and all validation policy constraints that apply to the
  certification path MUST be verified.  Applications MAY place
  additional requirements on the validation algorithm."


4. In section 3 Validation Request, the text states:

" All SCVP clients MUST support SignedData for signed requests and
  responses."

For certification path discovery signed responses are not necessary, nor 
are
signed requests necessary. For certificate validation according to a 
validation
policy signed responses are necessary, but signed requests are not 
necessary. So
this requirement should be modified.


5. Similar considerations apply for authenticatedData for signed 
requests and
responses.


6. The current query, which is far too complicated, is currently 
composed of 21
items as follows:

    Query ::= SEQUENCE {
     queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
     checks                   CertChecks,
     wantBack                 WantBack,  
     validationAlg            ValidationAlg,
     requestRefHash           BOOLEAN DEFAULT TRUE,
     fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
     IsCA                 [4] BOOLEAN DEFAULT FALSE,
     SignResponse         [5] BOOLEAN DEFAULT TRUE,
     serverContextInfo    [6] OCTET STRING OPTIONAL,
     validityTime         [7] GeneralizedTime OPTIONAL,
     trustAnchors         [8] TrustAnchors OPTIONAL,
     intermediateCerts    [9] CertBundle OPTIONAL,
     revInfos            [10] RevocationInfos OPTIONAL,
     keyUsage            [11] KeyUsage OPTIONAL,
     extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
     queryExtensions     [13] Extensions OPTIONAL  
     producedAt          [14] GeneralizedTime OPTIONAL
     validationPolRef    [15] ValidationPolRef OPTIONAL}

Taking into consideration the move of the so-called parameters of the 
default
validation algorithm :

     validationPol            ValidationPol,
     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
     IsCA                 [4] BOOLEAN DEFAULT FALSE,
     trustAnchors         [8] TrustAnchors OPTIONAL,
     keyUsage            [11] KeyUsage OPTIONAL,
     extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,


In fact as set of parameters is defined on page 38 as:

  ValPolicy ::=SEQUENCE  {
     validationAlg            ValidationAlg,
     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
     isCA                 [4] BOOLEAN DEFAULT FALSE,
     trustAnchors         [5] TrustAnchors,
     keyUsage             [6] KeyUsage OPTIONAL,
     extendedKeyUsage     [7] ExtKeyUsageSyntax OPTIONAL}

and it would make sense to use that structure which groups them and use 
it as
the parameters to be associated with id-svp 1.

The query could then be simplified as follows:

    Query ::= SEQUENCE {
     queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
     checks                   CertChecks,
     wantBack                 WantBack,  
     requestRefHash           BOOLEAN DEFAULT TRUE,
     fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
     signResponse         [1] BOOLEAN DEFAULT TRUE,
     serverContextInfo        OCTET STRING OPTIONAL,
     validationPol            ValidationPol OPTIONAL,
     -- if missing in the query, then MUST be present in the response
     validityTime             GeneralizedTime OPTIONAL,
     intermediateCerts        CertBundle OPTIONAL,
     revInfos                 RevocationInfos OPTIONAL,
     queryExtensions      [2] Extensions OPTIONAL,
     producedAt           [3] GeneralizedTime OPTIONAL
}

Below the new definition of ValidationPol is copied again.

  ValidationPol ::= CHOICE {
      valPolRef             OBJECT IDENTIFIER,
      valPolDef             ValPolDef }

    ValPolDef ::= SEQUENCE {
      valPolId              OBJECT IDENTIFIER,
      parameters            ANY DEFINED BY valPolId OPTIONAL }


7. The SCVP response is currently defined on page 27 as follows:

    CVResponse ::= SEQUENCE {
      scvpVersion           INTEGER,
      policyID              INTEGER,
      producedAt            GeneralizedTime,
      responseStatus        ResponseStatus,
      requestRef            RequestReference,
      requestor         [1] OCTET STRING OPTIONAL,
      responder         [2] OCTET STRING OPTIONAL,
      replyObjects      [3] ReplyObjects OPTIONAL,
      requestNonce      [4] OCTET STRING OPTIONAL,
      serverContextInfo [5] OCTET STRING OPTIONAL,
      valPolResponse    [6] ValPolicy OPTIONAL,
      validationPolRef  [7] ValidationPolicyRef OPTIONAL  
      respExtensions    [8] Extensions OPTIONAL }

policyID is mandatory and does not make sense when a validation policy 
reference
is being used. It should be deleted.

responder is for SCVP server relay only and the text omits to mention it.

requestor is primarily for SCVP server relay and that this parameter 
should not
have to be supported by a client.

Defining these two parameters as respExtensions would only thin clients 
and non
relaying servers to simply forget about them.

It is thus proposed to simplify the structure as follows:

    CVResponse ::= SEQUENCE {
      scvpVersion           INTEGER,
      requestNonce          OCTET STRING OPTIONAL,
      producedAt            GeneralizedTime,
      requestRef            RequestReference,
      validationPol         ValidationPol OPTIONAL,
      -- if missing in the query, then MUST be present
      responseStatus        ResponseStatus,
      replyObjects      [1] ReplyObjects OPTIONAL,
      serverContextInfo [2] OCTET STRING OPTIONAL,
      respExtensions    [3] Extensions OPTIONAL }


8. The Server Policies Request is currently defined on page 40 as follows:

    PolRequest ::= SEQUENCE {
      scvpVersion                INTEGER }

The current idea is to use a mechanisms similar to the CRL mechanism to 
detect
if the response is current or is a replay. It should be able to support 
a nonce.

The structure should thus be changed to:

    PolRequest ::= SEQUENCE {
      scvpVersion                INTEGER,
      requestNonce               OCTET STRING OPTIONAL }


9. The Server Policies Response is currently defined on page 40 as follows:

    PoliciesResponse ::= SEQUENCE {
      scvpVersion                INTEGER,
      DefaultPolicyID            INTEGER,
      thisUpdate                 GeneralizedTime,
      nextUpdate                 GeneralizedTime,
      trustAnchors               TrustAnchors,
      validationPolices          SEQUENCE OF ValidationPolRef,
      validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
      authPolicies               SEQUENCE OF AuthPolicy,
      responseTypes              ResponseTypes,   
      defaultValPol              ValPolicy,            
      clockSkew                  INTEGER OPTIONAL,
      authDataCert               Certificate OPTIONAL }


DefaultPolicyID and defaultValPol do not need to be present, since the 
default
policy may simply be the first policy of the SEQUENCE of validation 
policies
that is returned.

nextUpdate should be OPTIONAL since a server may choose to always send a 
fresh
response.

trustAnchors is a parameter of one specify validation policy and thus 
should not
be present at that level.

validationPolices should be used to define a sequence of validation policy
references and/or a sequence of validation policy definitions. See below.

validationAlgs may be inner component of validation policy definition.

authPolicies is unclear, since all responses MUST be signed. Deleted for
simplification.

defaultValPol is not needed, if the default policy is simply the first 
policy of
the SEQUENCE of validation policies that is returned.

The name of authDataCert should be changed into serverCert.

The structure should thus be changed to:

    PoliciesResponse ::= SEQUENCE {
      scvpVersion                INTEGER,
      responseNonce              OCTET STRING OPTIONAL,
      thisUpdate                 GeneralizedTime,
      nextUpdate                 GeneralizedTime OPTIONAL,
      validationPolicies         SEQUENCE OF ValidationPol,
      -- the default validation policy is the first of the sequence
      responseTypes              ResponseTypes,
      clockSkew                  INTEGER OPTIONAL,
      serverCert                 Certificate OPTIONAL }


Denis





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SCXAAY059223; Wed, 28 Jul 2004 05:33:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SCXAdC059222; Wed, 28 Jul 2004 05:33:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SCX8mn059181 for <[e-mail]>; Wed, 28 Jul 2004 05:33:09 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i6SCX3N14347; Wed, 28 Jul 2004 14:33:03 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 28 Jul 2004 14:33:03 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i6SCX2g12828; Wed, 28 Jul 2004 14:33:02 +0200 (MEST)
Date: Wed, 28 Jul 2004 14:33:02 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: PKIX WG Agenda for 60th IETF (second try!)
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

it seems to me that some of the results of discussions between
the editor and me have been forgotten or so.


I still think that the scvp is not conformant to RFC 3379
and/or the editors has not done something as announced.

1) RFC 3379 says: 
   The DPV request MUST allow the client to request that the server
   include in its response additional information which will allow
   relying parties not trusting the DPV server to be confident that the
   certificate validation has correctly been performed.  Such
   information may (not necessarily exclusively) consist of a
   certification path, revocation status information from authorized CRL
   issuers or authorized OCSP responders, revocation status information
   from CRL issuers or OCSP responders trusted under the validation
   policy, time-stamp tokens from TSAs responders trusted under the
   validation policy, or a DPV response from a DPV server that is
                      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   trusted under the validation policy.  When the certificate is valid
   according to the validation policy, the server MUST, upon request,
   include that information in the response.  However, the server MAY
   omit that information when the certificate is invalid or when it
   cannot determine the validity.

   ==> no provision (as far as I see).


2) RFC 3379 says:
   When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response.  Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy.  The DPV server MAY choose to blindly copy the
   identifier, omit the identifier, or return an error response.

The current text is SCVP says: 

  The OPTIONAL requestor item is used to identify the requestor.  The 
  value is only of local significance to the requestor.  If the SCVP 
  client includes a requestor value in the request, then the SCVP 
  server MUST return the same value if the server is generating a 
  specific response. 


tf also said:

> Given there are plenty of ways a client can generate a "unique" as well
> as other behaviors like it can encode a DN in the octet sting if it
> likes I don't see a problem. Its down to the client to do what it thinks
> fit. The value is simply replayed by the server so it is treated a
> binary blob.

There is nothing else possible for the server except copying, or,
no mechanisms to match this with the some authenticated entity 
can be safely developped if it is solely 'up to the client to encode whatever'. 

I had proposed two changes to the logic of 0 terminated octet strings by: 

- a sequence of octet strings allowing a real opaque string.
- a choice of generalname

I.e.

   Identifiers ::= SEQUENCE OF { 
          CHOICE {
               opaqueId OCTET STRING,
               nameId GeneralName
          }

No comment to this proposition as far as I remember. 

3) In May 204 trevor wrote:

> I think we can use the Cert sign bit in key usage so the is CA bit can
> be removed from SCVP15

which was not done. 

4) Somewhat related to this, and to the provisions to search in DPD or validate
   in DPV several types of extensions, I had proposed to opetionally search
   for the pathlength basicconstraint. if for example a client has a
   cert and a CA cert then one could use it to search only for CAs that
   have at least a pathlength of 1.
  

I seem to understand that the rule in this WG is:

- editor, chairmen, iesg says something ==> accepted if no response
- others ==> rejected if no response from anyone.

all totally independant of the content of the comment. 

At least point 3 doesn't fit into this rule.

I'd like to to see whether there is someone participating
in this list who agrees with something or considers it as useful ...

Thanks for consideration
Peter 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SAkIPs025761; Wed, 28 Jul 2004 03:46:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SAkITo025760; Wed, 28 Jul 2004 03:46:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailrelay01.tugraz.at (mailrelay.tu-graz.ac.at [129.27.3.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SAkEj7025658 for <[e-mail]>; Wed, 28 Jul 2004 03:46:17 -0700 (PDT) (envelope-from [e-mail])
Received: from iaik.at (mailhost.iaik.tu-graz.ac.at [129.27.152.30]) by mailrelay01.tugraz.at (8.13.0/8.13.0) with ESMTP id i6SAk8ij003918 for <[e-mail]>; Wed, 28 Jul 2004 12:46:09 +0200 (CEST)
Received: from iaik.tugraz.at [129.27.152.103] by iaik.at with ESMTP (SMTPD32-7.07) id A3F11039008C; Wed, 28 Jul 2004 12:46:09 +0200
Message-ID: <[e-mail]>
Date: Wed, 28 Jul 2004 12:46:10 +0200
From: mario ivkovic <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Time-Stamp Protocol (TCP-based protocol)
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.44
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If the client sends a tsaMsg to a tsa server and the server answers with 
partialMsgRep, who is responsible for closing the tcp/ip connection? 
(client or server)
Should the client send a pollReq in the same connection as the tsaMsg?

Thanks,

Mario Ivkovic

-- 

Mario Ivkovic, IAIK - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: [phone]
Fax: [phone]
http://jce.iaik.tugraz.at



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RFkUkf064404; Tue, 27 Jul 2004 08:46:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6RFkUOQ064403; Tue, 27 Jul 2004 08:46:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-1-sn3.vrr.skanova.net (av1-1-sn3.vrr.skanova.net [81.228.9.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RFkTST064395 for <[e-mail]>; Tue, 27 Jul 2004 08:46:29 -0700 (PDT) (envelope-from [e-mail])
Received: by av1-1-sn3.vrr.skanova.net (Postfix, from userid 502) id C2EC337E6D; Tue, 27 Jul 2004 17:46:26 +0200 (CEST)
Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id B693337E42 for <[e-mail]>; Tue, 27 Jul 2004 17:46:26 +0200 (CEST)
Received: from arport (t11o913p74.telia.com [213.64.28.74]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id C42F43800F for <[e-mail]>; Tue, 27 Jul 2004 17:46:25 +0200 (CEST)
Message-ID: <001b01c473f0$70677470$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <00a001c46f36$a5abe6c0$0500a8c0@arport>
Subject: Re: pkix-pi-10.txt - Usage Models
Date: Tue, 27 Jul 2004 17:43:17 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As far as I can see the PI extension adds nothing to existing single-
assigner (name space) PKIs like DoD's and various Citizen schemes.

In these PKIs a static RFC 3739-compliant assignment of serialNumber
as PI value suffices.  This is how it is done today and nobody has
expressed that something is really "missing".

Therefore, the PI extension should IMHO be (re)targeted at PKI networks
that at least _plan_ to accept multiple assigners.  This BTW means a
_lot_ more than adding some PI crypto-software with respect to RPs.

However, this also makes the specification of the assigner-part much
more important than has been expressed in some off-list messages like
"assigner is only read by machines", which does not tell the whole story.
Assigners will in multi-assigner PKIs be stored in user or customer
databases and will definitely be read and communicated by humans.
VAT and DUNS are example of two common assigners that are important
to distinguish both for legal and technical reasons.

With this I mean, that OIDs should not be the _only_ assigner choice as
this would probably put a "stigma" on the PI scheme as the world outside
of the IETF is fairly ignorant of OIDs.  Neither do I believe that a true
multi-assigner PI scheme would gain by putting assigner values in
special places, disconnected from their closely associated value parts.

That is, a *genuine* PI is a two-dimensional name, similar to an e-mail address.

For historical reasons (X.520) we must accept a compromise but this
compromise can still be more or less tasty.

================================================
  It is important to note that there currently probably does not exist
  a single multi-assigner PKI-based network.
================================================

/Anders



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R003lh001923; Mon, 26 Jul 2004 17:00:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6R003Mp001922; Mon, 26 Jul 2004 17:00:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.vtcif.telstra.com.au (mailbo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R002Jt001907 for <[e-mail]>; Mon, 26 Jul 2004 17:00:03 -0700 (PDT) (envelope-from [e-mail])
Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailbo.vtcif.telstra.com.au (Postfix) with ESMTP id 3347A22E42 for <[e-mail]>; Tue, 27 Jul 2004 09:59:58 +1000 (EST)
Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id BF2F91DA81 for <[e-mail]>; Tue, 27 Jul 2004 09:59:57 +1000 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 7364941E3A for <[e-mail]>; Tue, 27 Jul 2004 09:59:57 +1000 (EST)
content-class: urn:content-classes:message
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 27 Jul 2004 09:58:45 +1000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Thread-Index: AcRy/v8BKZJRiv7YTTWa4trhEA1tvgAa8t6g
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6R003Jt001917
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,
"deepest serialNumber value" meant the deepest serialNumber value, regardless of whether the RDN it was in was the deepest RDN, the 2nd deepest RDN etc.  We now both agree on the logic, so if you think my words are confusing I can live with your words.



Richard,
Including the PI extension with an absent identifierValue when the subject DN is cn="John Doe" , o="Acme Ltd" serialNumber="DUNS554433", c=US would not be sane, as you note.  However, it would not be the fault of the PI extension or the DN.  It would simply be a straight out lie by the CA.  The syntax does not (and cannot) prevent lies.


----------
From: Denis Pinkas [mailto:[e-mail]]
Sent: Monday, 26 July 2004 7:28 PM

> I still suggest using my original text changes.

Your original text was: "when identifierValue is absent the
deepest serialNumber value is used". I would guess that you mean:
"when identifierValue is absent, the value contained in the
serialNumber of the deepest RDN SHALL be used."

I would propose instead to re-use my text, modified by David,
with an additional modification for the item 2. This leads to:

1 - if there are one or more RDNs containing a serialNumber
     attribute (alone or accompanied by other attributes), then
     the value contained in the serialNumber of the deepest
     such RDN SHALL be used as the identifierValue.

2 - otherwise, the Permanent Identifier definition is invalid
     and the Permanent Identifier SHALL not be used.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QG6m4w094538; Mon, 26 Jul 2004 09:06:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QG6mHb094537; Mon, 26 Jul 2004 09:06:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QG6lNH094518 for <[e-mail]>; Mon, 26 Jul 2004 09:06:48 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i6QG6KaK005317; Mon, 26 Jul 2004 12:06:20 -0400
Received: from krdp8.nist.gov (seclab14.ncsl.nist.gov [129.6.52.54]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i6QG68mb024467; Mon, 26 Jul 2004 12:06:08 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 26 Jul 2004 12:09:51 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: PKIX WG Agenda for 60th IETF (second try!)
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please substitute the following agenda for this morning's 
submission.  There were numerous typos in the original.

Thanks,

Tim Polk

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

PKIX WG (pkix-wg)

Wednesday August 4, 2004 0900-1130
=================================

CHAIR: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

AGENDA:

1. WG Status and Direction

1.1 Document Status Review [Tim Polk (NIST)]

        The working group has a number of Internet-Drafts.  Many
        documents are with the ADs or in various stages of WG Last Call.
        Several others are ready for Last Call. (10 min.)

1.2 Proposed WG Milestones [Tim Polk (NIST)]

        The working group milestones are out of date.  New milestones are
        needed; these milestones need to satisfy IESG direction for an orderly
        closeout of WG activities. (10 min.)

2. PKIX WG Specifications

2.1 LDAP Specifications

       The PKIX WG has a number of LDAP-based specifications supporting
       publication and distribution of certificates and CRLs.

2.1 LDAP Schemas, String Values, and more
       - David Chadwick (U. of Salford)

   http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-02.txt
   http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-01.txt

       The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution
       for LDAP based PKI information distribution.  New drafts of two 
documents
       have been submitted since IETF 59; additional drafts will be published
       soon after this meeting; the presenter will discuss the changes in the
       and highlight issues that must be resolved before Last Call.  (15 min.)

2.2 Practical Considerations for Use of LDAP in PKIX
       - Kurt Zeilenga (LDAPbis WG co-chair)

   (no draft)

       Practical considerations must be considered to maximize the utility
       and interoperability of LDAP-based PKIs.  This presentation will
       highlight known issues and (where applicable) ways to address them.
       (10 min.)


2.3 Matching Text Strings in PKIX Certificates
       - Paul Hoffman (IMC) and Steve Hanna (Sun)

   http://www.ietf.org/internet-drafts/draft-hoffman-pkix-stringmatch-00.txt

       This specification describes the use of Stringprep to support comparison
       and matching of international text strings.  This document resolves 
an open
       issue from RFC 3280, where the minimum requirements for name comparison
       were specified as binary matching.  Since the publication of RFC 3280,
       the stringprep specification has been completed, providing a solid 
basis for
       comparison and matching of test strings in PKIX certificates. (15 min.)

[see also

   http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-strprep-04.txt]


2.4 RFC 3280 Progression
       - Tim Polk (NIST)

   (no draft)

       NIST will present the current plan and milestones for progression of
       RFC 3280 to Draft Standard.   (5 min.)

2.5 Subject Identification Method
       - Speaker TBD

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

       A new draft of the Subject Identification Method has been submitted 
since
       IETF 59.  The document is relatively stable and mature.  WG Last Call is
       expected for the next draft of this document. (15 min.)

2.6 SCVP Progression
       - Speaker TBD

http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-15.txt

       This document has been in WG Last Call since early 2004.  Completion 
of WG Last
       Call was blocked by newly identified implementation requirements for 
unsigned
       messages to support DPD.  Early proposals did not satisfy RFC 3739, 
and were
       rejected.  A new draft has been submitted since IETF 59 which 
satisfies both
       RFC 3379 and the requirements for unsigned messages. (5 min.)

3. Related Specifications & Liaison Presentations

       Time allowing, liaison presentations will be accommodated to ensure the
       PKIX WG is aware of related specifications currently progressing as 
individual
       drafts.


3.1 Specification of OCSP in IKEv2
        - Mike Myers (TraceRoute)

   (no draft)

        This presentation will highlight issues with the specification of OCSP
        in IKEv2. (10 min.)

3.2 User Interface Requirement for the Internet X.509 Public Key Infrastructure
        - Tae Choi (KISA)

   http://www.ietf.org/internet-drafts/draft-choi-pkix-ui-00.txt

        This document provides basic requirements of user interface at PKI 
client
        software that satisfy a full of PKI implementation with usability. 
To meet
        with the requirements, it defines root CA certificate trust mechanism,
        certificate sharing mechanism, and certificate representation 
method. (10 min.)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QFncRm082099; Mon, 26 Jul 2004 08:49:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QFncB8082098; Mon, 26 Jul 2004 08:49:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (d29-52.vdsl.isp-service.de [83.122.29.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QFnb7W081892 for <[e-mail]>; Mon, 26 Jul 2004 08:49:37 -0700 (PDT) (envelope-from [e-mail])
Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 40E30CFB78; Mon, 26 Jul 2004 17:44:49 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 26 Jul 2004 17:44:48 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: "Jaleel P.A" <[e-mail]>
Cc: [e-mail]
Subject: Re: how to add 'ValidFrom' parameter in conf file ?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.84.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jaleel P.A wrote:
> 
> I tried by adding the UTC formatted time at 'default_startdate' of
> 'CA_default' section. 

The PKIX mailing list is the wrong forum for discussing this. I guess you 
won't get an answer here.

You might want to post your questions on the openssl-users mailing list (see 
http://www.openssl.org/support/).

Ciao, Michael.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QDpLKi042775; Mon, 26 Jul 2004 06:51:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QDpLL0042774; Mon, 26 Jul 2004 06:51:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QDpKMg042767 for <[e-mail]>; Mon, 26 Jul 2004 06:51:21 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i6QDp7aK002596; Mon, 26 Jul 2004 09:51:07 -0400
Received: from krdp8.nist.gov (seclab14.ncsl.nist.gov [129.6.52.54]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i6QDommb012103; Mon, 26 Jul 2004 09:50:48 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 26 Jul 2004 09:54:31 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: PKIX WG Agenda for 60th IETF
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PKIX WG (pkix-wg)

Wednesday August 4, 2004 0900-1130
=================================

CHAIR: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

AGENDA:

1. WG Status and Direction

1.1 Document Status Review [Tim Polk (NIST)]

        The working group has a number of Internet-Drafts.  Many
        documents are with the ADs or in various stages of WG Last Call.
        Several others are ready for Last Call. (10 min.)

1.2 Proposed WG Milestones [Tim Polk (NIST)]

        The working group milestones are out of date.  New milestones are
        needed; these milestones need to satisfy IESG direction for an orderly
        closeout of WG activities. (10 min.)

2. PKIX WG Specifications

2.1 LDAP Specifications

       The PKIX WG has a number of LDAP-based specifications supporting
       publciation and distribution of certificates and CRLs.

2.1 LDAP Schemas, String Values, and more
       - David Chadwick (U. of Salford)

   http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-02.txt
   http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-01.txt

       The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution
       for LDAP based PKI information distribution.  New drafts of two 
documenta
       have been submitted since IETF 59; additional drafts will be published
       soon after this meeting; the presenter will discuss the changes in the
       and highlight issues that must be resolved before Last Call.  (15 min.)

2.2 Practical Considerations for Use of LDAP in PKIX
       - Kent Zeilenga (LDAP WG co-chair)

   (no draft)

       Practical considerations must be considered to maximize the utility
       and interoperability of LDAP-based PKIs.  This presentation will
       highlight known issues and (where applicable) ways to address them.
       (10 min.)


2.3 Matching Text Strings in PKIX Certificates
       - Paul Hoffman (IMC) and Steve Hanna (Sun)

   http://www.ietf.org/internet-drafts/draft-hoffman-pkix-stringmatch-00.txt

       This specification describes the use of Stringprep to support comparison
       and matching of international text strings.  This document resolves 
an open
       issue from RFC 3280, where the minimum requirements for name comparison
       were specified as binary matching.  Since the publication of RFC 3280,
       the strinprep specifation has been completed, providing a solid 
basis for
       comparison and matching of test strings in PKIX certificates. (15 min.)

[see also

   http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-strprep-04.txt]


2.4 RFC 3280 Progression
       - Tim Polk (NIST)

   (no draft)

       NIST will present the current plan and milestones for progression of
       RFC 3280 to Draft Standard.   (5 min.)

2.5 Subject Identification Method
       - Speaker TBD

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

       A new draft of the Subject Identification Method has been submitted 
since
       IETF 59.  The document is relatively stable and mature.  WG Last Call is
       expected for the next draft of this document. (15 min.)

2.6 SCVP Progression
       - TBD

http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-15.txt

       This document has been in WG Last Call since early 2004.  Completion 
of WG Last
       Call was blocked by newly identified implementation requirements for 
unsigned
       messages to support DPD.  Early propsals did not satisfy RFC 3739, 
and were
       rejected.  A new draft has been submitted since IETF 59 which 
satisfies both
       RFC 3739 and the requirements for unsigned messages. (5 min.)

3. Related Specifications & Liaison Presentations

       Time allowing, liaison presentations will be accommodated to ensure the
       PKIX WG is aware of related specifications currently progressing as 
individual
       drafts.


3.1 Specification of OCSP in IKEv2
        - Mike Myers (TraceRoute)

   (no draft)

        This presentation will highlight issues with the specification of OCSP
        in IKEv2. (10 min.)

3.2 User Interface Requirement for the Internet X.509 Public Key Infrastructure
        - Tae Choi (KISA)

   http://www.ietf.org/internet-drafts/draft-choi-pkix-ui-00.txt

        This document provides basic requirements of user interface at PKI 
client
        software that satisfy a full of PKI implementation with usability. 
To meet
        with the requirements, it defines root CA certificate trust mechanism,
        certificate sharing mechanism, and certificate representation 
method. (10 min.)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QDhbpa041942; Mon, 26 Jul 2004 06:43:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QDhbei041941; Mon, 26 Jul 2004 06:43:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hotmail.com (bay19-dav9.bay19.hotmail.com [64.4.53.189]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QDhafW041916 for <[e-mail]>; Mon, 26 Jul 2004 06:43:36 -0700 (PDT) (envelope-from [e-mail])
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 26 Jul 2004 06:36:15 -0700
Received: from 203.123.181.226 by bay19-dav9.bay19.hotmail.com with DAV; Mon, 26 Jul 2004 09:49:43 +0000
X-Originating-IP: [203.123.181.226]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "Jaleel P.A" <[e-mail]>
To: <[e-mail]>
Subject: RE: how to add 'ValidFrom' parameter in conf file ?
Date: Mon, 26 Jul 2004 15:19:42 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcQnw/jU0rLVV64rRZ24IYUJCq38pwBgsBfAEmGa0BAAChJPsA==
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 26 Jul 2004 13:36:15.0798 (UTC) FILETIME=[864DF560:01C47315]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I tried by adding the UTC formatted time at 'default_startdate' of
'CA_default' section. 

Ex :

[CA_default]
default_startdate = "040801102530Z"

But still SSL takes the current date.

Any guess ?

Thanks
Jal



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jaleel P.A
Sent: Monday, July 26, 2004 10:30 AM
To: [e-mail]
Subject: how to add 'ValidFrom' parameter in conf file ?




Hi

How to add a 'ValidFrom' parameter in Conf file. Is there any predefined
section in conf file for this ?


Thanks 
Jaleel 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QAhRSS019974; Mon, 26 Jul 2004 03:43:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QAhRkp019973; Mon, 26 Jul 2004 03:43:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QAhPYA019930 for <[e-mail]>; Mon, 26 Jul 2004 03:43:26 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Mon, 26 Jul 2004 12:18:12 +0200
Date: Mon, 26 Jul 2004 12:42:53 +0200 (CEST)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.65
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.65 on Emacs 21.3 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hey guys,

I've lurked for a while, and have perhaps not entirely followed, so I
appologise in advance for jumping in like this.

I'm curious about the following:

In message <[e-mail]> on Mon, 26 Jul 2004 11:27:46 +0200, Denis Pinkas <[e-mail]> said:

Denis.Pinkas> > Thanks David.
Denis.Pinkas> > 
Denis.Pinkas> >>cn="John Doe" , o="Acme Ltd" serialNumber="DUNS554433", c=US
Denis.Pinkas> 
Denis.Pinkas> I would propose instead to re-use my text, modified by
Denis.Pinkas> David, with an additional modification for the item 2.
Denis.Pinkas> This leads to:
Denis.Pinkas> 
Denis.Pinkas> 1 - if there are one or more RDNs containing a
Denis.Pinkas>      serialNumber attribute (alone or accompanied by
Denis.Pinkas>      other attributes), then the value contained in the
Denis.Pinkas>      serialNumber of the deepest such RDN SHALL be used
Denis.Pinkas>      as the identifierValue. 

What would that mean for a DN like the one quoted above?  Does it mean
that John Doe would get serialNumber="DUNS554433" as PI by default?
What would then happen if J. Random Luser also gets a DN from Acme Ltd,
like this:

  cn="J. Random Luser", o="Acme Ltd" serialNumber="DUNS554422", c=US

Does that mean that J. Random Luser also would get
serialNumber="DUNS554433" as PI by default?

If that's what you mean, then it doesn't feel sane to me.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q9TIK6093885; Mon, 26 Jul 2004 02:29:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q9TIgB093884; Mon, 26 Jul 2004 02:29:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q9TDPR093813 for <[e-mail]>; Mon, 26 Jul 2004 02:29:15 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA37174; Mon, 26 Jul 2004 11:39:27 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id LAA29388; Mon, 26 Jul 2004 11:28:59 +0200
Message-ID: <[e-mail]>
Date: Mon, 26 Jul 2004 11:27:46 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: [e-mail]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James,

> Thanks David.
> 
>>cn="John Doe" , o="Acme Ltd" serialNumber="DUNS554433", c=US
> 
> Denis's "problem" DN does not need to be solved.  The DN does NOT contain a PI for the subject so the CA will not include a PI extension saying it does.  End of story.
> 
> Russ's "problem" DN does not need to be solved.  As David notes, an attribute type is not allowed to appear more than once in an RDN.
> 
> I still suggest using my original text changes.

Your original text was: "when identifierValue is absent the
deepest serialNumber value is used". I would guess that you mean:
"when identifierValue is absent, the value contained in the
serialNumber of the deepest RDN SHALL be used."

I would propose instead to re-use my text, modified by David,
with an additional modification for the item 2. This leads to:

1 - if there are one or more RDNs containing a serialNumber
     attribute (alone or accompanied by other attributes), then
     the value contained in the serialNumber of the deepest
     such RDN SHALL be used as the identifierValue.

2 - otherwise, the Permanent Identifier definition is invalid
     and the Permanent Identifier SHALL not be used.

Denis



> -----Original Message-----
> From: David P. Kemp [mailto:[e-mail]]
> Sent: Thursday, 22 July 2004 5:58 AM
> To: Denis Pinkas
> Cc: Russ Housley; Manger, James H; [e-mail]
> Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber
> attribute
> 
> 
> Denis,
> 
> Your two conditions below are logical but unnecessarily
> restrictive.
> 
> Consider James' original (correct) example:
> 
> [1] cn="John Doe" serialNumber=12345, o="Acme Ltd"
>     serialNumber="DUNS 554433", c=US
> 
> and a modification (poorly-structured, but legal) that uses
> only single-valued RDNs:
> 
> [2] cn="John Doe", serialNumber=12345, o="Acme Ltd",
>    serialNumber="DUNS 554433", c=US
> 
> and your example:
> 
> [3] cn="John Doe", o="Acme Ltd", serialNumber="DUNS 554433", c=US
> 
> 
> I do not believe it is necessary to prohibit [2] in order to
> prevent [3].  Instead, if the SAN identifierValue is absent:
> 
> 1 - if there are one or more RDNs containing a serialNumber
>      attribute (alone or accompanied by other attributes), then
>      the value contained in the serialNumber of the deepest
>      such RDN shall be used as the identifierValue.
> 
> 2 - otherwise, the CA is in error.
> 
> 
> X.501 (02/2001) section 9.3, which appears to be normative,
> not informative, prohibits a given attribute type from
> appearing more than once in the same RDN.  The origin of
> Russ' comments regarding the possibility of multiple
> serialNumber attributes in a single RDN is unclear.
> 
> Dave
> 
> 
> 
> Denis Pinkas wrote:
> 
> 
>>1 - if there is one serialNumber attribute alone in a RDN (i.e. no
>>    other attribute is present in that RDN), then *there shall
>>    only be one such RDN and* the value contained in the
>>    serialNumber attribute shall be used as the identifierValue;
>>
>>2 - if there is no serialNumber attribute alone in a RDN, then the
>>    deepest RDN shall include a *single* serialNumber attribute
>>    and the value contained in that serialNumber shall be used
>>    as the identifierValue.
>>
>>Denis
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q5L8KZ005013; Sun, 25 Jul 2004 22:21:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6Q5L84H005012; Sun, 25 Jul 2004 22:21:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hotmail.com (bay19-dav12.bay19.hotmail.com [64.4.53.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q5L87o004949 for <[e-mail]>; Sun, 25 Jul 2004 22:21:08 -0700 (PDT) (envelope-from [e-mail])
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 25 Jul 2004 22:20:12 -0700
Received: from 203.123.181.226 by bay19-dav12.bay19.hotmail.com with DAV; Mon, 26 Jul 2004 04:59:42 +0000
X-Originating-IP: [203.123.181.226]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "Jaleel P.A" <[e-mail]>
To: <[e-mail]>
Subject: how to add 'ValidFrom' parameter in conf file ?
Date: Mon, 26 Jul 2004 10:29:42 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcQnw/jU0rLVV64rRZ24IYUJCq38pwBgsBfAEmGa0BA=
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 26 Jul 2004 05:20:12.0643 (UTC) FILETIME=[3A14EB30:01C472D0]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi

How to add a 'ValidFrom' parameter in Conf file. Is there any predefined
section in conf file for this ?


Thanks 
Jaleel 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N9D1r1078911; Fri, 23 Jul 2004 02:13:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6N9D1PU078910; Fri, 23 Jul 2004 02:13:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from polito.it (anacreon.polito.it [130.192.3.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N9CwwN078885 for <[e-mail]>; Fri, 23 Jul 2004 02:12:59 -0700 (PDT) (envelope-from [e-mail])
Received: from [130.192.1.59] ([130.192.1.59] verified) by polito.it (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 6121677 for [e-mail]; Fri, 23 Jul 2004 10:46:45 +0200
Message-ID: <[e-mail]>
Date: Fri, 23 Jul 2004 10:38:45 +0200
From: Massimiliano Pala <[e-mail]>
Organization: Politecnico di Torino
User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Request: Send me signed messages
References: <002101c46b50$342174a0$[e-mail]> <[e-mail]> <p06110403bd1de535f889@[10.20.30.249]> <p06110412bd1df2a828b0@[128.89.89.75]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070000030901080401020603"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Joseph Doekbrijder wrote:
> Interesting issue, which leaves me with a question:
> The only thing a spammer can not do (or maybe only once) is digitally 
> sign his spam! Upon abuse, The cert can be put on the receivers 
> "black-list", the cert could be revoked by CA and/or RA and the 
> IssuingParty can be contacted if abuse continues...
> Would it thus not be an interesting approach to build a mail filter that 
> filters out all non digitally signed email?
> It is clear, this is something for the future, but from a theoretical 
> point-of-view: Some feedback from the experts out there would be 
> interesting for me. In other words, can we take this any further?

Actually we do believe this could be an interesting approach to investigate.
At present we are working on an Email Policy Enforcer (EMPE) that seems
to be promising and uses strong authentication methods to solve some of
the email-related issues. I guess we'll be able to publish something about it in
the near future.

If it is not so OT I will send a pointer to it to the list.

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]      [e-mail]
                                                    Tel.:   [phone]
http://security.polito.it                       Fax:    +39   178  270 2077
                                                    Mobile: [phone]

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  http://ca.polito.it
Authority's Certificate:          http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------

--------------ms070000030901080401020603
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU7zCC
BIMwggNroAMCAQICAQswDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG
A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxMjEw
MDAwMFoXDTA2MTIzMTEwMDAwMFowUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kx
MDAuBgNVBAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP7ay1Eyxgv7fW1lpkRT4bljS3Cf7Z5m/KaX
pQEsMQfihBXvocVGVqYCTbXl1u+9rbyVV8MtoaZFE2Eb+8tKTA6D2UJpVln2GinHi1Cs+wIV
6Sz55wKaN3tKzGMw3L/H3ADNiYottP//ge3S1P6j0bcGhQ/p/xOGzmALt8CB7KCtn9+VHV8D
vcmOqmmQVcymUz9MCN68ZzfLvefAnUzWoIN72fxJDRG8szLj1IYxHOPsoLVID20yGDdyppHt
Vr1xUY4rGo5jPCuI79/QxNhQeDyWQo2x2jqM3nVmVXDFRJIms1j7BWpuiEhs0ZJWkaQXd29g
mBeZopvMKyAXO3XDDv8CAwEAAaOCAXQwggFwMEwGCWCGSAGG+EIBDQQ/Fj1Jc3N1ZWQgdW5k
ZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMDgG
CCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3BraS5vcmc6ODAy
NjA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3Js
L2NybC5kZXIwTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6
Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAfBgNVHSMEGDAWgBSM3IuxpUqQ
506Icxg8ndVefuSyzTAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIB9jAdBgNVHQ4EFgQUqjwT
yUkLXM240yDgxZWXMzNdJBMwDQYJKoZIhvcNAQEFBQADggEBAGuphjJQE0RQ28euKSOZ7Q4b
vGgPeO8WgGiUHrpZ6vI2+/knSqqK0AQ7j5+4viGMJgm2x8JnYq9ZYy1i0wFrYIxE/G2fw8cW
1P/8sCNzqTj+SO0/2KpJ0BkvuTSG2r1NTeg6a5r61a4jUqp4upKxuzgu6unsw/+RkU2KzlNm
053JOcsM82dIN3NBr+hZs/0IFiMW1GJB2P7225WWDF01OtQcmLYspoiffUPy2g+g4FD5IxHF
HKvCG1b9zHmfJoaDn5y+kQQpHs/ZIZeUyNe9ULifu3GgGQKp9sj6bpbGfjW3LAhhG6Ldhf8+
Azi6vNmzQwCbegU26NFazErhLS5qDXQwggU+MIIEJqADAgECAgIBaDANBgkqhkiG9w0BAQUF
ADBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UEAxMnRXVyb1BLSSBJ
dGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxNDEwMDAwMFoXDTA2MTIz
MTA5MDAwMFowZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlu
bzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmljYXRpb24gQXV0aG9y
aXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9sfcfWMG/mS8O69abPfnUWci
6TfUncSlfs8SzpwAsoW1/OJpGVtxq1yKQrP8WqiixEcZWSvnlOcyRj/C0tz3JLQKSAyrHKGS
Dkn5Md4HCue+L1JHQ3Ba14eQOj7rAugFgE+6LenTAvguOQl74/t9C93Ldm1NY+t1Fs36oPhP
JQ5inrZ6D8P9ol4s/ecyPhhQaU1tioqQy1d01gXTrmI2eH6Ui0AkyexVcxFpXR7qnvPV7huE
+ZTDU77t9jx24smmJuSxlA8HQS8I+qCytDhOYsKm676n1a4wpE9VunoVAm/+7tajm31ZYaxT
njX891kfFGoFi/J3tIRc67vh8Joy+wIDAQABo4ICCjCCAgYwdQYJYIZIAYb4QgENBGgWZklz
c3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9j
cHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBcBggrBgEF
BQcBAQRQME4wKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgwMjYwIgYI
KwYBBQUHMAKGFmh0dHA6Ly93d3cuZXVyb3BraS5vcmcwOwYDVR0fBDQwMjAwoC6gLIYqaHR0
cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwuZGVyMIGTBgNVHSAEgYswgYgw
QwYKKwYBBAGpBwEBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2Nh
L3Jvb3QvY3BzLzEuMS8wQQYKKwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3
LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMB8GA1UdIwQYMBaAFKo8E8lJC1zNuNMg4MWV
lzMzXSQTMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgH2MB0GA1UdDgQWBBT0DG1tnl9M
YlY5geDe+Y8vN6CExTANBgkqhkiG9w0BAQUFAAOCAQEAXx26gpm/oiG7ti2+e1Lwmnqn6jk0
ihxIxccazoTAjWzq60x+MhIJsIgRfGtv5U2XzEWc15UZru6srk8TqctT6EbqRMTCtx6mxPd6
RpKp3jepigGOkwnJsnjjUPC/tHmfJHNcll3Rk6a4OIvazlwOoCuQ8D0N9sAGtx35+T+tAyph
NU9yHtC3dpvQotLmJFo2Pr6sTy2ijCqQnHxJ2sZUEAlNEunKFP8y3uPfwvE0FEC7lONkUx+U
79yAlwPvBvASUopIQPy7BQ9IMupkj/1DmUvml/05f+DYv2x7UbiUlp1ksQXzs+WLxB2NADfn
CaPNvqphRz5KhJGOTJpc8CZ+UDCCBY8wggR3oAMCAQICAgFnMA0GCSqGSIb3DQEBBQUAMGUx
CzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMT
LVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDAy
MDMxNTAwMDBaFw0wNTEyMzExMjAwMDBaMH0xCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp
dGVjbmljbyBkaSBUb3Jpbm8xMTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNh
IGUgSW5mb3JtYXRpY2ExGzAZBgNVBAMTEk1hc3NpbWlsaWFubyAgUGFsYTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAq9EaJRA7cRia5n0014UeruZBPwDwNyEpWxIvWqVG6taEt1P1
wApd7oKi7yhUL8yUpX2eEQdLj/yjCQOr1NqmkL5MwiZhVtwcli3/3G0OayKu/i6yRIW24SM5
sbNLO4hhZYSiHAMlZ/U5Y6r6zFvxRbIK9/mB/wrJ6HIzOzC+xncCAwEAAaOCArMwggKvMIGV
BglghkgBhvhCAQ0EgYcWgYRJc3N1ZWQgdW5kZXIgcG9saWNpZXM6CiBodHRwOi8vd3d3LmV1
cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8KIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Ev
aXQvY3BzLzEuMS8KIGh0dHA6Ly9jYS5wb2xpdG8uaXQvY3BzLzIuMS8wEQYJYIZIAYb4QgEB
BAQDAgCwMGMGCCsGAQUFBwEBBFcwVTAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3Br
aS5vcmc6ODAyNjApBggrBgEFBQcwAoYdaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC8w
MgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NhLnBvbGl0by5pdC9jcmwwMi9jcmwuZGVyMAwG
A1UdEwEB/wQCMAAwPgYDVR0RBDcwNYEbbWFzc2ltaWxpYW5vLnBhbGFAcG9saXRvLml0oBYG
CisGAQQBlWICAQGgCBYGMTIxNTc1MIHNBgNVHSAEgcUwgcIwQwYKKwYBBAGpBwEBATA1MDMG
CCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYK
KwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0
L2Nwcy8xLjEvMDgGCisGAQQBlWIBAgEwKjAoBggrBgEFBQcCARYcaHR0cDovL2NhLnBvbGl0
by5pdC9jcHMvMi4xLzALBgNVHQ8EBAMCBPAwHQYDVR0OBBYEFKBsBAutUrWisrKMhGDw86gH
WDoSMB8GA1UdIwQYMBaAFPQMbW2eX0xiVjmB4N75jy83oITFMA0GCSqGSIb3DQEBBQUAA4IB
AQDrwXGLgvcDvhk2w6AFLp3DIhWl4zX9G6W4v9gis9vBHkIHQUg2iBmbVEeCn9XrSIXtuleH
uyYI+uu+KUdoCqt9XEFlL6eYnvrZNc7wWkH+msZwc11C+8UibhzaUezlEqTm9l+08xucAJER
4q489+2ZY7Kf8tFB1n4edgtg8rxrlNX++ZqqrJCnYWQvv0e4Hmav+CKnuMT+Y1qVv3BW6HDD
OBljhSEx6+cmooIPoWy8/5W/aGl5WEr1aCUZ/o8DODPxUIwEcUHV+m4EuQz7j0XLLcyC62Lc
FCx7+itzdJ61epbCmOgTNSWJFryVPClhlM3YFzFxL9Ae7mFmTdUbkdyKMIIFjzCCBHegAwIB
AgICAWcwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNu
aWNvIGRpIFRvcmlubzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTA0MDIwMzE1MDAwMFoXDTA1MTIzMTEyMDAwMFowfTELMAkG
A1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlubzExMC8GA1UECxMoRGlw
YXJ0aW1lbnRvIGRpIEF1dG9tYXRpY2EgZSBJbmZvcm1hdGljYTEbMBkGA1UEAxMSTWFzc2lt
aWxpYW5vICBQYWxhMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCr0RolEDtxGJrmfTTX
hR6u5kE/APA3ISlbEi9apUbq1oS3U/XACl3ugqLvKFQvzJSlfZ4RB0uP/KMJA6vU2qaQvkzC
JmFW3ByWLf/cbQ5rIq7+LrJEhbbhIzmxs0s7iGFlhKIcAyVn9TljqvrMW/FFsgr3+YH/Csno
cjM7ML7GdwIDAQABo4ICszCCAq8wgZUGCWCGSAGG+EIBDQSBhxaBhElzc3VlZCB1bmRlciBw
b2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLwogaHR0
cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLwogaHR0cDovL2NhLnBvbGl0by5p
dC9jcHMvMi4xLzARBglghkgBhvhCAQEEBAMCALAwYwYIKwYBBQUHAQEEVzBVMCgGCCsGAQUF
BzABhhxodHRwOi8vb2NzcC5ldXJvcGtpLm9yZzo4MDI2MCkGCCsGAQUFBzAChh1odHRwOi8v
d3d3LmV1cm9wa2kub3JnL2NhL2l0LzAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY2EucG9s
aXRvLml0L2NybDAyL2NybC5kZXIwDAYDVR0TAQH/BAIwADA+BgNVHREENzA1gRttYXNzaW1p
bGlhbm8ucGFsYUBwb2xpdG8uaXSgFgYKKwYBBAGVYgIBAaAIFgYxMjE1NzUwgc0GA1UdIASB
xTCBwjBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVyb3BraS5v
cmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6
Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wOAYKKwYBBAGVYgECATAqMCgGCCsG
AQUFBwIBFhxodHRwOi8vY2EucG9saXRvLml0L2Nwcy8yLjEvMAsGA1UdDwQEAwIE8DAdBgNV
HQ4EFgQUoGwEC61StaKysoyEYPDzqAdYOhIwHwYDVR0jBBgwFoAU9AxtbZ5fTGJWOYHg3vmP
LzeghMUwDQYJKoZIhvcNAQEFBQADggEBAOvBcYuC9wO+GTbDoAUuncMiFaXjNf0bpbi/2CKz
28EeQgdBSDaIGZtUR4Kf1etIhe26V4e7Jgj6674pR2gKq31cQWUvp5ie+tk1zvBaQf6axnBz
XUL7xSJuHNpR7OUSpOb2X7TzG5wAkRHirjz37Zljsp/y0UHWfh52C2DyvGuU1f75mqqskKdh
ZC+/R7geZq/4Iqe4xP5jWpW/cFbocMM4GWOFITHr5yaigg+hbLz/lb9oaXlYSvVoJRn+jwM4
M/FQjARxQdX6bgS5DPuPRcstzILrYtwULHv6K3N0nrV6lsKY6BM1JYkWvJU8KWGUzdgXMXEv
0B7uYWZN1RuR3IoxggLAMIICvAIBATBrMGUxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp
dGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eQICAWcwCQYFKw4DAhoFAKCCAaswGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNzIzMDgzODQ1WjAjBgkqhkiG9w0BCQQx
FgQU2s7EL/Zkjy9fFmXnF3Z5UjCzQtowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
egYJKwYBBAGCNxAEMW0wazBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28g
ZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkCAgFnMHwGCyqGSIb3DQEJEAILMW2gazBlMQswCQYDVQQGEwJJVDEeMBwG
A1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBU
b3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAgFnMA0GCSqGSIb3DQEBAQUABIGAWZYa
uEYVrYfnztmusQDJgLeJHO5VnLM/UYFdeDXTExaLiFty3zXXI/c6ovDXCGnPQUrmJ7szaR0r
vBe1ga9zUSKK9wCqbyJYFvkdlnaraHE5N3hBfFtpCeUGLp0bRMOy+XcuWsffuxAuJV947g2m
krBumvjwdYtasL0Sq+QuA7oAAAAAAAA=
--------------ms070000030901080401020603--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N8RmSY063756; Fri, 23 Jul 2004 01:27:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6N8RmV8063755; Fri, 23 Jul 2004 01:27:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N8RkqP063689 for <[e-mail]>; Fri, 23 Jul 2004 01:27:47 -0700 (PDT) (envelope-from [e-mail])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Jul 2004 10:27:33 +0200
Received: from [10.193.13.101] ([10.193.13.101]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jul 2004 10:27:33 +0200
Message-ID: <[e-mail]>
Date: Fri, 23 Jul 2004 10:27:32 +0200
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom R&D
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: PI: 10: Split Identity++
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jul 2004 08:27:33.0114 (UTC) FILETIME=[E6AF6DA0:01C4708E]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Manger, James H wrote:
 >
> URL vs OID:
> URLs as identifiers are fantastic: just by reading the URL you can often learn a lot, type it into a browser and (quite often) you can get a detailed explanation.  An OID is less human-friendly, but type it into google (instead of the address bar) and (quite often) you can get a detailed explanation just as easily.  The pervasiveness of OIDs in certs, there small size, structure and stability make them a good enough choice for identifying PI types.

Some information that may be of interest to your group:
- RFC 3061 (http://zvon.org/tmRFC/RFC3061/Output/) defines a URN for OIDs.
- There is a repository of 65,000+ OIDs at http://oid.elibel.tm.fr
- This repository offers a kind of OID resolution system by catenating 
your OID (in ASN.1 or dotted notation, see 
http://asn1.elibel.tm.fr/oid/faq.htm#6) after the URL 
http://oid.elibel.tm.fr/ (e.g., http://oid.elibel.tm.fr/1.3.6.1 )
- This repository is planned to get a more official status by moving to 
the ITU website (hopefully by the end of this year).
- It is planned to develop a web service for OID resolution (probably 
not before mid-2005).
-- 
Olivier DUBUISSON (ITU-T ASN.1 Project leader)
France Telecom
Recherche & Developpement / Research & Development Division
DR&D/MAPS/AMS - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N1XVea078630; Thu, 22 Jul 2004 18:33:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6N1XVJM078629; Thu, 22 Jul 2004 18:33:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailao.vtcif.telstra.com.au (mailao.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N1X1t2078557 for <[e-mail]>; Thu, 22 Jul 2004 18:33:30 -0700 (PDT) (envelope-from [e-mail])
Received: from mailai.vtcif.telstra.com.au (mailai.vtcif.telstra.com.au [202.12.142.17]) by mailao.vtcif.telstra.com.au (Postfix) with ESMTP id 541AC228A2 for <[e-mail]>; Fri, 23 Jul 2004 11:32:48 +1000 (EST)
Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id D72E71DA81 for <[e-mail]>; Fri, 23 Jul 2004 11:32:47 +1000 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 8A9C541E03 for <[e-mail]>; Fri, 23 Jul 2004 11:32:47 +1000 (EST)
content-class: urn:content-classes:message
Subject: RE: PI: 10: Split Identity++
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Fri, 23 Jul 2004 11:29:49 +1000
Message-ID: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: pkix-pi-10 - Split Identity++
Thread-Index: AcRwM/nnuG5n4u5OQByrH8lqZx6rjgAFFwNQ
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6N1XVt2078624
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

URL vs OID:
URLs as identifiers are fantastic: just by reading the URL you can often learn a lot, type it into a browser and (quite often) you can get a detailed explanation.  An OID is less human-friendly, but type it into google (instead of the address bar) and (quite often) you can get a detailed explanation just as easily.  The pervasiveness of OIDs in certs, there small size, structure and stability make them a good enough choice for identifying PI types.

	> O=http://registry.us.gov
A solution that enforces extra structure on DNs (eg inserting the assigner in the DN) does not sound like it will be too successful.  From your DN, it would be reasonable to guess that John Smith works for the registry department of the US government... but that is probably not what you meant.

The type, assigner and permanence of a value can be considered meta-data for that value.  It is not unreasonable (nor uncommon) to have the meta-data "half" somewhere else.

	> CN=John Smith, serialNumber=6756565, O=http://registry.us.gov, C=US
Even for your DN you still envisage a PI extension -- presumably to flag the O & SN attributes as a {PI-assigner, PI-value} pair.  Those flags are required to properly interpret the DN as a PI.  Hence, you will still have part of the identity somewhere else -- perhaps only a quarter, not a half ;-)



X.501 actually provides a mechanism to describe some meta-data about an attribute: the attribute type OID, its associated ATTRIBUTE object class value and the meta-data for its supertypes.  X.501 defines a limited variety of meta-data for an attribute, such as how to match & sort values and whether or not a value is unique for an entry.  The PI issue could be solved by extending this meta-data, defining some new generic types with well-defined permanence properties (eg employeeId, companyId), arranging them in a type hierarchy, subtyping specific PIs from those types, ensuring directories publish their schema and getting PKI products to consult that schema.  I see the PI certificate extension as a short cut to that sort of solution by representing a small part of the schema directly in a certificate in a specialised manner.

>  -----Original Message-----
> From: 	Anders Rundgren [mailto:[e-mail]] 
> Sent:	Friday, 23 July 2004 5:59 AM
> To:	[e-mail]
> Subject:	PI: 10: Split Identity++
> 
> Although I triggered the (un)deprecation of serialNumber as PI value objects, I am still not completely satisfied with the result.
> 
> Consider the following PI-enabled citizen certificate:
> 
>     CN=John Smith, serialNumber=6756565, C=US
>     PI-assigner: 2.4.4.282.2
> 
> I believe this would make more sense:
> 
>     CN=John Smith, serialNumber=6756565, O=http://registry.us.gov, C=US
> 
> Apart from pure esthetics, an advantage of putting the assigner in the DN as well, is that the DN becomes a TRUE SUPERSET of PI.  Using URIs, DNs in PI-augmented certificates also become TRUE globally unique identifiers (GUIDs).
> 
> Having one "half" of the identity in the DN and the other half somewhere else, is IMHO not a very "clean" solution.   No other PKI name constructs are designed that way AFAIK.
> 
> P.S. I did not bother with describing the PI extension in the second case as I would like to begin with the important stuff first D.S.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MK26lm048343; Thu, 22 Jul 2004 13:02:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MK25Lk048342; Thu, 22 Jul 2004 13:02:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-1-sn3.vrr.skanova.net (av1-1-sn3.vrr.skanova.net [81.228.9.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MK25cG048321 for <[e-mail]>; Thu, 22 Jul 2004 13:02:05 -0700 (PDT) (envelope-from [e-mail])
Received: by av1-1-sn3.vrr.skanova.net (Postfix, from userid 502) id CA93E37ECF; Thu, 22 Jul 2004 22:01:57 +0200 (CEST)
Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 4BEEB37E4C for <[e-mail]>; Thu, 22 Jul 2004 22:01:57 +0200 (CEST)
Received: from arport (t12o913p37.telia.com [213.64.28.157]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id 58C3D3800A for <[e-mail]>; Thu, 22 Jul 2004 22:01:56 +0200 (CEST)
Message-ID: <010601c47026$549ab630$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Re: pkix-pi-10 - Split Identity++
Date: Thu, 22 Jul 2004 21:58:59 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Although I triggered the (un)deprecation of serialNumber as PI
value objects, I am still not completely satisfied with the result.

Consider the following PI-enabled citizen certificate:

    CN=John Smith, serialNumber=6756565, C=US
    PI-assigner: 2.4.4.282.2

I believe this would make more sense:

    CN=John Smith, serialNumber=6756565, O=http://registry.us.gov, C=US

Apart from pure esthetics, an advantage of putting the assigner in the DN as
well, is that the DN becomes a TRUE SUPERSET of PI.  Using URIs,
DNs in PI-augmented certificates also become TRUE globally unique
identifiers (GUIDs).

Having one "half" of the identity in the DN and the other half somewhere
else, is IMHO not a very "clean" solution.   No other PKI name constructs
are designed that way AFAIK.

Anders R

P.S. I did not bother with describing the PI extension in the second
case as I would like to begin with the important stuff first D.S.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MIhbP6042580; Thu, 22 Jul 2004 11:43:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MIhbPE042579; Thu, 22 Jul 2004 11:43:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MIha5o042572 for <[e-mail]>; Thu, 22 Jul 2004 11:43:37 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6MIha841934 for <[e-mail]>; Thu, 22 Jul 2004 11:43:36 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: Re: SCVP-15
Date: Thu, 22 Jul 2004 11:42:54 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

Section 3.2.10, extracted below, is a good step forward to closure on
the issue.  Given its definition as a BOOLEAN in Query syntax, I am
comfortable with its default to TRUE.

The second paragraph however needs an implementable definition of DPD
vice DPV with respect to SCVP ASN.1 in order to assert that that a
request is in error if it asks for a validation assertion in the context
of signResponse set to FALSE.

Mike




3.2.10 signResponse

  The signResponse specifies if the client requires the server to
  sign a response to the validation request. If the client is
  performing full chain validation on the response and it is not
  concerned about the authenticity of the source of the data, then
  the client does not benefit from the signature on the response in
  which case it can indicate to the server that the signature is
  unnecessary via the signResponse value.

  SCVP clients that support DPD MUST support setting this value to
  FALSE. Since DPV responses must be signed, DPV only SCVP clients
  MUST NOT to support this value. SCVP servers SHOULD support
  returning unsigned responses. It is a local policy decision on the
  part of the server to return signed or unsigned responses if this
  value is set to FALSE.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MFFbd5024051; Thu, 22 Jul 2004 08:15:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MFFb8d024050; Thu, 22 Jul 2004 08:15:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6MFFa6w024042 for <[e-mail]>; Thu, 22 Jul 2004 08:15:36 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 3716 invoked by uid 0); 22 Jul 2004 15:08:24 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.94.19) by woodstock.binhost.com with SMTP; 22 Jul 2004 15:08:24 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Thu, 22 Jul 2004 08:08:12 -0400
To: "David P. Kemp" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave:

I reread it, and you are correct.

The first time I read it, the part that stuck with me was: "The set that 
forms an RDN contains exactly one AttributeTypeAndDistinguishedValue for 
each attribute which contains distinguished values in the entry ..."  Which 
made me think that non-distinguished values could employ a second instance 
of the same attribute type.  Not so.  It goes on to say: "... that is, a 
given attribute type cannot appear twice in the same RDN."

My issue is resolved.

Russ

At 03:57 PM 7/21/2004, David P. Kemp wrote:
>X.501 (02/2001) section 9.3, which appears to be normative,
>not informative, prohibits a given attribute type from
>appearing more than once in the same RDN.  The origin of
>Russ' comments regarding the possibility of multiple
>serialNumber attributes in a single RDN is unclear.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MDoDQ0015321; Thu, 22 Jul 2004 06:50:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MDoDnc015320; Thu, 22 Jul 2004 06:50:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk (ns3.worldcall.net.pk [203.81.192.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MDoBpj015310 for <[e-mail]>; Thu, 22 Jul 2004 06:50:12 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.200.124]) by ns3.worldcall.net.pk (8.12.5+Sun/8.12.5) with SMTP id i6MDjfTq023942; Thu, 22 Jul 2004 19:45:42 +0600 (PKST)
Message-ID: <00d501c46ff3$773d0400$[e-mail]>
From: "Faisal Maqsood" <[e-mail]>
To: <[e-mail]>
Subject: SCVP Structure Suggestions
Date: Thu, 22 Jul 2004 18:54:47 +0500
Organization: Ascertia Ltd
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D2_01C4701D.5C30C8C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00D2_01C4701D.5C30C8C0
Content-Type: text/plain;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

H=00i=00,=00=0D=00=0A=
=00=0D=00=0A=
=00I=00 =00h=00a=00v=00e=00 =00b=00e=00e=00n=00 =
=00l=00o=00o=00k=00i=00n=00g=00 =00a=00t=00 =00t=00h=00e=00 =
=00S=00C=00V=00P=00 =00D=00r=00a=00f=00t=00 =001=004=00 =00a=00n=00d=00 =
=00I=00 =00t=00h=00i=00n=00k=00 =00i=00t=00 =00c=00a=00n=00 =00b=00e=00 =
=00i=00m=00p=00r=00o=00v=00e=00d=00 =00a=00 =00b=00i=00t=00.=00 =00=0D=00=0A=
=00(=00I=00 =00k=00n=00o=00w=00 =00d=00r=00a=00f=00t=00 =001=005=00 =
=00i=00s=00 =00p=00u=00b=00l=00i=00s=00h=00e=00d=00 =00b=00u=00t=00 =
=00t=00h=00e=00s=00e=00 =00c=00h=00a=00n=00g=00e=00s=00 =00a=00r=00e=00 =
=00a=00l=00s=00o=00 =00n=00o=00t=00 =00t=00h=00e=00r=00e=00)=00=0D=00=0A=
=00=0D=00=0A=
=00N=00o=00t=00e=00:=00 =00M=00y=00 =00p=00r=00o=00p=00o=00s=00e=00d=00 =
=00A=00S=00N=00 =00S=00t=00r=00u=00c=00t=00u=00r=00e=00 =
=00m=00i=00g=00h=00t=00 =00n=00o=00t=00 =00b=00e=00 =001=000=000=00%=00 =
=00c=00o=00r=00r=00e=00c=00t=00 =00a=00n=00d=00 =00I=00 =
=00h=00a=00v=00e=00 =00n=00o=00t=00 =00f=00u=00l=00l=00y=00 =
=00c=00a=00l=00c=00u=00l=00a=00t=00e=00d=00 =00i=00t=00s=00 =
=00p=00r=00o=00s=00 =00o=00r=00 =00c=00o=00n=00s=00.=00=0D=00=0A=
=00 =00 =001=00.=00.=00 =00I=00 =00d=00o=00n=00'=00t=00 =
=00f=00i=00n=00d=00 =00a=00n=00y=00 =00g=00o=00o=00d=00 =
=00r=00e=00a=00s=00o=00n=00 =00o=00f=00 =00p=00l=00a=00c=00i=00n=00g=00 =
=00"=00r=00e=00q=00u=00e=00s=00t=00"=00 =00O=00c=00t=00e=00t=00 =
=00S=00t=00r=00i=00n=00g=00 =00i=00n=00s=00i=00d=00e=00 =
=00C=00V=00R=00e=00q=00u=00e=00s=00t=00.=00 =00I=00 =
=00t=00h=00i=00n=00k=00 =00i=00t=00 =00s=00h=00o=00u=00l=00d=00 =
=00b=00e=00 =00r=00e=00m=00o=00v=00e=00d=00 =00=0D=00=0A=
=00 =00 =002=00.=00.=00 =00T=00h=00e=00 =
=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00-=00>=00r=00e=00q=00u=00e=00s=00=
t=00 =00a=00n=00d=00 =
=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00-=00>=00r=00e=00s=00p=00o=00n=00=
s=00e=00 =00s=00h=00o=00u=00l=00d=00 =00a=00l=00s=00o=00 =00b=00e=00 =
=00r=00e=00m=00o=00v=00e=00d=00 =00a=00s=00 =00I=00 =
=00d=00o=00n=00'=00t=00 =00f=00i=00n=00d=00 =00a=00n=00y=00 =
=00r=00e=00a=00l=00 =00u=00s=00e=00 =00o=00f=00 =00t=00h=00i=00s=00.=00 =
=00=0D=00=0A=
=00 =00 =003=00.=00.=00 =00I=00n=00 =00t=00h=00e=00 =
=00C=00V=00R=00e=00q=00u=00e=00s=00t=00-=00>=00Q=00u=00e=00r=00y=00 =
=00o=00n=00e=00 =00c=00a=00n=00 =00s=00p=00e=00c=00i=00f=00y=00 =
=00C=00h=00e=00c=00k=00s=00 =00a=00n=00d=00 =
=00W=00a=00n=00t=00B=00a=00c=00k=00.=00 =00R=00e=00q=00u=00e=00s=00t=00 =
=00A=00S=00N=00S=00t=00r=00u=00c=00t=00u=00r=00e=00 =
=00s=00h=00o=00u=00l=00d=00 =00b=00e=00 =00s=00i=00m=00i=00l=00a=00r=00 =
=00t=00o=00 =00t=00h=00e=00 =00s=00t=00r=00a=00t=00e=00g=00y=00 =
=00u=00s=00e=00d=00 =00i=00n=00 =00t=00h=00e=00 =
=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00-=00>=00C=00e=00r=00t=00R=00e=00=
p=00l=00y=00 =00i=00.=00e=00 =00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =
=00a=00n=00d=00 =00W=00a=00n=00t=00B=00a=00c=00k=00 =
=00s=00h=00o=00u=00l=00d=00 =00a=00l=00s=00o=00 =00b=00e=00 =
=00p=00r=00e=00s=00e=00n=00t=00 =00a=00l=00o=00n=00g=00 =
=00w=00i=00t=00h=00 =00C=00e=00r=00t=00.=00 =00I=00 =
=00w=00o=00u=00l=00d=00 =00p=00r=00o=00p=00o=00s=00e=00 =00t=00h=00e=00 =
=00f=00o=00l=00l=00o=00w=00i=00n=00g=00 =
=00s=00t=00r=00u=00c=00t=00u=00r=00e=00.=00=0D=00=0A=
=00Q=00u=00e=00r=00y=00 =00:=00:=00=3D=00 =
=00S=00E=00Q=00U=00E=00N=00C=00E=00 =00{=00 =00=0D=00=0A=
=00 =00Q=00u=00e=00r=00i=00e=00d=00C=00e=00r=00t=00s=00 =
=00S=00E=00Q=00U=00E=00N=00C=00E=00 =00S=00I=00Z=00E=00 =
=00(=001=00.=00.=00M=00A=00X=00)=00 =00O=00F=00 =
=00C=00e=00r=00t=00C=00o=00n=00f=00i=00g=00,=00 =00=0D=00=0A=
=00 =00C=00h=00e=00c=00k=00s=00 =00 =00 =00 =00 =00[=000=00]=00 =
=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00,=00=0D=00=0A=
=00 =00W=00a=00n=00t=00B=00a=00c=00k=00 =00 =00 =00 =00[=001=00]=00 =
=00W=00a=00n=00t=00B=00a=00c=00k=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00,=00=0D=00=0A=
=00 =00.=00.=00.=00.=00.=00=0D=00=0A=
=00 =00 =00 =00 =00}=00=0D=00=0A=
=00=0D=00=0A=
=00C=00e=00r=00t=00C=00o=00n=00f=00i=00g=00:=00:=00=3D=00 =
=00S=00E=00Q=00U=00E=00N=00C=00E=00{=00=0D=00=0A=
=00 =00C=00e=00r=00t=00 =00 =
=00C=00e=00r=00t=00R=00e=00f=00e=00r=00e=00n=00c=00e=00,=00=0D=00=0A=
=00 =00C=00h=00e=00c=00k=00s=00 =00 =00 =00 =00 =00 =00[=000=00]=00 =
=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00,=00 =00 =00 =00=0D=00=0A=
=00 =00W=00a=00n=00t=00B=00a=00c=00k=00 =00 =00 =00 =00[=001=00]=00 =
=00W=00a=00n=00t=00B=00a=00c=00k=00 =00 =00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00=0D=00=0A=
=00}=00=0D=00=0A=
=00=0D=00=0A=
=00=0D=00=0A=
=00N=00o=00t=00e=00:=00 =00P=00l=00a=00c=00i=00n=00g=00 =
=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =00a=00n=00d=00 =
=00W=00a=00n=00t=00B=00a=00c=00k=00 =00i=00n=00 =
=00R=00e=00f=00e=00r=00e=00n=00c=00e=00 =00A=00S=00N=00 =
=00S=00t=00r=00u=00c=00t=00u=00r=00e=00 =00h=00a=00v=00e=00 =003=00 =
=00b=00e=00n=00e=00f=00i=00t=00s=00 =00=0D=00=0A=
=00 =00 =00a=00.=00.=00 =00U=00s=00e=00r=00 =00c=00a=00n=00 =
=00d=00e=00f=00i=00n=00e=00 =00W=00a=00n=00t=00B=00a=00c=00k=00,=00 =
=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =00f=00o=00r=00 =
=00e=00a=00c=00h=00 =00C=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =
=00s=00e=00p=00e=00r=00a=00t=00e=00l=00y=00 =
=00p=00r=00o=00v=00i=00d=00i=00n=00g=00 =00g=00r=00e=00a=00t=00e=00r=00 =
=00f=00l=00e=00x=00i=00b=00i=00l=00i=00t=00y=00.=00 =00T=00h=00e=00 =
=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00-=00>=00C=00e=00r=00t=00R=00e=00=
p=00l=00y=00 =00A=00S=00N=00 =00s=00t=00r=00u=00c=00t=00u=00r=00e=00 =
=00a=00l=00r=00e=00a=00d=00y=00 =00s=00u=00p=00p=00o=00r=00t=00s=00 =
=00s=00e=00p=00e=00r=00a=00t=00e=00 =
=00W=00a=00n=00t=00B=00a=00c=00k=00,=00 =
=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =00f=00o=00r=00 =
=00e=00a=00c=00h=00 =00C=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00.=00 =
=00=0D=00=0A=
=00 =00 =00b=00.=00.=00 =00W=00a=00n=00t=00B=00a=00c=00k=00,=00 =
=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =00i=00n=00s=00i=00d=00e=00 =
=00C=00V=00R=00e=00q=00u=00e=00s=00t=00-=00>=00Q=00u=00e=00r=00y=00 =
=00A=00S=00N=00 =00S=00t=00r=00u=00c=00t=00u=00r=00e=00 =
=00s=00h=00o=00u=00l=00d=00 =00r=00e=00m=00a=00i=00n=00 =00t=00o=00 =
=00p=00r=00o=00v=00i=00d=00e=00 =00d=00e=00f=00a=00u=00l=00t=00 =
=00s=00e=00t=00t=00i=00n=00g=00s=00 =00b=00u=00t=00 =
=00w=00o=00u=00l=00d=00 =00b=00e=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00.=00 =00I=00f=00 =00i=00n=00 =
=00C=00e=00r=00t=00C=00o=00n=00f=00i=00g=00 =00o=00n=00e=00 =
=00d=00o=00e=00s=00 =00n=00o=00t=00 =00p=00r=00o=00v=00i=00d=00e=00 =
=00W=00a=00n=00t=00B=00a=00c=00k=00 =00a=00n=00d=00 =
=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =00t=00h=00e=00n=00 =
=00t=00h=00e=00s=00e=00 =00d=00e=00f=00a=00u=00l=00t=00 =
=00v=00a=00l=00u=00e=00s=00 =
=00(=00C=00V=00R=00e=00q=00u=00e=00s=00t=00-=00>=00Q=00u=00e=00r=00y=00-=00=
>=00W=00a=00n=00t=00B=00a=00c=00k=00,=00 =
=00C=00V=00R=00e=00q=00u=00e=00s=00t=00-=00>=00Q=00u=00e=00r=00y=00-=00>=00=
C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00)=00 =00M=00U=00S=00T=00 =
=00b=00e=00 =00p=00r=00e=00s=00e=00n=00t=00 =00a=00n=00d=00 =
=00u=00s=00e=00d=00.=00 =00=0D=00=0A=
=00 =00 =00c=00.=00.=00 =00B=00e=00n=00e=00f=00i=00t=00 =00o=00f=00 =
=00p=00r=00o=00v=00i=00d=00i=00n=00g=00 =00C=00h=00e=00c=00k=00s=00 =
=00a=00n=00d=00 =00W=00a=00n=00t=00B=00a=00c=00k=00 =
=00i=00n=00s=00i=00d=00e=00 =00Q=00u=00e=00r=00y=00 =
=00w=00o=00u=00l=00d=00 =00b=00e=00 =00t=00o=00 =00a=00l=00l=00o=00w=00 =
=00s=00o=00m=00e=00 =00o=00r=00 =00a=00l=00l=00 =00o=00f=00 =
=00t=00h=00e=00 =00C=00e=00r=00t=00 =00i=00n=00s=00i=00d=00e=00 =
=00C=00e=00r=00t=00C=00o=00n=00f=00i=00g=00 =00t=00o=00 =00u=00s=00e=00 =
=00d=00e=00f=00a=00u=00l=00t=00 =00C=00h=00e=00c=00k=00s=00 =00+=00 =
=00W=00a=00n=00t=00B=00a=00c=00k=00 =00s=00e=00t=00t=00i=00n=00g=00s=00 =
=00t=00h=00u=00s=00 =00r=00e=00d=00u=00c=00i=00n=00g=00 =
=00C=00V=00R=00e=00q=00u=00e=00s=00t=00 =00s=00i=00z=00e=00 =
=00a=00n=00d=00 =00t=00h=00u=00s=00 =00r=00e=00d=00u=00c=00e=00s=00 =
=00n=00e=00t=00w=00o=00r=00k=00 =00l=00o=00a=00d=00.=00=0D=00=0A=
=00 =00 =00 =00 =004=00.=00 =00 =00 =00 =
=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00s=00t=00r=00u=00c=00t=00u=00r=00e=00 =00n=00e=00e=00d=00s=00 =
=00a=00l=00s=00o=00 =00t=00o=00 =00b=00e=00 =00u=00p=00d=00a=00t=00e=00 =
=00t=00o=00 =00m=00a=00p=00 =00w=00i=00t=00h=00 =
=00C=00V=00R=00e=00q=00u=00e=00s=00t=00 =00o=00p=00t=00i=00o=00n=00s=00 =
=00b=00y=00 =00i=00n=00t=00r=00o=00d=00u=00c=00i=00n=00g=00 =
=00t=00w=00o=00 =00n=00e=00w=00 =00o=00p=00t=00i=00o=00n=00a=00l=00 =
=00o=00b=00j=00e=00c=00t=00s=00 =00a=00s=00 =
=00b=00e=00l=00o=00w=00:=00=0D=00=0A=
=00=0D=00=0A=
=00 =00 =00 =00 =00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00:=00:=00=3D=00 =00S=00E=00Q=00U=00E=00N=00C=00E=00 =00{=00 =00=0D=00=0A=
=00 =00 =00 =00 =00 =00 =00 =00 =00 =
=00s=00c=00v=00p=00V=00e=00r=00s=00i=00o=00n=00 =
=00I=00N=00T=00E=00G=00E=00R=00,=00 =00=0D=00=0A=
=00 =00 =00 =00 =00 =00 =00 =00 =00 =00.=00.=00.=00.=00.=00.=00.=00=0D=00=0A=
=00 =00 =00 =00 =00 =00 =00 =00 =00 =
=00R=00e=00p=00l=00y=00C=00h=00e=00c=00k=00s=00 =00[=008=00]=00 =
=00R=00e=00p=00l=00y=00C=00h=00e=00c=00k=00s=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00,=00 =00=0D=00=0A=
=00 =00 =00 =00 =00 =00 =00 =00 =00 =
=00R=00e=00p=00l=00y=00W=00a=00n=00t=00B=00a=00c=00k=00s=00 =
=00[=009=00]=00 =
=00R=00e=00p=00l=00y=00W=00a=00n=00t=00B=00a=00c=00k=00s=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00=0D=00=0A=
=00 =00 =00 =00 =00 =00}=00=0D=00=0A=
=00=0D=00=0A=
=00I=00n=00 =00a=00d=00d=00i=00t=00i=00o=00n=00 =
=00C=00e=00r=00t=00R=00e=00p=00l=00y=00 =
=00A=00S=00N=00S=00t=00r=00u=00c=00t=00u=00r=00e=00 =
=00s=00h=00o=00u=00l=00d=00 =00a=00l=00s=00o=00 =00b=00e=00 =
=00c=00h=00a=00n=00g=00e=00d=00 =00t=00o=00 =00m=00a=00k=00e=00 =
=00R=00e=00p=00l=00y=00C=00h=00e=00c=00k=00s=00 =00a=00n=00d=00 =
=00R=00e=00p=00l=00y=00W=00a=00n=00t=00B=00a=00c=00k=00s=00 =00a=00s=00 =
=00o=00p=00t=00i=00o=00n=00a=00l=00.=00=0D=00=0A=
=00=0D=00=0A=
=00A=00l=00s=00o=00 =00i=00n=00 =00Q=00u=00e=00r=00y=00,=00 =
=00a=00l=00l=00 =00f=00l=00a=00g=00s=00 =
=00(=00R=00e=00q=00u=00e=00s=00t=00R=00e=00f=00H=00a=00s=00h=00,=00 =
=00I=00n=00c=00l=00u=00d=00e=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00=
,=00 =00I=00n=00h=00i=00b=00i=00t=00P=00o=00l=00M=00a=00p=00,=00 =
=00R=00e=00q=00u=00i=00r=00e=00E=00x=00p=00l=00i=00c=00i=00t=00P=00o=00l=00=
,=00 =00I=00g=00n=00o=00r=00e=00A=00n=00y=00P=00o=00l=00,=00 =
=00I=00s=00C=00A=00)=00 =00s=00h=00o=00u=00l=00d=00 =00b=00e=00 =
=00o=00p=00t=00i=00o=00n=00a=00l=00 =00i=00n=00s=00t=00e=00a=00d=00 =
=00o=00f=00 =00m=00e=00n=00d=00a=00t=00o=00r=00y=00 =00a=00s=00 =
=00a=00l=00l=00 =00t=00h=00e=00s=00e=00 =00h=00a=00v=00e=00 =
=00d=00e=00f=00a=00u=00l=00t=00 =00v=00a=00l=00u=00e=00s=00 =
=00a=00n=00d=00 =00t=00o=00 =00m=00a=00k=00e=00 =00t=00h=00e=00s=00e=00 =
=00o=00p=00t=00i=00o=00n=00a=00l=00 =00w=00i=00l=00l=00 =
=00r=00e=00d=00u=00c=00e=00 =00n=00e=00t=00w=00o=00r=00k=00 =
=00l=00o=00a=00d=00.=00=0D=00=0A=
=00=0D=00=0A=
=00R=00e=00g=00a=00r=00d=00s=00,=00=0D=00=0A=
=00F=00a=00i=00s=00a=00l=00 =00M=00a=00q=00s=00o=00o=00d=00=0D=00=0A=
=00=0D=00=0A=
=00
------=_NextPart_000_00D2_01C4701D.5C30C8C0
Content-Type: text/html;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

=FF=FE<=00!=00D=00O=00C=00T=00Y=00P=00E=00 =00H=00T=00M=00L=00 =
=00P=00U=00B=00L=00I=00C=00 =
=00"=00-=00/=00/=00W=003=00C=00/=00/=00D=00T=00D=00 =00H=00T=00M=00L=00 =
=004=00.=000=00 =
=00T=00r=00a=00n=00s=00i=00t=00i=00o=00n=00a=00l=00/=00/=00E=00N=00"=00>=00=
=0D=00=0A=
=00<=00H=00T=00M=00L=00 =00x=00m=00l=00n=00s=00:=00s=00t=001=00 =
=00=3D=00 =
=00"=00u=00r=00n=00:=00s=00c=00h=00e=00m=00a=00s=00-=00m=00i=00c=00r=00o=00=
s=00o=00f=00t=00-=00c=00o=00m=00:=00o=00f=00f=00i=00c=00e=00:=00s=00m=00a=
=00r=00t=00t=00a=00g=00s=00"=00 =00x=00m=00l=00n=00s=00:=00o=00 =
=00=3D=00 =00=0D=00=0A=
=00"=00u=00r=00n=00:=00s=00c=00h=00e=00m=00a=00s=00-=00m=00i=00c=00r=00o=00=
s=00o=00f=00t=00-=00c=00o=00m=00:=00o=00f=00f=00i=00c=00e=00:=00o=00f=00f=
=00i=00c=00e=00"=00>=00<=00H=00E=00A=00D=00>=00<=00B=00A=00S=00E=00 =
=00=0D=00=0A=
=00h=00r=00e=00f=00=3D=00"=00f=00i=00l=00e=00:=00/=00/=00F=00:=00\=00_=00=
B=00a=00c=00k=00U=00p=00-=00F=00M=00\=00E=00m=00a=00i=00l=00 =
=00S=00i=00g=00n=00a=00t=00u=00r=00e=00\=00"=00>=00=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00h=00t=00t=00p=00-=00e=00q=00u=00i=00v=00=3D=00C=00o=00n=00t=00e=00n=00=
t=00-=00T=00y=00p=00e=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00t=00e=00x=00t=00/=00h=00t=00m=00=
l=00;=00 =
=00c=00h=00a=00r=00s=00e=00t=00=3D=00u=00n=00i=00c=00o=00d=00e=00"=00>=00=
=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00M=00L=00 =
=005=00.=005=000=00.=004=001=003=004=00.=006=000=000=00"=00 =
=00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00<=00/=00=
H=00E=00A=00D=00>=00=0D=00=0A=
=00<=00B=00O=00D=00Y=00 =
=00b=00g=00C=00o=00l=00o=00r=00=3D=00#=00f=00f=00f=00f=00f=00f=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00H=00i=00,=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00I=00 =00h=00a=00v=00e=00 =00b=00e=00e=00n=00 =
=00l=00o=00o=00k=00i=00n=00g=00 =00a=00t=00 =00t=00h=00e=00 =
=00S=00C=00V=00P=00 =00D=00r=00a=00f=00t=00 =001=004=00 =00a=00n=00d=00 =
=00I=00 =00t=00h=00i=00n=00k=00 =00i=00t=00 =00c=00a=00n=00 =00b=00e=00 =
=00i=00m=00p=00r=00o=00v=00e=00d=00 =00a=00 =00=0D=00=0A=
=00b=00i=00t=00.=00 =00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00(=00I=00 =00k=00n=00o=00w=00 =
=00d=00r=00a=00f=00t=00 =001=005=00 =00i=00s=00 =
=00p=00u=00b=00l=00i=00s=00h=00e=00d=00 =00b=00u=00t=00 =
=00t=00h=00e=00s=00e=00 =00c=00h=00a=00n=00g=00e=00s=00 =00a=00r=00e=00 =
=00a=00l=00s=00o=00 =00n=00o=00t=00 =
=00t=00h=00e=00r=00e=00)=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00N=00o=00t=00e=00:=00&=00n=00b=00s=00p=00;=00M=00y=00=
 =00p=00r=00o=00p=00o=00s=00e=00d=00 =00A=00S=00N=00 =
=00S=00t=00r=00u=00c=00t=00u=00r=00e=00 =00m=00i=00g=00h=00t=00 =
=00n=00o=00t=00 =00b=00e=00 =001=000=000=00%=00 =
=00c=00o=00r=00r=00e=00c=00t=00 =00a=00n=00d=00 =00I=00 =
=00h=00a=00v=00e=00 =00=0D=00=0A=
=00n=00o=00t=00 =00f=00u=00l=00l=00y=00 =
=00c=00a=00l=00c=00u=00l=00a=00t=00e=00d=00 =00i=00t=00s=00 =
=00p=00r=00o=00s=00 =00o=00r=00 =
=00c=00o=00n=00s=00.=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00O=00L=00>=00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00I=00 =00d=00o=00n=00'=00t=00 =
=00f=00i=00n=00d=00 =00a=00n=00y=00 =00g=00o=00o=00d=00 =
=00r=00e=00a=00s=00o=00n=00 =00o=00f=00 =00p=00l=00a=00c=00i=00n=00g=00 =
=00"=00r=00e=00q=00u=00e=00s=00t=00"=00 =00O=00c=00t=00e=00t=00 =
=00S=00t=00r=00i=00n=00g=00 =00i=00n=00s=00i=00d=00e=00 =00=0D=00=0A=
=00 =00 =00C=00V=00R=00e=00q=00u=00e=00s=00t=00.=00 =00I=00 =
=00t=00h=00i=00n=00k=00 =00i=00t=00 =00s=00h=00o=00u=00l=00d=00 =
=00b=00e=00 =00r=00e=00m=00o=00v=00e=00d=00 =00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00T=00h=00e=00 =
=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00-=00&=00g=00t=00;=00r=00e=00q=00=
u=00e=00s=00t=00 =00a=00n=00d=00 =
=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00-=00&=00g=00t=00;=00r=00e=00s=00=
p=00o=00n=00s=00e=00 =00s=00h=00o=00u=00l=00d=00 =00a=00l=00s=00o=00 =
=00b=00e=00 =00=0D=00=0A=
=00 =00 =00r=00e=00m=00o=00v=00e=00d=00 =00a=00s=00 =00I=00 =
=00d=00o=00n=00'=00t=00 =00f=00i=00n=00d=00 =00a=00n=00y=00 =
=00r=00e=00a=00l=00 =00u=00s=00e=00 =00o=00f=00 =00t=00h=00i=00s=00.=00 =
=00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00I=00n=00 =00t=00h=00e=00 =
=00C=00V=00R=00e=00q=00u=00e=00s=00t=00-=00&=00g=00t=00;=00Q=00u=00e=00r=00=
y=00 =00o=00n=00e=00 =00c=00a=00n=00 =00s=00p=00e=00c=00i=00f=00y=00 =
=00C=00h=00e=00c=00k=00s=00 =00a=00n=00d=00 =
=00W=00a=00n=00t=00B=00a=00c=00k=00.=00 =00R=00e=00q=00u=00e=00s=00t=00 =
=00=0D=00=0A=
=00 =00 =00A=00S=00N=00S=00t=00r=00u=00c=00t=00u=00r=00e=00 =
=00s=00h=00o=00u=00l=00d=00 =00b=00e=00 =00s=00i=00m=00i=00l=00a=00r=00 =
=00t=00o=00 =00t=00h=00e=00 =00s=00t=00r=00a=00t=00e=00g=00y=00 =
=00u=00s=00e=00d=00 =00i=00n=00 =00t=00h=00e=00 =00=0D=00=0A=
=00 =00 =
=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00-=00&=00g=00t=00;=00C=00e=00r=00=
t=00R=00e=00p=00l=00y=00 =00i=00.=00e=00 =
=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =00a=00n=00d=00 =
=00W=00a=00n=00t=00B=00a=00c=00k=00 =00s=00h=00o=00u=00l=00d=00 =
=00a=00l=00s=00o=00 =00b=00e=00 =00p=00r=00e=00s=00e=00n=00t=00 =00=0D=00=0A=
=00 =00 =00a=00l=00o=00n=00g=00 =00w=00i=00t=00h=00 =
=00C=00e=00r=00t=00.=00 =00I=00 =00w=00o=00u=00l=00d=00 =
=00p=00r=00o=00p=00o=00s=00e=00 =00t=00h=00e=00 =
=00f=00o=00l=00l=00o=00w=00i=00n=00g=00 =
=00s=00t=00r=00u=00c=00t=00u=00r=00e=00.=00<=00/=00L=00I=00>=00<=00/=00O=00=
L=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00Q=00u=00e=00r=00y=00 =00:=00:=00=3D=00 =
=00S=00E=00Q=00U=00E=00N=00C=00E=00 =00{=00 =
=00<=00B=00R=00>=00&=00n=00b=00s=00p=00;=00Q=00u=00e=00r=00i=00e=00d=00C=00=
e=00r=00t=00s=00&=00n=00b=00s=00p=00;=00S=00E=00Q=00U=00E=00N=00C=00E=00 =
=00S=00I=00Z=00E=00 =00(=001=00.=00.=00M=00A=00X=00)=00 =00O=00F=00 =
=00=0D=00=0A=
=00C=00e=00r=00t=00C=00o=00n=00f=00i=00g=00,=00 =
=00<=00B=00R=00>=00&=00n=00b=00s=00p=00;=00C=00h=00e=00c=00k=00s=00&=00n=00=
b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00b=
=00s=00p=00;=00 =
=00[=000=00]=00&=00n=00b=00s=00p=00;=00C=00e=00r=00t=00C=00h=00e=00c=00k=00=
s=00 =00=0D=00=0A=
=00O=00P=00T=00I=00O=00N=00A=00L=00,=00<=00B=00R=00>=00&=00n=00b=00s=00p=00=
;=00W=00a=00n=00t=00B=00a=00c=00k=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=
=00p=00;=00&=00n=00b=00s=00p=00;=00 =
=00[=001=00]=00&=00n=00b=00s=00p=00;=00W=00a=00n=00t=00B=00a=00c=00k=00 =
=00=0D=00=0A=
=00O=00P=00T=00I=00O=00N=00A=00L=00,=00<=00B=00R=00>=00&=00n=00b=00s=00p=00=
;=00.=00.=00.=00.=00.=00<=00B=00R=00>=00&=00n=00b=00s=00p=00;=00&=00n=00b=
=00s=00p=00;=00&=00n=00b=00s=00p=00;=00 =
=00}=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00C=00e=00r=00t=00C=00o=00n=00f=00i=00g=00:=00:=00=3D=
=00 =00=0D=00=0A=
=00S=00E=00Q=00U=00E=00N=00C=00E=00{=00<=00B=00R=00>=00&=00n=00b=00s=00p=00=
;=00C=00e=00r=00t=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00C=00e=
=00r=00t=00R=00e=00f=00e=00r=00e=00n=00c=00e=00,=00<=00B=00R=00>=00&=00n=00=
b=00s=00p=00;=00C=00h=00e=00c=00k=00s=00&=00n=00b=00s=00p=00;=00&=00n=00b=
=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00b=00=
s=00p=00;=00 =00=0D=00=0A=
=00[=000=00]=00&=00n=00b=00s=00p=00;=00C=00e=00r=00t=00C=00h=00e=00c=00k=00=
s=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00,=00&=00n=00b=00s=00p=00;=00&=00n=00b=00=
s=00p=00;=00 =
=00<=00B=00R=00>=00&=00n=00b=00s=00p=00;=00W=00a=00n=00t=00B=00a=00c=00k=00=
&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00 =
=00=0D=00=0A=
=00[=001=00]=00&=00n=00b=00s=00p=00;=00W=00a=00n=00t=00B=00a=00c=00k=00&=00=
n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00<=00B=00R=00>=00}=00<=00/=00D=00I=00V=00=
>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00<=00B=00R=00>=00N=00o=00t=00e=00:=00 =
=00P=00l=00a=00c=00i=00n=00g=00 =
=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =00a=00n=00d=00 =
=00W=00a=00n=00t=00B=00a=00c=00k=00 =00i=00n=00 =
=00R=00e=00f=00e=00r=00e=00n=00c=00e=00 =00A=00S=00N=00 =
=00S=00t=00r=00u=00c=00t=00u=00r=00e=00 =00h=00a=00v=00e=00 =003=00 =
=00=0D=00=0A=
=00b=00e=00n=00e=00f=00i=00t=00s=00 =00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00U=00L=00>=00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00U=00s=00e=00r=00 =00c=00a=00n=00 =
=00d=00e=00f=00i=00n=00e=00 =00W=00a=00n=00t=00B=00a=00c=00k=00,=00 =
=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =00f=00o=00r=00 =
=00e=00a=00c=00h=00 =00C=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =
=00s=00e=00p=00e=00r=00a=00t=00e=00l=00y=00 =00=0D=00=0A=
=00 =00 =00p=00r=00o=00v=00i=00d=00i=00n=00g=00 =
=00g=00r=00e=00a=00t=00e=00r=00 =
=00f=00l=00e=00x=00i=00b=00i=00l=00i=00t=00y=00.=00 =00T=00h=00e=00 =
=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00-=00&=00g=00t=00;=00C=00e=00r=00=
t=00R=00e=00p=00l=00y=00 =00A=00S=00N=00 =
=00s=00t=00r=00u=00c=00t=00u=00r=00e=00 =00=0D=00=0A=
=00 =00 =00a=00l=00r=00e=00a=00d=00y=00 =
=00s=00u=00p=00p=00o=00r=00t=00s=00 =00s=00e=00p=00e=00r=00a=00t=00e=00 =
=00W=00a=00n=00t=00B=00a=00c=00k=00,=00 =
=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =00f=00o=00r=00 =
=00e=00a=00c=00h=00 =00C=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00.=00 =
=00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00W=00a=00n=00t=00B=00a=00c=00k=00,=00 =
=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =00i=00n=00s=00i=00d=00e=00 =
=00C=00V=00R=00e=00q=00u=00e=00s=00t=00-=00&=00g=00t=00;=00Q=00u=00e=00r=00=
y=00 =00A=00S=00N=00 =00S=00t=00r=00u=00c=00t=00u=00r=00e=00 =
=00s=00h=00o=00u=00l=00d=00 =00=0D=00=0A=
=00 =00 =00r=00e=00m=00a=00i=00n=00 =00t=00o=00 =
=00p=00r=00o=00v=00i=00d=00e=00 =00d=00e=00f=00a=00u=00l=00t=00 =
=00s=00e=00t=00t=00i=00n=00g=00s=00 =00b=00u=00t=00 =
=00w=00o=00u=00l=00d=00 =00b=00e=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00.=00 =00I=00f=00 =00i=00n=00 =
=00C=00e=00r=00t=00C=00o=00n=00f=00i=00g=00 =00o=00n=00e=00 =00=0D=00=0A=
=00 =00 =00d=00o=00e=00s=00 =00n=00o=00t=00 =
=00p=00r=00o=00v=00i=00d=00e=00 =00W=00a=00n=00t=00B=00a=00c=00k=00 =
=00a=00n=00d=00 =00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00 =
=00t=00h=00e=00n=00 =00t=00h=00e=00s=00e=00 =
=00d=00e=00f=00a=00u=00l=00t=00 =00v=00a=00l=00u=00e=00s=00 =00=0D=00=0A=
=00 =00 =
=00(=00C=00V=00R=00e=00q=00u=00e=00s=00t=00-=00&=00g=00t=00;=00Q=00u=00e=00=
r=00y=00-=00&=00g=00t=00;=00W=00a=00n=00t=00B=00a=00c=00k=00,=00 =
=00C=00V=00R=00e=00q=00u=00e=00s=00t=00-=00&=00g=00t=00;=00Q=00u=00e=00r=00=
y=00-=00&=00g=00t=00;=00C=00e=00r=00t=00C=00h=00e=00c=00k=00s=00)=00 =
=00M=00U=00S=00T=00 =00b=00e=00 =00=0D=00=0A=
=00 =00 =00p=00r=00e=00s=00e=00n=00t=00 =00a=00n=00d=00 =
=00u=00s=00e=00d=00.=00 =00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00B=00e=00n=00e=00f=00i=00t=00 =00o=00f=00 =
=00p=00r=00o=00v=00i=00d=00i=00n=00g=00 =00C=00h=00e=00c=00k=00s=00 =
=00a=00n=00d=00 =00W=00a=00n=00t=00B=00a=00c=00k=00 =
=00i=00n=00s=00i=00d=00e=00 =00Q=00u=00e=00r=00y=00 =
=00w=00o=00u=00l=00d=00 =00b=00e=00 =00t=00o=00 =00a=00l=00l=00o=00w=00 =
=00=0D=00=0A=
=00 =00 =00s=00o=00m=00e=00 =00o=00r=00 =00a=00l=00l=00 =00o=00f=00 =
=00t=00h=00e=00 =00C=00e=00r=00t=00 =00i=00n=00s=00i=00d=00e=00 =
=00C=00e=00r=00t=00C=00o=00n=00f=00i=00g=00 =00t=00o=00 =00u=00s=00e=00 =
=00d=00e=00f=00a=00u=00l=00t=00 =00C=00h=00e=00c=00k=00s=00 =00+=00 =
=00W=00a=00n=00t=00B=00a=00c=00k=00 =00=0D=00=0A=
=00 =00 =00s=00e=00t=00t=00i=00n=00g=00s=00 =00t=00h=00u=00s=00 =
=00r=00e=00d=00u=00c=00i=00n=00g=00 =
=00C=00V=00R=00e=00q=00u=00e=00s=00t=00 =00s=00i=00z=00e=00 =
=00a=00n=00d=00 =00t=00h=00u=00s=00 =00r=00e=00d=00u=00c=00e=00s=00 =
=00n=00e=00t=00w=00o=00r=00k=00 =
=00l=00o=00a=00d=00.=00<=00/=00L=00I=00>=00<=00/=00U=00L=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00=
n=00b=00s=00p=00;=00 =
=004=00.=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00=
p=00;=00 =00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00s=00t=00r=00u=00c=00t=00u=00r=00e=00 =00n=00e=00e=00d=00s=00 =
=00a=00l=00s=00o=00 =00t=00o=00 =00=0D=00=0A=
=00b=00e=00 =00u=00p=00d=00a=00t=00e=00 =00t=00o=00 =00m=00a=00p=00 =
=00w=00i=00t=00h=00 =00C=00V=00R=00e=00q=00u=00e=00s=00t=00 =
=00o=00p=00t=00i=00o=00n=00s=00 =00b=00y=00 =
=00i=00n=00t=00r=00o=00d=00u=00c=00i=00n=00g=00 =00t=00w=00o=00 =
=00n=00e=00w=00 =00o=00p=00t=00i=00o=00n=00a=00l=00 =
=00o=00b=00j=00e=00c=00t=00s=00 =00=0D=00=0A=
=00a=00s=00 =00b=00e=00l=00o=00w=00:=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00=
n=00b=00s=00p=00;=00 =00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00:=00:=00=3D=00 =00S=00E=00Q=00U=00E=00N=00C=00E=00 =00{=00 =
=00<=00B=00R=00>=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00=
b=00s=00p=00;=00 =00=0D=00=0A=
=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00=
 =
=00&=00n=00b=00s=00p=00;=00s=00c=00v=00p=00V=00e=00r=00s=00i=00o=00n=00&=00=
n=00b=00s=00p=00;=00I=00N=00T=00E=00G=00E=00R=00,=00&=00n=00b=00s=00p=00;=
=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00=
n=00b=00s=00p=00;=00 =
=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00=
&=00n=00b=00s=00p=00;=00 =00=0D=00=0A=
=00.=00.=00.=00.=00.=00.=00.=00<=00B=00R=00>=00&=00n=00b=00s=00p=00;=00&=00=
n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=
=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00=
b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00R=00e=00p=00l=00y=00C=00h=00e=00c=
=00k=00s=00&=00n=00b=00s=00p=00;=00[=008=00]=00 =00=0D=00=0A=
=00R=00e=00p=00l=00y=00C=00h=00e=00c=00k=00s=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00,=00 =
=00<=00B=00R=00>=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00=
b=00s=00p=00;=00 =
=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00=
 =00=0D=00=0A=
=00&=00n=00b=00s=00p=00;=00R=00e=00p=00l=00y=00W=00a=00n=00t=00B=00a=00c=00=
k=00s=00&=00n=00b=00s=00p=00;=00[=009=00]=00 =
=00R=00e=00p=00l=00y=00W=00a=00n=00t=00B=00a=00c=00k=00s=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00<=00B=00R=00>=00&=00n=00b=00s=00p=00;=00=
&=00n=00b=00s=00p=00;=00&=00n=00b=00s=00p=00;=00 =00=0D=00=0A=
=00&=00n=00b=00s=00p=00;=00}=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00I=00n=00 =00a=00d=00d=00i=00t=00i=00o=00n=00 =
=00C=00e=00r=00t=00R=00e=00p=00l=00y=00 =
=00A=00S=00N=00S=00t=00r=00u=00c=00t=00u=00r=00e=00 =
=00s=00h=00o=00u=00l=00d=00 =00a=00l=00s=00o=00 =00b=00e=00 =
=00c=00h=00a=00n=00g=00e=00d=00 =00t=00o=00 =00m=00a=00k=00e=00 =00=0D=00=0A=
=00R=00e=00p=00l=00y=00C=00h=00e=00c=00k=00s=00 =00a=00n=00d=00 =
=00R=00e=00p=00l=00y=00W=00a=00n=00t=00B=00a=00c=00k=00s=00 =00a=00s=00 =
=00o=00p=00t=00i=00o=00n=00a=00l=00.=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00A=00l=00s=00o=00 =00i=00n=00 =
=00Q=00u=00e=00r=00y=00,=00 =00a=00l=00l=00 =00f=00l=00a=00g=00s=00 =
=00(=00R=00e=00q=00u=00e=00s=00t=00R=00e=00f=00H=00a=00s=00h=00,=00 =
=00I=00n=00c=00l=00u=00d=00e=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00=
,=00 =00=0D=00=0A=
=00I=00n=00h=00i=00b=00i=00t=00P=00o=00l=00M=00a=00p=00,=00 =
=00R=00e=00q=00u=00i=00r=00e=00E=00x=00p=00l=00i=00c=00i=00t=00P=00o=00l=00=
,=00 =00I=00g=00n=00o=00r=00e=00A=00n=00y=00P=00o=00l=00,=00 =
=00I=00s=00C=00A=00)=00 =00s=00h=00o=00u=00l=00d=00 =00b=00e=00 =
=00o=00p=00t=00i=00o=00n=00a=00l=00 =00=0D=00=0A=
=00i=00n=00s=00t=00e=00a=00d=00 =00o=00f=00 =
=00m=00e=00n=00d=00a=00t=00o=00r=00y=00 =00a=00s=00 =00a=00l=00l=00 =
=00t=00h=00e=00s=00e=00 =00h=00a=00v=00e=00 =
=00d=00e=00f=00a=00u=00l=00t=00 =00v=00a=00l=00u=00e=00s=00 =
=00a=00n=00d=00 =00t=00o=00 =00m=00a=00k=00e=00 =00t=00h=00e=00s=00e=00 =
=00o=00p=00t=00i=00o=00n=00a=00l=00 =00=0D=00=0A=
=00w=00i=00l=00l=00 =00r=00e=00d=00u=00c=00e=00 =
=00n=00e=00t=00w=00o=00r=00k=00 =
=00l=00o=00a=00d=00.=00<=00B=00R=00>=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00R=00e=00g=00a=00r=00d=00s=00,=00<=00/=00D=00I=00V=00=
>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00<=00S=00P=00A=00N=00 =00=0D=00=0A=
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =007=00.=005=00p=00t=00;=00 =00C=00O=00L=00O=00R=00:=00 =
=00n=00a=00v=00y=00;=00 =
=00F=00O=00N=00T=00-=00F=00A=00M=00I=00L=00Y=00:=00 =
=00V=00e=00r=00d=00a=00n=00a=00;=00 =
=00m=00s=00o=00-=00n=00o=00-=00p=00r=00o=00o=00f=00:=00 =
=00y=00e=00s=00"=00>=00F=00a=00i=00s=00a=00l=00&=00n=00b=00s=00p=00;=00M=00=
a=00q=00s=00o=00o=00d=00<=00/=00S=00P=00A=00N=00>=00<=00/=00D=00I=00V=00>=
=00=0D=00=0A=
=00<=00D=00I=00V=00>=00<=00S=00P=00A=00N=00 =00=0D=00=0A=
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =007=00.=005=00p=00t=00;=00 =00C=00O=00L=00O=00R=00:=00 =
=00n=00a=00v=00y=00;=00 =
=00F=00O=00N=00T=00-=00F=00A=00M=00I=00L=00Y=00:=00 =
=00V=00e=00r=00d=00a=00n=00a=00;=00 =
=00m=00s=00o=00-=00n=00o=00-=00p=00r=00o=00o=00f=00:=00 =
=00y=00e=00s=00"=00>=00<=00/=00S=00P=00A=00N=00>=00&=00n=00b=00s=00p=00;=00=
<=00/=00D=00I=00V=00>=00<=00/=00D=00I=00V=00>=00<=00/=00D=00I=00V=00>=00<=
=00/=00B=00O=00D=00Y=00>=00<=00/=00H=00T=00M=00L=00>=00=0D=00=0A=
=00
------=_NextPart_000_00D2_01C4701D.5C30C8C0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MCp8Uu010332; Thu, 22 Jul 2004 05:51:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MCp8OE010331; Thu, 22 Jul 2004 05:51:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MCp74q010322 for <[e-mail]>; Thu, 22 Jul 2004 05:51:08 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 22 Jul 2004 08:50:56 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Fisher, James L." <[e-mail]>
CC: [e-mail]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jul 2004 12:51:03.0252 (UTC) FILETIME=[8BD94940:01C46FEA]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James,

A "Relative Distinguished Name" (RDN) references one element
or object in a tree, like a single "folder" in a Windows
file pathname.  But unlike a folder name, an RDN may contain
more than one attribute as long as they all have different
types. [ cn="John Smith" sn=12345 ] is a single RDN with two
names, whereas [ cn="John Smith", sn=12345 ] (note the comma)
is two RDNs each with a single name.

A Distinguished Name (DN) is a full path through the tree.
There may be multiple DC= or OU= attributes at different
levels in the tree, but only one at a given level.

Dave


Fisher, James L. wrote:
>>Russ's "problem" DN does not need to be solved.  As David notes, an
> 
> attribute type is not allowed to appear more than once in an RDN.
> 
> But we frequently see DNs containing multiple "dc=" and "ou="
> attributes.  Are those certs in violation of RFC3280 since Section
> 4.1.2.6 references to X.501 names?
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MBIgVY001455; Thu, 22 Jul 2004 04:18:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MBIgd5001454; Thu, 22 Jul 2004 04:18:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail45.messagelabs.com (mail45.messagelabs.com [140.174.2.179]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6MBIfED001432 for <[e-mail]>; Thu, 22 Jul 2004 04:18:41 -0700 (PDT) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-5.tower-45.messagelabs.com!1090495109!4337911
X-StarScan-Version: 5.2.10; banners=-,-,-
X-Originating-IP: [141.156.156.57]
Received: (qmail 8887 invoked from network); 22 Jul 2004 11:18:29 -0000
Received: from mtk-news1.mitretek.org (141.156.156.57) by server-5.tower-45.messagelabs.com with SMTP; 22 Jul 2004 11:18:29 -0000
Received: from email1.mitretek.org (localhost [127.0.0.1]) by mtk-news1.mitretek.org (8.12.10/8.12.10) with ESMTP id i6MBISQm020153 for <[e-mail]>; Thu, 22 Jul 2004 07:18:29 -0400 (EDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 22 Jul 2004 07:18:22 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Thread-Index: AcRvXffs1xwifDvaQHivIbbSzMcgggAI4a2gABaZgJA=
From: "Fisher, James L." <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6MBIfED001449
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Russ's "problem" DN does not need to be solved.  As David notes, an
attribute type is not allowed to appear more than once in an RDN.

But we frequently see DNs containing multiple "dc=" and "ou="
attributes.  Are those certs in violation of RFC3280 since Section
4.1.2.6 references to X.501 names?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M1nemp054359; Wed, 21 Jul 2004 18:49:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6M1neck054358; Wed, 21 Jul 2004 18:49:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailao.vtcif.telstra.com.au (mailao.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M1ncJJ054349 for <[e-mail]>; Wed, 21 Jul 2004 18:49:39 -0700 (PDT) (envelope-from [e-mail])
Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailao.vtcif.telstra.com.au (Postfix) with ESMTP id C554D23C11 for <[e-mail]>; Thu, 22 Jul 2004 11:49:35 +1000 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 4626A1DA83 for <[e-mail]>; Thu, 22 Jul 2004 11:49:35 +1000 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA01508 for <[e-mail]>; Thu, 22 Jul 2004 11:49:35 +1000 (EST)
content-class: urn:content-classes:message
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Thu, 22 Jul 2004 10:40:00 +1000
Message-ID: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Thread-Index: AcRvXffs1xwifDvaQHivIbbSzMcgggAI4a2g
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6M1ndJJ054353
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks David.

> cn="John Doe" , o="Acme Ltd" serialNumber="DUNS554433", c=US

Denis's "problem" DN does not need to be solved.  The DN does NOT contain a PI for the subject so the CA will not include a PI extension saying it does.  End of story.


Russ's "problem" DN does not need to be solved.  As David notes, an attribute type is not allowed to appear more than once in an RDN.


I still suggest using my original text changes.



-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Thursday, 22 July 2004 5:58 AM
To: Denis Pinkas
Cc: Russ Housley; Manger, James H; [e-mail]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber
attribute


Denis,

Your two conditions below are logical but unnecessarily
restrictive.

Consider James' original (correct) example:

[1] cn="John Doe" serialNumber=12345, o="Acme Ltd"
    serialNumber="DUNS 554433", c=US

and a modification (poorly-structured, but legal) that uses
only single-valued RDNs:

[2] cn="John Doe", serialNumber=12345, o="Acme Ltd",
   serialNumber="DUNS 554433", c=US

and your example:

[3] cn="John Doe", o="Acme Ltd", serialNumber="DUNS 554433", c=US


I do not believe it is necessary to prohibit [2] in order to
prevent [3].  Instead, if the SAN identifierValue is absent:

1 - if there are one or more RDNs containing a serialNumber
     attribute (alone or accompanied by other attributes), then
     the value contained in the serialNumber of the deepest
     such RDN shall be used as the identifierValue.

2 - otherwise, the CA is in error.


X.501 (02/2001) section 9.3, which appears to be normative,
not informative, prohibits a given attribute type from
appearing more than once in the same RDN.  The origin of
Russ' comments regarding the possibility of multiple
serialNumber attributes in a single RDN is unclear.

Dave



Denis Pinkas wrote:

> 
> 1 - if there is one serialNumber attribute alone in a RDN (i.e. no
>     other attribute is present in that RDN), then *there shall
>     only be one such RDN and* the value contained in the
>     serialNumber attribute shall be used as the identifierValue;
> 
> 2 - if there is no serialNumber attribute alone in a RDN, then the
>     deepest RDN shall include a *single* serialNumber attribute
>     and the value contained in that serialNumber shall be used
>     as the identifierValue.
> 
> Denis





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LJwW0b021773; Wed, 21 Jul 2004 12:58:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LJwWCL021772; Wed, 21 Jul 2004 12:58:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LJwVpb021764 for <[e-mail]>; Wed, 21 Jul 2004 12:58:31 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 21 Jul 2004 15:57:54 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Russ Housley <[e-mail]>, "Manger, James H" <[e-mail]>, [e-mail]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jul 2004 19:57:55.0437 (UTC) FILETIME=[037CD1D0:01C46F5D]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Your two conditions below are logical but unnecessarily
restrictive.

Consider James' original (correct) example:

[1] cn="John Doe" serialNumber=12345, o="Acme Ltd"
    serialNumber="DUNS 554433", c=US

and a modification (poorly-structured, but legal) that uses
only single-valued RDNs:

[2] cn="John Doe", serialNumber=12345, o="Acme Ltd",
   serialNumber="DUNS 554433", c=US

and your example:

[3] cn="John Doe", o="Acme Ltd", serialNumber="DUNS 554433", c=US


I do not believe it is necessary to prohibit [2] in order to
prevent [3].  Instead, if the SAN identifierValue is absent:

1 - if there are one or more RDNs containing a serialNumber
     attribute (alone or accompanied by other attributes), then
     the value contained in the serialNumber of the deepest
     such RDN shall be used as the identifierValue.

2 - otherwise, the CA is in error.


X.501 (02/2001) section 9.3, which appears to be normative,
not informative, prohibits a given attribute type from
appearing more than once in the same RDN.  The origin of
Russ' comments regarding the possibility of multiple
serialNumber attributes in a single RDN is unclear.

Dave



Denis Pinkas wrote:

> 
> 1 - if there is one serialNumber attribute alone in a RDN (i.e. no
>     other attribute is present in that RDN), then *there shall
>     only be one such RDN and* the value contained in the
>     serialNumber attribute shall be used as the identifierValue;
> 
> 2 - if there is no serialNumber attribute alone in a RDN, then the
>     deepest RDN shall include a *single* serialNumber attribute
>     and the value contained in that serialNumber shall be used
>     as the identifierValue.
> 
> Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LGflwC003618; Wed, 21 Jul 2004 09:41:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LGfl79003617; Wed, 21 Jul 2004 09:41:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LGfk9Q003607 for <[e-mail]>; Wed, 21 Jul 2004 09:41:46 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA08038; Wed, 21 Jul 2004 18:52:02 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id SAA09711; Wed, 21 Jul 2004 18:41:36 +0200
Message-ID: <[e-mail]>
Date: Wed, 21 Jul 2004 18:40:40 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Alberti Antoine <[e-mail]>
CC: Russ Housley <[e-mail]>, "Manger, James H" <[e-mail]>, [e-mail]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6LGfl9Q003612
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I wonder if it is realistic to set constraints on DNs in the PKI standards: 
 > one may not be able to use a DN that existed before the certificate
 > creation or renewal if the DN does not match the new rules. In this case,
 > what does the DN mean if it has to change from time to time, that is to
 > say if it does not identify the owner of the cert (I know it is already
 > the case, but it is not necessarily a reason to make this even more
 > true) ?

Using a serialNumber attribute is not mandatory to be able to use the PI 
feature. Some forms of DN will be able to support a serialNumber as the 
value of the identifierValue, while some others will not. In such a case, an 
explicit identifierValue can be used.

The proposed text only excludes the case where a RDN sequence would contain 
two or more serialNumber attributes in isolation. This is none of the 
examples given.

The constraint seems thus reasonable.

Denis


> Regards.
> Antoine Alberti.
> 
> 
>>-----Message d'origine-----
>>De : [e-mail]
>>[mailto:[e-mail]]De la part de Denis Pinkas
>>Envoyé : mercredi 21 juillet 2004 18:01
>>À : Russ Housley
>>Cc : Manger, James H; [e-mail]
>>Objet : Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber
>>attribute
>>
>>
>>
>>Russ,
>>
>>I would think that you wrote this e-mail before getting mine 
>>on the same 
>>topic. When reading your e-mail, I would believe that the two 
>>cases would 
>>need to be changed from:
>>
>>1 - if there is one serialNumber attribute alone in a RDN (i.e. no
>>     other attribute is present in that RDN), then the value contained
>>     in that serialNumber shall be used as the identifierValue;
>>
>>2 - if there is no serialNumber attribute alone in a RDN, then the
>>     deepest RDN shall include a serialNumber attribute and the
>>     value contained in that serialNumber shall be used as the
>>     identifierValue.
>>
>>to:
>>
>>1 - if there is one serialNumber attribute alone in a RDN (i.e. no
>>     other attribute is present in that RDN), then *there shall
>>     only be one such RDN and* the value contained in the
>>     serialNumber attribute shall be used as the identifierValue;
>>
>>2 - if there is no serialNumber attribute alone in a RDN, then the
>>     deepest RDN shall include a *single* serialNumber attribute
>>     and the value contained in that serialNumber shall be used
>>     as the identifierValue.
>>
>>Denis
>>
>>
>>
>>>James:
>>>
>>>The authors put the serial number restriction into the document in 
>>>response to a comment from me.  In the example that you 
>>
>>provide, there 
>>
>>>is not a problem.  However, one can construct a 
>>
>>distinguished name that 
>>
>>>is ambiguous.  The X.500 series of documents give us a very complex 
>>>structure for Name:
>>>
>>>   Name ::= CHOICE {
>>>     RDNSequence }
>>>
>>>   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
>>>
>>>   RelativeDistinguishedName ::=
>>>     SET OF AttributeTypeAndValue
>>>
>>>   AttributeTypeAndValue ::= SEQUENCE {
>>>     type     AttributeType,
>>>     value    AttributeValue }
>>>
>>>   AttributeType ::= OBJECT IDENTIFIER
>>>
>>>   AttributeValue ::= ANY DEFINED BY AttributeType
>>>
>>>Since RelativeDistinguishedName is a SET, it is possible to 
>>
>>have more 
>>
>>>than one attribute at the same level.  If this level were 
>>
>>to include 
>>
>>>more than one SerialNumber attribute, then it would not be 
>>
>>clear which 
>>
>>>one to use as the permanent identifier.  Since it is a SET, 
>>
>>one cannot 
>>
>>>rely on order to help resolve this issue.  They would be 
>>
>>equally "deep" 
>>
>>>in the RDNSequence.
>>>
>>>I admit that no one in their right mind would design a 
>>
>>schema like this, 
>>
>>>but sadly, the structure permits an uninformed person to make some 
>>>really bad choices.  Further, guidance in this area was 
>>
>>removed from the 
>>
>>>X.500 series of documents.  The informative information 
>>
>>that was once 
>>
>>>present was removed because some implementors treated it as 
>>
>>normative.
>>
>>>Russ
>>>
>>>
>>>At 01:07 AM 7/19/2004, Manger, James H wrote:
>>>
>>>
>>>>1.
>>>>The ability to flag a serialNumber attribute value in the 
>>>
>>subject name 
>>
>>>>as a permanent identifier is a nice feature.  Requiring that there 
>>>>only be a single serialNumber attribute, however, is unnecessarily 
>>>>restrictive.  It seems quite sensible to use serialNumber 
>>>
>>attributes 
>>
>>>>to hold company numbers, org unit ids and/or personal 
>>>
>>identifiers.  
>>
>>>>For example: cn="John Doe" serialNumber=12345, o="Acme Ltd" 
>>>>serialNumber="DUNS 554433", c=US.  The PI extension would 
>>>
>>refer to 12345.
>>
>>>>[Section 2] Change the ASN.1 comment for the 
>>>
>>identifierValue field of 
>>
>>>>PermanentIdentifier to:
>>>>" -- if absent, use the deepest serialNumber attribute 
>>>
>>value in the 
>>
>>>>subject DN"
>>>>
>>>>[Section 2] Change the paragraph that begins "When the 
>>>
>>identifierValue 
>>
>>>>field is absent" to:
>>>>"When the identifierValue field is absent, then the deepest 
>>>>serialNumber attribute value from the subject DN is the 
>>>
>>value to be 
>>
>>>>taken for the identifierValue.  An attribute is "deeper" 
>>>
>>if it occurs 
>>
>>>>later in the sequence of RDNs that make up the DN.  A "deeper" 
>>>>attribute occurs earlier in the string representation of a DN 
>>>>[RFC2253], which start encoding the last element of the 
>>>
>>RDN sequence 
>>
>>>>that makes up a DN and moves backwards towards the first.  The 
>>>>PermanentIdentifier SHALL NOT be used if there is no serialNumber 
>>>>attribute in the subject DN.
>>>>
>>>>
>>>>
>>>>2.
>>>>Why can't the assigner field be present but the 
>>>
>>identifierValue field 
>>
>>>>be absent (refer to the serialNumber attribute)?  An absent 
>>>>identifierValue is simply "shorthand" to avoid duplicating 
>>>
>>a value -- 
>>
>>>>it doesn't really have any sematic value so shouldn't have 
>>>
>>any impact 
>>
>>>>on the assigner field (or vice versa).
>>>>
>>>>
>>>>
>>>>3.
>>>>The security considerations section mentions an 
>>>
>>identifierType field 
>>
>>>>that no longer exists.
>>>>
>>>>
>>>>
>>>>>----------
>>>>>From:         [e-mail] 
>>>>
>>>>[mailto:[e-mail]]
>>>>
>>>>>Sent: Wednesday, 14 July 2004 6:05 AM
>>>>>
>>>>>      Title           : Internet X.509 Public Key Infrastructure 
>>>>
>>>>Permanent Identifier
>>>>
>>>>>      Author(s)       : D. Pinkas, T. Gindin
>>>>>      Filename        : draft-ietf-pkix-pi-10.txt
>>>>>      Date            : 2004-7-13
>>>>>
>>>>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-10.txt
>>>>>
>>>>>      ----------
>>>>>      From:   Denis Pinkas [mailto:[e-mail]]
>>>>>      Sent:   Thursday, 15 July 2004 6:06 PM
>>>>>      Cc:     [e-mail]
>>>>>
>>>>
>>>>                ... the definition of the PI has been 
>>>
>>changed to allow 
>>
>>>>to use the serialNumber attribute from the subject DN.
>>>
>>>
>>>
>>
>>
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LGKhoo099437; Wed, 21 Jul 2004 09:20:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LGKhbA099436; Wed, 21 Jul 2004 09:20:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LGKfCb099364 for <[e-mail]>; Wed, 21 Jul 2004 09:20:42 -0700 (PDT) (envelope-from [e-mail])
Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id i6LGK6Kp006886; Wed, 21 Jul 2004 18:20:07 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Date: Wed, 21 Jul 2004 18:20:06 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Thread-Index: AcRvPMxYAgDEz69MTIOwiUH7/WDo3gAANlPg
From: "Alberti Antoine" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: "Manger, James H" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 21 Jul 2004 16:27:16.0062 (UTC) FILETIME=[95D53FE0:01C46F3F]
X-Scanned-By: MIMEDefang 2.38
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6LGKhCb099431
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I wonder if it is realistic to set constraints on DNs in the PKI standards: one may not be able to use a DN that existed before the certificate creation or renewal if the DN does not match the new rules. In this case, what does the DN mean if it has to change from time to time, that is to say if it does not identify the owner of the cert (I know it is already the case, but it is not necessarily a reason to make this even more true) ?

Regards.
Antoine Alberti.

> -----Message d'origine-----
> De : [e-mail]
> [mailto:[e-mail]]De la part de Denis Pinkas
> Envoyé : mercredi 21 juillet 2004 18:01
> À : Russ Housley
> Cc : Manger, James H; [e-mail]
> Objet : Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber
> attribute
> 
> 
> 
> Russ,
> 
> I would think that you wrote this e-mail before getting mine 
> on the same 
> topic. When reading your e-mail, I would believe that the two 
> cases would 
> need to be changed from:
> 
> 1 - if there is one serialNumber attribute alone in a RDN (i.e. no
>      other attribute is present in that RDN), then the value contained
>      in that serialNumber shall be used as the identifierValue;
> 
> 2 - if there is no serialNumber attribute alone in a RDN, then the
>      deepest RDN shall include a serialNumber attribute and the
>      value contained in that serialNumber shall be used as the
>      identifierValue.
> 
> to:
> 
> 1 - if there is one serialNumber attribute alone in a RDN (i.e. no
>      other attribute is present in that RDN), then *there shall
>      only be one such RDN and* the value contained in the
>      serialNumber attribute shall be used as the identifierValue;
> 
> 2 - if there is no serialNumber attribute alone in a RDN, then the
>      deepest RDN shall include a *single* serialNumber attribute
>      and the value contained in that serialNumber shall be used
>      as the identifierValue.
> 
> Denis
> 
> 
> > James:
> > 
> > The authors put the serial number restriction into the document in 
> > response to a comment from me.  In the example that you 
> provide, there 
> > is not a problem.  However, one can construct a 
> distinguished name that 
> > is ambiguous.  The X.500 series of documents give us a very complex 
> > structure for Name:
> > 
> >    Name ::= CHOICE {
> >      RDNSequence }
> > 
> >    RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
> > 
> >    RelativeDistinguishedName ::=
> >      SET OF AttributeTypeAndValue
> > 
> >    AttributeTypeAndValue ::= SEQUENCE {
> >      type     AttributeType,
> >      value    AttributeValue }
> > 
> >    AttributeType ::= OBJECT IDENTIFIER
> > 
> >    AttributeValue ::= ANY DEFINED BY AttributeType
> > 
> > Since RelativeDistinguishedName is a SET, it is possible to 
> have more 
> > than one attribute at the same level.  If this level were 
> to include 
> > more than one SerialNumber attribute, then it would not be 
> clear which 
> > one to use as the permanent identifier.  Since it is a SET, 
> one cannot 
> > rely on order to help resolve this issue.  They would be 
> equally "deep" 
> > in the RDNSequence.
> > 
> > I admit that no one in their right mind would design a 
> schema like this, 
> > but sadly, the structure permits an uninformed person to make some 
> > really bad choices.  Further, guidance in this area was 
> removed from the 
> > X.500 series of documents.  The informative information 
> that was once 
> > present was removed because some implementors treated it as 
> normative.
> > 
> > Russ
> > 
> > 
> > At 01:07 AM 7/19/2004, Manger, James H wrote:
> > 
> >> 1.
> >> The ability to flag a serialNumber attribute value in the 
> subject name 
> >> as a permanent identifier is a nice feature.  Requiring that there 
> >> only be a single serialNumber attribute, however, is unnecessarily 
> >> restrictive.  It seems quite sensible to use serialNumber 
> attributes 
> >> to hold company numbers, org unit ids and/or personal 
> identifiers.  
> >> For example: cn="John Doe" serialNumber=12345, o="Acme Ltd" 
> >> serialNumber="DUNS 554433", c=US.  The PI extension would 
> refer to 12345.
> >>
> >> [Section 2] Change the ASN.1 comment for the 
> identifierValue field of 
> >> PermanentIdentifier to:
> >> " -- if absent, use the deepest serialNumber attribute 
> value in the 
> >> subject DN"
> >>
> >> [Section 2] Change the paragraph that begins "When the 
> identifierValue 
> >> field is absent" to:
> >> "When the identifierValue field is absent, then the deepest 
> >> serialNumber attribute value from the subject DN is the 
> value to be 
> >> taken for the identifierValue.  An attribute is "deeper" 
> if it occurs 
> >> later in the sequence of RDNs that make up the DN.  A "deeper" 
> >> attribute occurs earlier in the string representation of a DN 
> >> [RFC2253], which start encoding the last element of the 
> RDN sequence 
> >> that makes up a DN and moves backwards towards the first.  The 
> >> PermanentIdentifier SHALL NOT be used if there is no serialNumber 
> >> attribute in the subject DN.
> >>
> >>
> >>
> >> 2.
> >> Why can't the assigner field be present but the 
> identifierValue field 
> >> be absent (refer to the serialNumber attribute)?  An absent 
> >> identifierValue is simply "shorthand" to avoid duplicating 
> a value -- 
> >> it doesn't really have any sematic value so shouldn't have 
> any impact 
> >> on the assigner field (or vice versa).
> >>
> >>
> >>
> >> 3.
> >> The security considerations section mentions an 
> identifierType field 
> >> that no longer exists.
> >>
> >>
> >> > ----------
> >> > From:         [e-mail] 
> >> [mailto:[e-mail]]
> >> > Sent: Wednesday, 14 July 2004 6:05 AM
> >> >
> >> >       Title           : Internet X.509 Public Key Infrastructure 
> >> Permanent Identifier
> >> >       Author(s)       : D. Pinkas, T. Gindin
> >> >       Filename        : draft-ietf-pkix-pi-10.txt
> >> >       Date            : 2004-7-13
> >> >
> >> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-10.txt
> >> >
> >> >       ----------
> >> >       From:   Denis Pinkas [mailto:[e-mail]]
> >> >       Sent:   Thursday, 15 July 2004 6:06 PM
> >> >       Cc:     [e-mail]
> >> >
> >>                 ... the definition of the PI has been 
> changed to allow 
> >> to use the serialNumber attribute from the subject DN.
> > 
> > 
> > 
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LGDcpg098801; Wed, 21 Jul 2004 09:13:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LGDcKG098800; Wed, 21 Jul 2004 09:13:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6LGDbcG098793 for <[e-mail]>; Wed, 21 Jul 2004 09:13:38 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 6222 invoked by uid 0); 21 Jul 2004 16:06:41 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.154.86) by woodstock.binhost.com with SMTP; 21 Jul 2004 16:06:41 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Wed, 21 Jul 2004 12:14:07 -0400
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Cc: "Manger, James H" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

Yes, I did write this before I saw your response.

Russ

At 12:00 PM 7/21/2004, Denis Pinkas wrote:
>Russ,
>
>I would think that you wrote this e-mail before getting mine on the same 
>topic. When reading your e-mail, I would believe that the two cases would 
>need to be changed from:
>
>1 - if there is one serialNumber attribute alone in a RDN (i.e. no
>     other attribute is present in that RDN), then the value contained
>     in that serialNumber shall be used as the identifierValue;
>
>2 - if there is no serialNumber attribute alone in a RDN, then the
>     deepest RDN shall include a serialNumber attribute and the
>     value contained in that serialNumber shall be used as the
>     identifierValue.
>
>to:
>
>1 - if there is one serialNumber attribute alone in a RDN (i.e. no
>     other attribute is present in that RDN), then *there shall
>     only be one such RDN and* the value contained in the
>     serialNumber attribute shall be used as the identifierValue;
>
>2 - if there is no serialNumber attribute alone in a RDN, then the
>     deepest RDN shall include a *single* serialNumber attribute
>     and the value contained in that serialNumber shall be used
>     as the identifierValue.
>
>Denis
>
>
>>James:
>>The authors put the serial number restriction into the document in 
>>response to a comment from me.  In the example that you provide, there is 
>>not a problem.  However, one can construct a distinguished name that is 
>>ambiguous.  The X.500 series of documents give us a very complex 
>>structure for Name:
>>    Name ::= CHOICE {
>>      RDNSequence }
>>    RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
>>    RelativeDistinguishedName ::=
>>      SET OF AttributeTypeAndValue
>>    AttributeTypeAndValue ::= SEQUENCE {
>>      type     AttributeType,
>>      value    AttributeValue }
>>    AttributeType ::= OBJECT IDENTIFIER
>>    AttributeValue ::= ANY DEFINED BY AttributeType
>>Since RelativeDistinguishedName is a SET, it is possible to have more 
>>than one attribute at the same level.  If this level were to include more 
>>than one SerialNumber attribute, then it would not be clear which one to 
>>use as the permanent identifier.  Since it is a SET, one cannot rely on 
>>order to help resolve this issue.  They would be equally "deep" in the 
>>RDNSequence.
>>I admit that no one in their right mind would design a schema like this, 
>>but sadly, the structure permits an uninformed person to make some really 
>>bad choices.  Further, guidance in this area was removed from the X.500 
>>series of documents.  The informative information that was once present 
>>was removed because some implementors treated it as normative.
>>Russ
>>
>>At 01:07 AM 7/19/2004, Manger, James H wrote:
>>
>>>1.
>>>The ability to flag a serialNumber attribute value in the subject name 
>>>as a permanent identifier is a nice feature.  Requiring that there only 
>>>be a single serialNumber attribute, however, is unnecessarily 
>>>restrictive.  It seems quite sensible to use serialNumber attributes to 
>>>hold company numbers, org unit ids and/or personal identifiers.
>>>For example: cn="John Doe" serialNumber=12345, o="Acme Ltd" 
>>>serialNumber="DUNS 554433", c=US.  The PI extension would refer to 12345.
>>>
>>>[Section 2] Change the ASN.1 comment for the identifierValue field of 
>>>PermanentIdentifier to:
>>>" -- if absent, use the deepest serialNumber attribute value in the 
>>>subject DN"
>>>
>>>[Section 2] Change the paragraph that begins "When the identifierValue 
>>>field is absent" to:
>>>"When the identifierValue field is absent, then the deepest serialNumber 
>>>attribute value from the subject DN is the value to be taken for the 
>>>identifierValue.  An attribute is "deeper" if it occurs later in the 
>>>sequence of RDNs that make up the DN.  A "deeper" attribute occurs 
>>>earlier in the string representation of a DN [RFC2253], which start 
>>>encoding the last element of the RDN sequence that makes up a DN and 
>>>moves backwards towards the first.  The PermanentIdentifier SHALL NOT be 
>>>used if there is no serialNumber attribute in the subject DN.
>>>
>>>
>>>
>>>2.
>>>Why can't the assigner field be present but the identifierValue field be 
>>>absent (refer to the serialNumber attribute)?  An absent identifierValue 
>>>is simply "shorthand" to avoid duplicating a value -- it doesn't really 
>>>have any sematic value so shouldn't have any impact on the assigner 
>>>field (or vice versa).
>>>
>>>
>>>
>>>3.
>>>The security considerations section mentions an identifierType field 
>>>that no longer exists.
>>>
>>>
>>> > ----------
>>> > From:         [e-mail] [mailto:[e-mail]]
>>> > Sent: Wednesday, 14 July 2004 6:05 AM
>>> >
>>> >       Title           : Internet X.509 Public Key Infrastructure 
>>> Permanent Identifier
>>> >       Author(s)       : D. Pinkas, T. Gindin
>>> >       Filename        : draft-ietf-pkix-pi-10.txt
>>> >       Date            : 2004-7-13
>>> >
>>> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-10.txt
>>> >
>>> >       ----------
>>> >       From:   Denis Pinkas [mailto:[e-mail]]
>>> >       Sent:   Thursday, 15 July 2004 6:06 PM
>>> >       Cc:     [e-mail]
>>> >
>>>                 ... the definition of the PI has been changed to allow 
>>> to use the serialNumber attribute from the subject DN.
>>
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LG1huY097791; Wed, 21 Jul 2004 09:01:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LG1hqK097790; Wed, 21 Jul 2004 09:01:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LG1gor097779 for <[e-mail]>; Wed, 21 Jul 2004 09:01:42 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA32066; Wed, 21 Jul 2004 18:11:57 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id SAA02689; Wed, 21 Jul 2004 18:01:31 +0200
Message-ID: <[e-mail]>
Date: Wed, 21 Jul 2004 18:00:35 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: "Manger, James H" <[e-mail]>, [e-mail]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I would think that you wrote this e-mail before getting mine on the same 
topic. When reading your e-mail, I would believe that the two cases would 
need to be changed from:

1 - if there is one serialNumber attribute alone in a RDN (i.e. no
     other attribute is present in that RDN), then the value contained
     in that serialNumber shall be used as the identifierValue;

2 - if there is no serialNumber attribute alone in a RDN, then the
     deepest RDN shall include a serialNumber attribute and the
     value contained in that serialNumber shall be used as the
     identifierValue.

to:

1 - if there is one serialNumber attribute alone in a RDN (i.e. no
     other attribute is present in that RDN), then *there shall
     only be one such RDN and* the value contained in the
     serialNumber attribute shall be used as the identifierValue;

2 - if there is no serialNumber attribute alone in a RDN, then the
     deepest RDN shall include a *single* serialNumber attribute
     and the value contained in that serialNumber shall be used
     as the identifierValue.

Denis


> James:
> 
> The authors put the serial number restriction into the document in 
> response to a comment from me.  In the example that you provide, there 
> is not a problem.  However, one can construct a distinguished name that 
> is ambiguous.  The X.500 series of documents give us a very complex 
> structure for Name:
> 
>    Name ::= CHOICE {
>      RDNSequence }
> 
>    RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
> 
>    RelativeDistinguishedName ::=
>      SET OF AttributeTypeAndValue
> 
>    AttributeTypeAndValue ::= SEQUENCE {
>      type     AttributeType,
>      value    AttributeValue }
> 
>    AttributeType ::= OBJECT IDENTIFIER
> 
>    AttributeValue ::= ANY DEFINED BY AttributeType
> 
> Since RelativeDistinguishedName is a SET, it is possible to have more 
> than one attribute at the same level.  If this level were to include 
> more than one SerialNumber attribute, then it would not be clear which 
> one to use as the permanent identifier.  Since it is a SET, one cannot 
> rely on order to help resolve this issue.  They would be equally "deep" 
> in the RDNSequence.
> 
> I admit that no one in their right mind would design a schema like this, 
> but sadly, the structure permits an uninformed person to make some 
> really bad choices.  Further, guidance in this area was removed from the 
> X.500 series of documents.  The informative information that was once 
> present was removed because some implementors treated it as normative.
> 
> Russ
> 
> 
> At 01:07 AM 7/19/2004, Manger, James H wrote:
> 
>> 1.
>> The ability to flag a serialNumber attribute value in the subject name 
>> as a permanent identifier is a nice feature.  Requiring that there 
>> only be a single serialNumber attribute, however, is unnecessarily 
>> restrictive.  It seems quite sensible to use serialNumber attributes 
>> to hold company numbers, org unit ids and/or personal identifiers.  
>> For example: cn="John Doe" serialNumber=12345, o="Acme Ltd" 
>> serialNumber="DUNS 554433", c=US.  The PI extension would refer to 12345.
>>
>> [Section 2] Change the ASN.1 comment for the identifierValue field of 
>> PermanentIdentifier to:
>> " -- if absent, use the deepest serialNumber attribute value in the 
>> subject DN"
>>
>> [Section 2] Change the paragraph that begins "When the identifierValue 
>> field is absent" to:
>> "When the identifierValue field is absent, then the deepest 
>> serialNumber attribute value from the subject DN is the value to be 
>> taken for the identifierValue.  An attribute is "deeper" if it occurs 
>> later in the sequence of RDNs that make up the DN.  A "deeper" 
>> attribute occurs earlier in the string representation of a DN 
>> [RFC2253], which start encoding the last element of the RDN sequence 
>> that makes up a DN and moves backwards towards the first.  The 
>> PermanentIdentifier SHALL NOT be used if there is no serialNumber 
>> attribute in the subject DN.
>>
>>
>>
>> 2.
>> Why can't the assigner field be present but the identifierValue field 
>> be absent (refer to the serialNumber attribute)?  An absent 
>> identifierValue is simply "shorthand" to avoid duplicating a value -- 
>> it doesn't really have any sematic value so shouldn't have any impact 
>> on the assigner field (or vice versa).
>>
>>
>>
>> 3.
>> The security considerations section mentions an identifierType field 
>> that no longer exists.
>>
>>
>> > ----------
>> > From:         [e-mail] 
>> [mailto:[e-mail]]
>> > Sent: Wednesday, 14 July 2004 6:05 AM
>> >
>> >       Title           : Internet X.509 Public Key Infrastructure 
>> Permanent Identifier
>> >       Author(s)       : D. Pinkas, T. Gindin
>> >       Filename        : draft-ietf-pkix-pi-10.txt
>> >       Date            : 2004-7-13
>> >
>> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-10.txt
>> >
>> >       ----------
>> >       From:   Denis Pinkas [mailto:[e-mail]]
>> >       Sent:   Thursday, 15 July 2004 6:06 PM
>> >       Cc:     [e-mail]
>> >
>>                 ... the definition of the PI has been changed to allow 
>> to use the serialNumber attribute from the subject DN.
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LFQQLK094339; Wed, 21 Jul 2004 08:26:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LFQQjT094338; Wed, 21 Jul 2004 08:26:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av3-2-sn4.m-sp.skanova.net (av3-2-sn4.m-sp.skanova.net [81.228.10.113]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LFQP9k094317 for <[e-mail]>; Wed, 21 Jul 2004 08:26:26 -0700 (PDT) (envelope-from [e-mail])
Received: by av3-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 9ECA037ED6; Wed, 21 Jul 2004 17:26:14 +0200 (CEST)
Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av3-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 8DA7037E46; Wed, 21 Jul 2004 17:26:14 +0200 (CEST)
Received: from arport (t11o913p10.telia.com [213.64.28.10]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with SMTP id 8714337E49; Wed, 21 Jul 2004 17:26:11 +0200 (CEST)
Message-ID: <00a001c46f36$a5abe6c0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: "Manger, James H" <[e-mail]>, "Denis Pinkas" <[e-mail]>
References: <[e-mail]>
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
Date: Wed, 21 Jul 2004 17:23:14 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,
James is probably right regarding multiple serialNumbers.

But why didn't you rather showed him that you actually can handle multiple
PI's by using the subjectAltName-only variant for the company ID?

However, that James put a DUNS 554433 "sort-of-PI" in the subject
DN, again illustrates the obvious:  It is non-intuitive to put names
in other places than in DNs.  This includes assigners as well.

That X.520 does not support assigners is hardly an argument as
the X.500 people apparently didn't understood the importance of
permanent identifier concepts, so we are now actually "patching"
X.500.   Patches usually "look" ugly but they may "work" completely
OK anyway.

We may ignore this fact, but it will most likely just show up again in
homebrewed constructs like the one James (accidentally?) created.

To further complicate things: That the "subject" is John Doe
is only valid from a strict X.500 point of view.  If this certificate
is actually associated with a signed purchase order that a relying
party (supplier) has just received, they hardly regard John Doe
(who they may never ever have heard of) as the "important" thing
but rather "Acme Ltd" and "DUNS 554433".  Well, I actually
lied here because they will not bother with the certificate DN
at all as this name scheme is entirely different to the name
schemes used in business messages.  Only X.500 experts can
on case-per-case basis, manually and only occasionally do this 
name matching.  That PIs insist on using OIDs for authorities,
thereby avoiding intelligible expressions like "DUNS" or
http://www.dnb.com/duns, will postpone this for security
reasons highly wanted name matching for yet another decade.
e-Business folks generally have no idea what an OID is, and
before PIs they had no reason to know it either.

============================================
 A properly designed PI OTOH, could be the bridge between
 identities in certificates and business messages that X.500
 as it stands today never achieved, and never will either!
============================================

But if the only goal is to get PI out now, I guess we might as well
support things like James' "sort-of-PI" scheme by keeping focus on
the "deepest" serialNumber.

That was deep :-)

Anders

----- Original Message ----- 
From: "Manger, James H" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>; <[e-mail]>
Sent: Wednesday, July 21, 2004 03:15
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute



That is wrong.

A DN names an object by describing a path to it through a hierarchy of
other objects.  Each RDN consists of attributes of one of those *other*
objects.  Only the last RDN has attributes of the actual named object.
A serialNumber attribute (like any other attribute) can appear multiple
times -- once for each level of the hierarchy (ie once for each RDN).

RDN = *Relative* Distinguished Name.

[Note. No attribute type can appear multiple times within a single RDN.]

In my sample DN:
cn="John Doe" serialNumber=12345, o="Acme Ltd" serialNumber="DUNS
554433", c=US
there are 3 objects: a country, a company and a person.  The person only
has one serialNumber.  The company is an object in its own right so it
can have its own serialNumber.

So please reconsider my suggestion (1) that when identifierValue is
absent the deepest serialNumber value is used.

[Theoretically, the PI draft could require the serialNumber be in the
deepest RDN.  This would ensure the serialNumber is an attribute of the
named object, not of some parent object.  However, I would not recommend
that.  It is not unusual for DNs (particularly in certificates) to only
use 1 attribute per RDN, even if some of the attributes all relate to
the same logical object.]


----------
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, 21 July 2004 12:01 AM

Section 5.2.9 from X520 defines the serial Number attribute as follows:

"The serial Number attribute type specifies an identifier, the serial
number 
of an objet."

The serial Number attribute applies to the object, not to a RDN
component.
Thus, unless it is an error, there can't be multiple serial Number 
attributes in a DN.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LF2gh2090932; Wed, 21 Jul 2004 08:02:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LF2gfN090931; Wed, 21 Jul 2004 08:02:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6LF2fwZ090925 for <[e-mail]>; Wed, 21 Jul 2004 08:02:42 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 20365 invoked by uid 0); 21 Jul 2004 14:55:27 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.137.25) by woodstock.binhost.com with SMTP; 21 Jul 2004 14:55:27 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Wed, 21 Jul 2004 11:02:43 -0400
To: "Manger, James H" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
In-Reply-To: <[e-mail] l.telstra.com.au>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James:

The authors put the serial number restriction into the document in response 
to a comment from me.  In the example that you provide, there is not a 
problem.  However, one can construct a distinguished name that is 
ambiguous.  The X.500 series of documents give us a very complex structure 
for Name:

    Name ::= CHOICE {
      RDNSequence }

    RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

    RelativeDistinguishedName ::=
      SET OF AttributeTypeAndValue

    AttributeTypeAndValue ::= SEQUENCE {
      type     AttributeType,
      value    AttributeValue }

    AttributeType ::= OBJECT IDENTIFIER

    AttributeValue ::= ANY DEFINED BY AttributeType

Since RelativeDistinguishedName is a SET, it is possible to have more than 
one attribute at the same level.  If this level were to include more than 
one SerialNumber attribute, then it would not be clear which one to use as 
the permanent identifier.  Since it is a SET, one cannot rely on order to 
help resolve this issue.  They would be equally "deep" in the RDNSequence.

I admit that no one in their right mind would design a schema like this, 
but sadly, the structure permits an uninformed person to make some really 
bad choices.  Further, guidance in this area was removed from the X.500 
series of documents.  The informative information that was once present was 
removed because some implementors treated it as normative.

Russ


At 01:07 AM 7/19/2004, Manger, James H wrote:

>1.
>The ability to flag a serialNumber attribute value in the subject name as 
>a permanent identifier is a nice feature.  Requiring that there only be a 
>single serialNumber attribute, however, is unnecessarily restrictive.  It 
>seems quite sensible to use serialNumber attributes to hold company 
>numbers, org unit ids and/or personal identifiers.  For example: cn="John 
>Doe" serialNumber=12345, o="Acme Ltd" serialNumber="DUNS 554433", 
>c=US.  The PI extension would refer to 12345.
>
>[Section 2] Change the ASN.1 comment for the identifierValue field of 
>PermanentIdentifier to:
>" -- if absent, use the deepest serialNumber attribute value in the 
>subject DN"
>
>[Section 2] Change the paragraph that begins "When the identifierValue 
>field is absent" to:
>"When the identifierValue field is absent, then the deepest serialNumber 
>attribute value from the subject DN is the value to be taken for the 
>identifierValue.  An attribute is "deeper" if it occurs later in the 
>sequence of RDNs that make up the DN.  A "deeper" attribute occurs earlier 
>in the string representation of a DN [RFC2253], which start encoding the 
>last element of the RDN sequence that makes up a DN and moves backwards 
>towards the first.  The PermanentIdentifier SHALL NOT be used if there is 
>no serialNumber attribute in the subject DN.
>
>
>
>2.
>Why can't the assigner field be present but the identifierValue field be 
>absent (refer to the serialNumber attribute)?  An absent identifierValue 
>is simply "shorthand" to avoid duplicating a value -- it doesn't really 
>have any sematic value so shouldn't have any impact on the assigner field 
>(or vice versa).
>
>
>
>3.
>The security considerations section mentions an identifierType field that 
>no longer exists.
>
>
> > ----------
> > From:         [e-mail] [mailto:[e-mail]]
> > Sent: Wednesday, 14 July 2004 6:05 AM
> >
> >       Title           : Internet X.509 Public Key Infrastructure 
> Permanent Identifier
> >       Author(s)       : D. Pinkas, T. Gindin
> >       Filename        : draft-ietf-pkix-pi-10.txt
> >       Date            : 2004-7-13
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-10.txt
> >
> >       ----------
> >       From:   Denis Pinkas [mailto:[e-mail]]
> >       Sent:   Thursday, 15 July 2004 6:06 PM
> >       Cc:     [e-mail]
> >
>                 ... the definition of the PI has been changed to allow to 
> use the serialNumber attribute from the subject DN.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LEAGnO086116; Wed, 21 Jul 2004 07:10:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LEAGPk086115; Wed, 21 Jul 2004 07:10:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LEAE7L086108 for <[e-mail]>; Wed, 21 Jul 2004 07:10:15 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA13970; Wed, 21 Jul 2004 16:20:26 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA17530; Wed, 21 Jul 2004 15:55:23 +0200
Message-ID: <[e-mail]>
Date: Wed, 21 Jul 2004 15:54:27 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: [e-mail]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James,

> That is wrong.
> 
> A DN names an object by describing a path to it through a hierarchy of
> other objects.  Each RDN consists of attributes of one of those *other*
> objects.  Only the last RDN has attributes of the actual named object.
> A serialNumber attribute (like any other attribute) can appear multiple
> times -- once for each level of the hierarchy (ie once for each RDN).
> 
> RDN = *Relative* Distinguished Name.
> 
> [Note. No attribute type can appear multiple times within a single RDN.]
> 
> In my sample DN:
> cn="John Doe" serialNumber=12345, o="Acme Ltd" serialNumber="DUNS
> 554433", c=US
> there are 3 objects: a country, a company and a person.  The person only
> has one serialNumber.  The company is an object in its own right so it
> can have its own serialNumber.

OK.

> So please reconsider my suggestion (1) that when identifierValue is
> absent the deepest serialNumber value is used.

I understand what you mean, but the proposed formulation is wrong.

Suppose a certificate with:
cn="John Doe" , o="Acme Ltd" serialNumber="DUNS554433", c=US

then there would be thousands of certificates with the same PI and refering 
to differents persons. :-(

> [Theoretically, the PI draft could require the serialNumber be in the
> deepest RDN.  This would ensure the serialNumber is an attribute of the
> named object, not of some parent object. However, I would not recommend that.
> It is not unusual for DNs (particularly in certificates) to only
> use 1 attribute per RDN, even if some of the attributes all relate to
> the same logical object.]

This remark is correct, but we need a way to prevent the case mentionned above.

There would be two cases to consider:

1 - if there is one serialNumber attribute alone in a RDN (i.e. no
     other attribute is present in that RDN), then the value contained
     in that serialNumber shall be used as the identifierValue;

2 - if there is no serialNumber attribute alone in a RDN, then the
     deepest RDN shall include a serialNumber attribute and the
     value contained in that serialNumber shall be used as the
     identifierValue.

Is this formulation correct ?

Denis

> ----------
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, 21 July 2004 12:01 AM
> 
> Section 5.2.9 from X520 defines the serial Number attribute as follows:
> 
> "The serial Number attribute type specifies an identifier, the serial
> number 
> of an objet."
> 
> The serial Number attribute applies to the object, not to a RDN
> component.
> Thus, unless it is an error, there can't be multiple serial Number 
> attributes in a DN.
> 




Received: from 208.184.76.43 ([203.236.127.125]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6L9WbIs040276; Wed, 21 Jul 2004 02:32:39 -0700 (PDT) (envelope-from [e-mail])
Received: from t7idc.0sxgcz5.com ([102.87.85.61]) by 208.184.76.43 with SMTP; Wed, 21 Jul 2004 14:26:00 +0400
Message-ID: <826l0rf$mbia-1460@5krl223ko>
From: "Admin" <[e-mail]>
To: [e-mail]
Subject: Staff Bulletin
Date: Wed, 21 Jul 04 14:26:00 GMT
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="DD.__A53A.26A09.B.AE.8_6"

This is a multi-part message in MIME format.

--DD.__A53A.26A09.B.AE.8_6
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Nonprofit Organizations: Members, Staff and Associates:

You Must Respond By 5 P.M. Thursday, July 22, 2004.

Through a special arrangement, Avtech Direct is offering a limited
allotment of BRAND NEW, top of-the-line, name-brand desktop computers
at more than 50% off MSRP to all Nonprofit Members and Staff 
who respond to this message before 5 P.M., Thursday, July 22, 2004.

All desktop are brand-new, packed in their original boxes, and come
with a full manufacturer's warranty plus a 100% satisfaction guarantee.

These professional grade Desktops are fully equipped with 2004
next generation technology, making these the best performing
computers money can buy.

Avtech Direct is offering these feature rich, top performing
Desktop Computers with the latest Intel technology at an amazing price
to all who call:

    1-800-884-9510 by 5 P.M. Thursday, July 22, 2004

The fast and powerful AT-2400 series Desktop features: 

      * Intel 2.0Ghz Processor for amazing speed and performance
      * 128MB DDR RAM,  --- Upgradeable to 1024
      * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB
      * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW 
      * 1.44 Floppy disk drive
      * Next Generation Technology
      * ATI Premium video and sound
      * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0
      * Soft Touch Keyboard and scroll mouse
      * Internet Ready
      * Network Ready
      * 1 Year parts and labor warranty
      * Priority customer service and tech support

MSRP $699 ........................................ Your Cost $297

How to qualify:

  1. You must be a Member, Staff or Associate of a Nonprofit:
  2. All desktop computers will be available on a
     first come first serve basis.
  3. You must call 1-800-884-9510 by 5 P.M. Thursday, July 22, 2004
     and we will hold the desktops you request on will call. 
  4. You are not obligated in any way.
  5. 100% Satisfaction Guaranteed.
   
   
Call Avtech Direct
1-800-884-9510 before 5 P.M. Thursday, July 22, 2004


Visit our website at http://www.avtechdirect-nonprofits.com




If you wish to unsubscribe from this list, please go to:
http://www.computeradvice.org/unsubscribe.asp


Avtech Direct
22647 Ventura Blvd., Suite 374
Woodland Hills, CA 91364
--DD.__A53A.26A09.B.AE.8_6--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L1GFn0012768; Tue, 20 Jul 2004 18:16:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6L1GFFe012767; Tue, 20 Jul 2004 18:16:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailao.vtcif.telstra.com.au (mailao.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L1GDow012761 for <[e-mail]>; Tue, 20 Jul 2004 18:16:14 -0700 (PDT) (envelope-from [e-mail])
Received: from mailai.vtcif.telstra.com.au (mailai.vtcif.telstra.com.au [202.12.142.17]) by mailao.vtcif.telstra.com.au (Postfix) with ESMTP id 22D9423413; Wed, 21 Jul 2004 11:16:19 +1000 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id CFDEC1DA84; Wed, 21 Jul 2004 11:16:18 +1000 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA21174; Wed, 21 Jul 2004 11:16:18 +1000 (EST)
content-class: urn:content-classes:message
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
Date: Wed, 21 Jul 2004 11:15:50 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
Thread-Index: AcRuYjSxFs9kg0o7Qoy/d/W+BCH4kAAWUT7g
From: "Manger, James H" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6L1GEow012762
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

That is wrong.

A DN names an object by describing a path to it through a hierarchy of
other objects.  Each RDN consists of attributes of one of those *other*
objects.  Only the last RDN has attributes of the actual named object.
A serialNumber attribute (like any other attribute) can appear multiple
times -- once for each level of the hierarchy (ie once for each RDN).

RDN = *Relative* Distinguished Name.

[Note. No attribute type can appear multiple times within a single RDN.]

In my sample DN:
cn="John Doe" serialNumber=12345, o="Acme Ltd" serialNumber="DUNS
554433", c=US
there are 3 objects: a country, a company and a person.  The person only
has one serialNumber.  The company is an object in its own right so it
can have its own serialNumber.

So please reconsider my suggestion (1) that when identifierValue is
absent the deepest serialNumber value is used.

[Theoretically, the PI draft could require the serialNumber be in the
deepest RDN.  This would ensure the serialNumber is an attribute of the
named object, not of some parent object.  However, I would not recommend
that.  It is not unusual for DNs (particularly in certificates) to only
use 1 attribute per RDN, even if some of the attributes all relate to
the same logical object.]


----------
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, 21 July 2004 12:01 AM

Section 5.2.9 from X520 defines the serial Number attribute as follows:

"The serial Number attribute type specifies an identifier, the serial
number 
of an objet."

The serial Number attribute applies to the object, not to a RDN
component.
Thus, unless it is an error, there can't be multiple serial Number 
attributes in a DN.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L00kHB005227; Tue, 20 Jul 2004 17:00:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6L00k5x005224; Tue, 20 Jul 2004 17:00:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from PC_hipolito.org (dns.sil.edu.pe [64.76.72.108]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6L00hSs005208 for <[e-mail]>; Tue, 20 Jul 2004 17:00:44 -0700 (PDT) (envelope-from [e-mail])
Date: Tue, 20 Jul 2004 19:00:55 -0500
To: "Ietf-pkix" <[e-mail]>
From: "Wpolk" <[e-mail]>
Subject: Re:
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------xubcldenbrrseomxjanc"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

<html><body>
>foto3  and MP3<br><br>

<br>
</body></html>

----------xubcldenbrrseomxjanc
Content-Type: application/octet-stream; name="Doll.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Doll.scr"



----------xubcldenbrrseomxjanc--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KKL651088375; Tue, 20 Jul 2004 13:21:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KKL6Vb088374; Tue, 20 Jul 2004 13:21:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KKL5dT088368 for <[e-mail]>; Tue, 20 Jul 2004 13:21:05 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25882; Tue, 20 Jul 2004 16:21:07 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-15.txt
Date: Tue, 20 Jul 2004 16:21:07 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-15.txt
	Pages		: 56
	Date		: 2004-7-20
	
SCVP allows a client to offload certificate handling to a server.  
The server can provide the client with a variety of valuable 
information about the certificate, such as whether the certificate 
is valid, a certification path to a trust anchor, and revocation 
status.  SCVP has many purposes, including simplifying client 
implementations and allowing companies to centralize trust and 
policy management.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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

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


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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KKKeeU088353; Tue, 20 Jul 2004 13:20:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KKKeiQ088352; Tue, 20 Jul 2004 13:20:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KKKdGN088345 for <[e-mail]>; Tue, 20 Jul 2004 13:20:39 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25809; Tue, 20 Jul 2004 16:20:41 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sim-03.txt
Date: Tue, 20 Jul 2004 16:20:41 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Subject 
			  Identification Method (SIM)
	Author(s)	: J. Park, et al.
	Filename	: draft-ietf-pkix-sim-03.txt
	Pages		: 14
	Date		: 2004-7-20
	
This document defines Privacy-Enhanced Protected Subject Identifier
   (PEPSI) format for including a privacy sensitive identifier in the
   subjectAltName extension of a certificate.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-sim-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-sim-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-sim-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-sim-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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KGmhQ3055119; Tue, 20 Jul 2004 09:48:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KGmhw2055116; Tue, 20 Jul 2004 09:48:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail10.atl.registeredsite.com ([e-mail] [64.224.219.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KGmgeh055106; Tue, 20 Jul 2004 09:48:42 -0700 (PDT) (envelope-from [e-mail])
Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail10.atl.registeredsite.com (8.12.11/8.12.8) with ESMTP id i6KGmjgv015369; Tue, 20 Jul 2004 16:48:45 GMT
Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Tue, 20 Jul 2004 11:48:44 -0500
Message-ID: <[e-mail]>
Date: Tue, 20 Jul 2004 09:43:08 -0700
From: Ed Gerck <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joseph Doekbrijder <[e-mail]>
CC: Christine Karman <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Request: Send me signed messages
References: <[e-mail]> <[e-mail]> <4.3.2.7.2.20040719124821.0280f818@localhost> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Joseph Doekbrijder wrote:

> Ed Gerck wrote:
> 
>> to send encrypted email to many people you need each recipient's cert 
>> (and you also
>> want to make sure they are not revoked at the time they receive the 
>> message, which
>> is yet another problem).
> 
> 
> Why does the sender need to make sure that the encryption certificate of 
> the receiver is not revoked at the time the message is received?
> IMHO this is irrelevant. (Otherwise one would not be able to read very 
> old messages, etc...)

Suppose you encrypt a message to Bob at time T, using Bob's PK cert that
is not revoked at time T (as you verify the CRL). Due to email delays, the
message is delivered at time T + D, at which time Bob's PK cert has been
revoked due to key compromise reported by Bob after time T but before T + D.
The end result is that, unwillingly, you sent Bob an insecure message because
you used his compromised key.

This risk, while not fully preventable, can be reduced. For example, suppose
you estimate that the email delay will not be larger than 5 minutes. You verify
a CRL for Bob's cert and, if the CRL was issued more than 5 minutes ago, wait
for the next CRL and send the email within 5 minutes of its publication. This
can be easily automated by you, using the freshestCRL field.

Cheers,
Ed Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KGcBjm053601; Tue, 20 Jul 2004 09:38:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KGcBfO053599; Tue, 20 Jul 2004 09:38:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail10.atl.registeredsite.com ([e-mail] [64.224.219.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KGcA7l053583; Tue, 20 Jul 2004 09:38:10 -0700 (PDT) (envelope-from [e-mail])
Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail10.atl.registeredsite.com (8.12.11/8.12.8) with ESMTP id i6KGc0IT030172; Tue, 20 Jul 2004 16:38:00 GMT
Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Tue, 20 Jul 2004 11:37:59 -0500
Message-ID: <[e-mail]>
Date: Tue, 20 Jul 2004 09:32:24 -0700
From: Ed Gerck <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>
CC: Christine Karman <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Request: Send me signed messages
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al Arsenault wrote:

> Actually, the sender can't control anything about the time the recipient
> receives the message. All he can do is verify that the recipient's
> certificate is not revoked at the time the message is sent, as the sender
> perceives the time.

Agreed. That's why what would really be desirable [1] cannot be done and
it's an additional problem when sending encrypted email. The same does not
happen with signed email, because the message is usually considered valid if
the cert was valid at the time the message was signed.

Cheers,
Ed Gerck

[1] Ed Gerck wrote:
>> in order to send encrypted email to many people you need each recipient's
>>cert (and you also want to make sure they are not revoked at the time they 
 >> receive the message, which is yet another problem).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KEdFod034543; Tue, 20 Jul 2004 07:39:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KEdFRp034542; Tue, 20 Jul 2004 07:39:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from chris.org (gw.huntprop.com [216.109.168.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6KEdDcE034526 for <[e-mail]>; Tue, 20 Jul 2004 07:39:14 -0700 (PDT) (envelope-from [e-mail])
Date: Tue, 20 Jul 2004 09:39:36 -0600
To: "Ietf-pkix" <[e-mail]>
From: "Anders.rundgren" <[e-mail]>
Subject: Re:
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------milcaxnupfxgfmsfrctl"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

<html><body>
>fotoinfo<br><br>


<br>Password: <img src="cid:iebhawkbdy.bmp"><br>
<br>
</body></html>

----------milcaxnupfxgfmsfrctl
Content-Type: image/bmp; name="iebhawkbdy.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="iebhawkbdy.bmp"
Content-ID: <iebhawkbdy.bmp>

Qk2mCAAAAAAAADYAAAAoAAAAPAAAABIAAAABABAAAAAAAHAIAAAAAAAAAAAAAAAAAAAAAAAA
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/gHyAfIB8
gHyAfIB8gHyAfIB8gHyAfIB8gHyAfIB8gHyAfIB8gHyAfIB8gHyAfIB8gHyAfIB8gHyAfIB8
gHyAfIB8gHyAfP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f5N+gHztfVp//3//f/9/k36AfO19Wn//f/9/vX/tfYB8
1H7/f/9//3+9f+19gHzUfv9//3//f/9/cX6AfO19e3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3/UfoB8nH8Xf4B8nH//f9R+gHycfxd/
gHycf/9/L36AfFp/gHzUfv9//38vfoB8Wn+AfNR+/3//f3F+gHycfxd/gHx7f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3+JfYB8/3/ef4B8
k37/f4l9gHz/f95/gHyTfv9/gHyAfP9/gHyJff9//3+AfIB8/3+AfIl9/3//fy9+gHz/f/9/
gHztff9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3+AfIB8/3//f4B8gHz/f4B8gHz/f/9/gHyAfP9/7X2AfP9/gHyAfP9//3/tfYB8/3+AfIB8
/3//f/9//3//f/9/gHyAfP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3+AfIB8e3//f4B8gHz/f4B8gHx7f/9/gHyAfP9/Wn+AfFp/gHwvfv9/
/39af4B8Wn+AfC9+/3//f/9/vX+9f71/gHztff9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3/tfYB8cX6cf4B8k37/f+19gHxxfpx/gHyTfv9/
/397f4B8gHz2fv9//3//f3t/gHyAfPZ+/3//f/9/7X2AfIl9iX17f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3/UfoB8k36JfXF+3n//f9R+
gHyTfol9cX7ef/9//39xfoB8nH+AfPZ+/3//f3F+gHycf4B89n7/f/9/k36AfDh//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//397f4B8
F3//f/9//3//f3t/gHwXf/9//3//f/9//3+AfIB8/3+AfIB8/3//f4B8gHz/f4B8gHz/f/9/
F3+AfNR+/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f3F+7X3ef4B87X3/f/9/cX7tfd5/gHztff9//39xfoB8nH+AfO19/3//f3F+
gHycf4B87X3/f/9/nH+AfHF+/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9/k36AfIl9Wn//f/9//3+TfoB8iX1af/9//3//f3F+
gHztfb1//3//f/9/cX6AfO19vX//f/9//3+AfIB8gHyAfP9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/


----------milcaxnupfxgfmsfrctl
Content-Type: application/octet-stream; name="Garry.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Garry.zip"



----------milcaxnupfxgfmsfrctl--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KE3ek5028386; Tue, 20 Jul 2004 07:03:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KE3eaU028385; Tue, 20 Jul 2004 07:03:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KE3cV4028367 for <[e-mail]>; Tue, 20 Jul 2004 07:03:39 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA17070; Tue, 20 Jul 2004 16:14:01 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA29490; Tue, 20 Jul 2004 16:03:26 +0200
Message-ID: <[e-mail]>
Date: Tue, 20 Jul 2004 16:02:33 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-10.txt
References: <[e-mail]> <[e-mail]> <001001c46ca3$2f126420$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

> Denis,
> It is good to see that the PI draft is doing progress!
> 
> May I comment a bit on this last revision?

(text deleted)

> Assume that a DoD certificate after the PI upgrade contains the following:
> 
> Subject DN: CN=John Smith, serialNumber=123456, OU=Army, O=DoD, C=US
> PI assigner: 1.23.67.355.23.6.7        (A "sample" OID for the DEERS registry)

This is the fourth case suggested to be supported by James.

> The question I tried to answer was simply: How is automated relying
> party software supposed to use the enhanced identity information?

This is a good question.

> Here follows three possible alternatives:
> 
> 1. X.500-only
> ==========
> ID: CN=John Smith, serialNumber=123456, OU=Army, O=DoD, C=US

The full DN may be used, if the certificate relates through a valid 
certification path to a trusted root key according to some validation policy.

> This scheme becomes (at least principally) dubious, the moment you start
> to deal with multiple assigners (=independent name spaces).   And if you
> only intend to use one assigner, the PI extension becomes redundant.
> 
> 
> 2. X.500 + PI
> ==========
> ID: 1.23.67.355.23.6.7 + CN=John Smith, serialNumber=123456, OU=Army, O=DoD, C=US
> 
> This scheme is not exploiting the primary motive for using permanent
> identifiers, attribute independence (=being able to change name, location
> etc. without getting a "new" identity).

This combination is a not a possible solution.

> 3. PI-only
> =======
> ID: 1.23.67.355.23.6.7 + 123456

The PI composed of the two elements mentionned on the above line may be 
used, if the certificate relates through a valid certification path to a 
trusted root key according to some validation policy.

Denis

> This scheme makes all but one DN attribute redundant.  But the
> unused attributes still contribute to shortening the life-time of the
> certificate, as well as limiting usage to a single assignment (you will
> need a separate certificate for each assignment within the enterprise).
> 
> 
> As far as I can see, PI extensions when applied to a large class of
> X.500-based systems[1] will probably only add more confusion to
> an already complex situation, rather than solving a problem.
> 
> Sincerely
> Anders Rundgren
> 
> 
> 1] it is worth noting that PKIs that were designed from scratch to use
> PIs (there are several large such), do not suffer from these problems.
> However, these PKIs do not follow the X.500 methodology where
> an identity is the combination of a set of hierarchical attributes, qualifying
> the subject.  In my opinion, the idea that an LDAP entry for an employee
> should be linked to a certificate containing a [redundant] copy of the
> directory path, is an off-line world relic.  In an on-line world, subject
> attributes like location, phone number, bank account, job function etc.
> should be dynamically acquired, as well as adapted for the actual
> situation and relation.
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KE1uAH028167; Tue, 20 Jul 2004 07:01:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KE1uQq028166; Tue, 20 Jul 2004 07:01:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KE1t3d028142 for <[e-mail]>; Tue, 20 Jul 2004 07:01:56 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA61216; Tue, 20 Jul 2004 16:12:18 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA29470; Tue, 20 Jul 2004 16:01:43 +0200
Message-ID: <[e-mail]>
Date: Tue, 20 Jul 2004 16:00:49 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: [e-mail]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James,

> 1. The ability to flag a serialNumber attribute value in the subject name 
 > as a permanent identifier is a nice feature.

 > Requiring that there only be a single serialNumber attribute,
 > however, is unnecessarily restrictive.

> It seems quite sensible to use serialNumber attributes to hold company 
 > numbers, org unit ids and/or personal identifiers.

 > For example: cn="John Doe" serialNumber=12345, o="Acme Ltd"
 > serialNumber="DUNS 554433", c=US.

> The PI extension would refer to 12345.

Section 5.2.9 from X520 defines the serial Number attribute as follows:

"The serial Number attribute type specifies an identifier, the serial number 
of an objet."

The serial Number attribute applies to the object, not to a RDN component.
Thus, unless it is an error, there can't be multiple serial Number 
attributes in a DN.

> [Section 2] Change the ASN.1 comment for the identifierValue field of PermanentIdentifier to:
> " -- if absent, use the deepest serialNumber attribute value in the subject DN"

See above.

> [Section 2] Change the paragraph that begins 
 > "When the identifierValue field is absent" to:
> "When the identifierValue field is absent, then the deepest serialNumber attribute 
 > value from the subject DN is the value to be taken for the
 > identifierValue.

 > An attribute is "deeper" if it occurs later in the sequence of RDNs
 > hat make up the DN.  A "deeper" attribute occurs earlier in the string
 > representation of a DN [RFC2253], which start encoding the last element
 > of the RDN sequence that makes up a DN and moves backwards towards the
 > first.

See above.

 > The PermanentIdentifier SHALL NOT be used if there is no serialNumber
 > attribute in the subject DN.

This could be added as a note.

> 2. Why can't the assigner field be present but the identifierValue field 
 >    be absent (refer to the serialNumber attribute)?

 > An absent identifierValue is simply "shorthand" to avoid duplicating
 > a value -- it doesn't really have any sematic value so shouldn't have
 > any impact on the assigner field (or vice versa).

This is a good question.

This combination would mean that the serial Number is not local to the CA 
but is coming from an assigner authority.

Some text proposal follows to support this option:

4 -  The assigner field is present and the identifierValue field is
      absent.

      The assigner field identifies the Assigner Authority and the type
      of permanent identifier being identified. The value of the single
      serialNumber attribute included in the subject DN SHALL be considered
      as the identifier value. The permanent identifier is globally unique
      among all CAs. In such a case, two permanent identifiers of this type
      match if and only if, the contents the serialNumber attributes within
      the subject DN's of those same certificates match using the
      caseIgnoreMatch rule, and the assigner fields match.

      Note: in this case, the PermanentIdentifier SHALL NOT be used
      if there is no serialNumber attribute in the subject DN.


> 3.  The security considerations section mentions an identifierType field 
 >     that no longer exists.

Good catch. Thanks.

Denis

> 
>>----------
>>From: 	[e-mail] [mailto:[e-mail]] 
>>Sent:	Wednesday, 14 July 2004 6:05 AM
>>
>>	Title		: Internet X.509 Public Key Infrastructure Permanent Identifier
>>	Author(s)	: D. Pinkas, T. Gindin
>>	Filename	: draft-ietf-pkix-pi-10.txt
>>	Date		: 2004-7-13
>>	
>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-10.txt
>>
>>	----------
>>	From: 	Denis Pinkas [mailto:[e-mail]] 
>>	Sent:	Thursday, 15 July 2004 6:06 PM
>>	Cc:	[e-mail]
>>
> 
> 		... the definition of the PI has been changed to allow to use the serialNumber attribute from the subject DN.
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KDZjEw024013; Tue, 20 Jul 2004 06:35:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KDZjQD024012; Tue, 20 Jul 2004 06:35:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail45.messagelabs.com (mail45.messagelabs.com [140.174.2.179]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6KDZhw6023964; Tue, 20 Jul 2004 06:35:44 -0700 (PDT) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-7.tower-45.messagelabs.com!1090330533!4296446
X-StarScan-Version: 5.2.10; banners=-,-,-
X-Originating-IP: [141.156.156.57]
Received: (qmail 22909 invoked from network); 20 Jul 2004 13:35:34 -0000
Received: from mtk-news1.mitretek.org (141.156.156.57) by server-7.tower-45.messagelabs.com with SMTP; 20 Jul 2004 13:35:34 -0000
Received: from email1.mitretek.org (localhost [127.0.0.1]) by mtk-news1.mitretek.org (8.12.10/8.12.10) with ESMTP id i6KDZWQm023479; Tue, 20 Jul 2004 09:35:33 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Request: Send me signed messages
Date: Tue, 20 Jul 2004 09:35:31 -0400
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_000A_01C46E3C.E64D8670"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Request: Send me signed messages
Thread-Index: AcRuSHRpin3MZ95wTAyRvwaJbtzwrwADgkow
From: "Fisher, James L." <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C46E3C.E64D8670
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Assuming you really meant: Why should the sender check the status of the
recipient's encryption cert "at the time the message is [SENT]" (not
received)....

Because the sender would not want to encrypt (for confidentiality) using an
encryption cert that has been reported as stolen/compromised.  Otherwise the
thief could read the private message.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Joseph Doekbrijder
Sent: Tuesday, July 20, 2004 5:49 AM
To: Ed Gerck
Cc: Christine Karman; [e-mail]; [e-mail]
Subject: Re: Request: Send me signed messages



Ed Gerck wrote:

> to send encrypted email to many people you need each recipient's cert 
> (and you also
> want to make sure they are not revoked at the time they receive the 
> message, which
> is yet another problem).

Why does the sender need to make sure that the encryption certificate of 
the receiver is not revoked at the time the message is received?
IMHO this is irrelevant. (Otherwise one would not be able to read very 
old messages, etc...)


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCA5sw
ggMEoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgbIxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJn
aW5pYTEVMBMGA1UEBxMMRmFsbHMgQ2h1cmNoMRkwFwYDVQQKExBNaXRyZXRlayBTeXN0ZW1zMRkw
FwYDVQQLExBlQXV0aCBHVyB0ZXN0aW5nMSIwIAYDVQQDExlSb290IGZvciBlQXV0aCBHVyB0ZXN0
aW5nMR8wHQYJKoZIhvcNAQkBFhBqbGZAbWl0cmV0ZWsub3JnMB4XDTAzMDMxMDE4MzMxN1oXDTIz
MDMxMTE4MzMxN1owgbIxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEVMBMGA1UEBxMM
RmFsbHMgQ2h1cmNoMRkwFwYDVQQKExBNaXRyZXRlayBTeXN0ZW1zMRkwFwYDVQQLExBlQXV0aCBH
VyB0ZXN0aW5nMSIwIAYDVQQDExlSb290IGZvciBlQXV0aCBHVyB0ZXN0aW5nMR8wHQYJKoZIhvcN
AQkBFhBqbGZAbWl0cmV0ZWsub3JnMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDp8+A8kT1W
eR5UyTBPkTm0IyYAzHKNlpoI8wqRKlC2+W1VIOJaKFbwUhe0YRjU+f68XivWnULfFtKJKqq7hucD
Hpv11jviE5q/Cj0syKawfEafzwlAlpWsIKHAMspEj/j/NEnydETABVLirziqrxBDoUMIbcWMwrij
5lAaeFDhcQIDAQABo4G+MIG7MB0GA1UdDgQWBBSoIs4jb7OmIizIzKbuhjx5lB+peTAMBgNVHRME
BTADAQH/MAsGA1UdDwQEAwIBBjAyBglghkgBhvhCAQ0EJRYjT3BlblNTTCBDZXJ0aWZpY2F0ZSBm
b3IgQ0EgNTJfZWF1dGgwEQYJYIZIAYb4QgEBBAQDAgEGMBsGA1UdEQQUMBKBEGpsZkBtaXRyZXRl
ay5vcmcwGwYDVR0SBBQwEoEQamxmQG1pdHJldGVrLm9yZzANBgkqhkiG9w0BAQUFAAOBgQA46QSa
KB2ovpBOukH11ULRcImu4FKjti6qO/vgZrUmq+HiE3iDPXlfsQymCmdwL2ln87vK6X7ep1L9BSQe
b6kVIsDF6SPHm3p129NV6Kt20BJX1uE6QVK4yVP3z+J+Knc7uRUvnWQcjnAbFfHCQsZeFuFVRElD
B/l8Sfa3HBHUQzCCBVMwggS8oAMCAQICARAwDQYJKoZIhvcNAQEFBQAwgbIxCzAJBgNVBAYTAlVT
MREwDwYDVQQIEwhWaXJnaW5pYTEVMBMGA1UEBxMMRmFsbHMgQ2h1cmNoMRkwFwYDVQQKExBNaXRy
ZXRlayBTeXN0ZW1zMRkwFwYDVQQLExBlQXV0aCBHVyB0ZXN0aW5nMSIwIAYDVQQDExlSb290IGZv
ciBlQXV0aCBHVyB0ZXN0aW5nMR8wHQYJKoZIhvcNAQkBFhBqbGZAbWl0cmV0ZWsub3JnMB4XDTAz
MDkyNDE1MjA0NloXDTA0MDkyMzE1MjA0Nlowga0xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJn
aW5pYTEVMBMGA1UEBxMMRmFsbHMgQ2h1cmNoMRkwFwYDVQQKExBNaXRyZXRlayBTeXN0ZW1zMR0w
GwYDVQQLExRQS0kgdGVzdGluZyBhbmQgZGVtbzEZMBcGA1UEAxQQamxmQG1pdHJldGVrLm9yZzEf
MB0GCSqGSIb3DQEJARYQamxmQG1pdHJldGVrLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAxJ4wizcrBjovFp21C7sfcqYs9MK/OjV7ZgUziB8MPz/JZPL1QpN9HB6EJsX5Fz1gbigaPMOg
wI32M2peOLjJwB7AFFc9ketLeXDsdOJEjs3v9GgoebNyhi72CPRwis7UUU/Ex75VZdNMmhNqm1hp
holkARvYbAIJods/szk3LBkCAwEAAaOCAnowggJ2MAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQD
AgWgMAsGA1UdDwQEAwIF4DBHBglghkgBhvhCAQ0EOhY4T3BlblNTTCBDZXJ0aWZpY2F0ZSBmcm9t
IENBIDUyX2VhdXRoIC0tIGZvciB0ZXN0aW5nIG9ubHkwHQYDVR0OBBYEFBbYg2DUDegKg7iBV0oP
08uOs/QTMIHfBgNVHSMEgdcwgdSAFKgiziNvs6YiLMjMpu6GPHmUH6l5oYG4pIG1MIGyMQswCQYD
VQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExFTATBgNVBAcTDEZhbGxzIENodXJjaDEZMBcGA1UE
ChMQTWl0cmV0ZWsgU3lzdGVtczEZMBcGA1UECxMQZUF1dGggR1cgdGVzdGluZzEiMCAGA1UEAxMZ
Um9vdCBmb3IgZUF1dGggR1cgdGVzdGluZzEfMB0GCSqGSIb3DQEJARYQamxmQG1pdHJldGVrLm9y
Z4IBADAbBgNVHREEFDASgRBqbGZAbWl0cmV0ZWsub3JnMBsGA1UdEgQUMBKBEGpsZkBtaXRyZXRl
ay5vcmcwgcQGA1UdHwSBvDCBuTCBtqCBs6CBsIaBrUROOkNOJTNkUm9vdCUyMGZvciUyMGVBdXRo
JTIwR1clMjB0ZXN0aW5nJTJjT1UlM2RlQXV0aCUyMEdXJTIwdGVzdGluZyUyY08lM2RNaXRyZXRl
ayUyMFN5c3RlbXMlMmNMJTNkRmFsbHMlMjBDaHVyY2glMmNTVCUzZFZpcmdpbmlhJTJjQyUzZFVT
P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MA0GCSqGSIb3DQEBBQUAA4GBAKW0NgC4
Ddk8yntytgXpz5/ixb3WBTWj8ZfA/3U0zzA77hrZETF7B7XpuRBjf9AHBu4zDH2WW1qzrqkGYRny
PwgEDRnkgE85Uyz1HoTWVHSJNaN0G97H0O3+9NWsbJ6DxiGa6DWHvU39VVcplRM25YNP+9vGtCUJ
yBccxANkmHF2MYIDwzCCA78CAQEwgbgwgbIxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJnaW5p
YTEVMBMGA1UEBxMMRmFsbHMgQ2h1cmNoMRkwFwYDVQQKExBNaXRyZXRlayBTeXN0ZW1zMRkwFwYD
VQQLExBlQXV0aCBHVyB0ZXN0aW5nMSIwIAYDVQQDExlSb290IGZvciBlQXV0aCBHVyB0ZXN0aW5n
MR8wHQYJKoZIhvcNAQkBFhBqbGZAbWl0cmV0ZWsub3JnAgEQMAkGBSsOAwIaBQCgggJgMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcyMDEzMzUzMVowIwYJKoZI
hvcNAQkEMRYEFKDymKD0nSuujY0KhMHSwn7mzkAQMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MAcGBSsOAwIaMAoGCCqGSIb3DQIFMIHJBgkrBgEEAYI3EAQxgbswgbgwgbIxCzAJBgNVBAYTAlVT
MREwDwYDVQQIEwhWaXJnaW5pYTEVMBMGA1UEBxMMRmFsbHMgQ2h1cmNoMRkwFwYDVQQKExBNaXRy
ZXRlayBTeXN0ZW1zMRkwFwYDVQQLExBlQXV0aCBHVyB0ZXN0aW5nMSIwIAYDVQQDExlSb290IGZv
ciBlQXV0aCBHVyB0ZXN0aW5nMR8wHQYJKoZIhvcNAQkBFhBqbGZAbWl0cmV0ZWsub3JnAgEQMIHL
BgsqhkiG9w0BCRACCzGBu6CBuDCBsjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRUw
EwYDVQQHEwxGYWxscyBDaHVyY2gxGTAXBgNVBAoTEE1pdHJldGVrIFN5c3RlbXMxGTAXBgNVBAsT
EGVBdXRoIEdXIHRlc3RpbmcxIjAgBgNVBAMTGVJvb3QgZm9yIGVBdXRoIEdXIHRlc3RpbmcxHzAd
BgkqhkiG9w0BCQEWEGpsZkBtaXRyZXRlay5vcmcCARAwDQYJKoZIhvcNAQEBBQAEgYCYC5jTOY+j
5TRAFwbjS8Eup62tSn6pjeWhHVsyAAg7LkRmej85NAa0ln1xVA1nt9J7x6HNS3HT12cgiZWSQGtx
TeHepiGln1fZqzZA9PRjhK4z1QULXGUTdnPAhh35vj1fRrjh2Gab7pe+xK+pCnHjREJzfPqHOf8F
LRmOL2qKvQAAAAAAAA==

------=_NextPart_000_000A_01C46E3C.E64D8670--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KBQGuv001723; Tue, 20 Jul 2004 04:26:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KBQG5c001720; Tue, 20 Jul 2004 04:26:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KBQFPU001698; Tue, 20 Jul 2004 04:26:15 -0700 (PDT) (envelope-from [e-mail])
Received: from arsenaultd2 (col-dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id i6KBQ87W008341; Tue, 20 Jul 2004 07:26:09 -0400 (EDT)
From: "Al Arsenault" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, "Christine Karman" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Request: Send me signed messages
Date: Tue, 20 Jul 2004 07:22:31 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <[e-mail]>
Importance: Normal
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Actually, the sender can't control anything about the time the recipient
receives the message. All he can do is verify that the recipient's
certificate is not revoked at the time the message is sent, as the sender
perceives the time.

	Al Arsenault


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Ed Gerck
> Sent: Monday, July 19, 2004 8:26 PM
> To: Christine Karman
> Cc: [e-mail]; [e-mail]
> Subject: Re: Request: Send me signed messages
>
>
>
>
>
> Christine Karman wrote:
>
> > At 09:43 PM 7/16/2004, Ed Gerck wrote:
> >
> >> An obvious problem with email certificates is that they open
> us to spam.
> >
> >
> > How's that?
>
> A repository of certs with email addresses is a repository of
> email addresses.
>
> > If you accept encrypted email, then you can refuse unsigned email.
>
> You can do the latter without doing the former. Beseides, while
> it's relatively easy
> to send signed email to many people (as it depends only on your
> cert), in order
> to send encrypted email to many people you need each recipient's
> cert (and you also
> want to make sure they are not revoked at the time they receive
> the message, which
> is yet another problem).
>
> Cheers,
> Ed  Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K9nIIj069332; Tue, 20 Jul 2004 02:49:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K9nI4F069330; Tue, 20 Jul 2004 02:49:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.2wire.ch (mail.2wire.ch [62.65.128.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K9nGWY069268 for <[e-mail]>; Tue, 20 Jul 2004 02:49:16 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 76976 invoked by uid 89); 20 Jul 2004 09:49:10 -0000
Received: from unknown (HELO swisssign.com) (62.65.151.222) by mail.2wire.ch with SMTP; 20 Jul 2004 09:49:10 -0000
Message-ID: <[e-mail]>
Date: Tue, 20 Jul 2004 11:48:58 +0200
From: Joseph Doekbrijder <[e-mail]>
Organization: SwissSign AG
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-ch, en-us, en, fr-ch
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: Christine Karman <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Request: Send me signed messages
References: <[e-mail]> <[e-mail]> <4.3.2.7.2.20040719124821.0280f818@localhost> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080600090600050304000002"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms080600090600050304000002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit



Ed Gerck wrote:

> to send encrypted email to many people you need each recipient's cert 
> (and you also
> want to make sure they are not revoked at the time they receive the 
> message, which
> is yet another problem).

Why does the sender need to make sure that the encryption certificate of 
the receiver is not revoked at the time the message is received?
IMHO this is irrelevant. (Otherwise one would not be able to read very 
old messages, etc...)



-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: [phone] / Mobile: [phone]
www.swisssign.com
--------------------------------------------------

This message has been digitally signed to ensure unaltered and 
authenticated reception. Should you receive an error message regarding 
the validity of the signature, please click and download the SwissSign 
root certificate using the following link  https://swisssign.net/trust/
After installation, your mail client will be able to automatically 
verify the authenticity of e-mail messages sent to you by users of 
SwissSign certificates.


--------------ms080600090600050304000002
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWiTCC
A2EwggJJoAMCAQICCGQgZ70rBHuyMA0GCSqGSIb3DQEBBQUAMGkxIzAhBgNVBAMTGlN3aXNz
U2lnbiBQZXJzb25hbCBHb2xkIENBMSEwHwYJKoZIhvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5j
b20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMjExMTQzOTA1WhcN
MDQxMjExMTQzOTA1WjB4MSQwIgYDVQQDExtKb3NlcGggQW50b25pdXMgRG9la2JyaWpkZXIx
LzAtBgkqhkiG9w0BCQEWIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMRIwEAYD
VQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQCpc7LucWH/EP2YmDBOMZVmPzy8JfYovxAL8wbfuXjFQLg4/orh+8AonyozzaK0fJzFw/D4
46z3siNvu065E6AKM3BFPSsyS5RrUPnYjtxcLAmfv+OsR5gAMA1hhsS571XCWaVPvEuCIltW
RvpcKVeuAsdpR6p7eW7UPQuO0EgR4QIDAQABo4GBMH8wHwYDVR0jBBgwFoAU8jaGz72k1nnf
MpmM0FlpHQWVLIYwDgYDVR0PAQH/BAQDAgQwMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQGCCsG
AQUFBwMEMCsGA1UdEQQkMCKBIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMA0G
CSqGSIb3DQEBBQUAA4IBAQBY4/HrZkMYrF0LKNWpDrYTbEM7wRjHKtpjMHWb1DlAm1qRBWAB
0Ns/jyCHLedGlRydHuVPh+THO9PPgRESIWoWq88uz+gpue3A4DWpuk7BqrYKXFfKTa1uKsfE
L62LJ0cO8Q09aCkkEpETL8u92s68328QPhSgFmX5wgToyG3Vw2EOMTcbCeKFRYSkZTywe2NV
IMkDKKUDuRYBYZZ1Db8P3SzF26bszuUH+4HsbgIg8K+mrEeln9aHpbujAUVx8huCpYR25Ziz
rtK2vHmDd2VQUfOs+gA4dns7Ys+sOYXYWn2ZvXycCirQktDuaOTAxRXrBXByGLTNDsJBsNQI
FbZdMIIDqTCCApGgAwIBAgIIXLEyej+EomAwDQYJKoZIhvcNAQEFBQAwZDEcMBoGA1UEAxMT
U3dpc3NTaWduIFNpbHZlciBDQTEjMCEGCSqGSIb3DQEJARYUc2lsdmVyQHN3aXNzc2lnbi5j
b20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMDEyMTEzODIyWhcN
MTUxMDA2MTMzNjU3WjBgMRowGAYDVQQDExFTd2lzc1NpZ24gR29sZCBDQTEhMB8GCSqGSIb3
DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYT
AkNIMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAstKfzDugVAxC63Qhl8+Cko7T
Kjh0aMls6o0iYfPE6LU9jRHGRE2FyEoI4+3EgotNIVEX7GOTtQUL3YRzkJ55T/urzNtWDead
etokNxoH1KrYObxIuFeSyepEN/QKcNedliNqwGF3wPqKCGna554QeyV44pRhvNH3+hFL3Mz3
Tazf2wtmE/et/JSAFFUPWfSqrugURE1G2kaB9o2tt/BFtEjslSD41D9g7nexjvgHDyRKsoY3
FoEHexV/ttvFZNzGJJ7NLwgC84JvCdLi3RvNyGfiWnqkjuRdQOohAsWNJcjn7aoksB5y/Ipr
BjsivtY/LBYQ7zq+Sc8v+8bf3T1lzwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUtGz1MEEswDyRjDQnY/pVvPzntD8wHwYDVR0jBBgwFoAU
EvoMgVv/f9El2B5zMDUPRhg2snUwDQYJKoZIhvcNAQEFBQADggEBADG0plqQXp/SAJjFJYax
q1R+3LaDheER1IgXaIem+nofwcBaCvEP+vkWkEuBwFbvI97tKlO6oY1WtVlJHbkfHXcvRAiv
s8W9EbuQlXJ9g1J+ZKJbnI/KmTwsNYvHj5PBe9+PwvA1oZwTJDEEBSaUcdOxaNw3ceka7oTd
dWXfAWUhGXDmS3O2yTHVovUrFAshmYEz9r4YRvbUzkKYcP12zOu2UmdrCOzSWua2EOuSimLM
se00IOJTlhJMfL+ly6O8G1MA7wTqKkSgnDbVe0XsMQYmSJaiVqSkRGIUYE7mvlq9YKCguBZ1
fpmurO0BeWvmzZxZT/7VBjcfMzwS1tZ4CeAwggOuMIIClqADAgECAggQSAsMRGstRTANBgkq
hkiG9w0BAQUFADBgMRowGAYDVQQDExFTd2lzc1NpZ24gR29sZCBDQTEhMB8GCSqGSIb3DQEJ
ARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNI
MB4XDTAzMTAxMjExNTgyMloXDTA2MTAxMjExNTgyMlowaTEjMCEGA1UEAxMaU3dpc3NTaWdu
IFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNvbTES
MBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAMZmnWhcHmQ8GZB+9uoZyb+LmqUqYRWWL6vSFwWMSQdtn7aMT0zVI1N37y2I
LN5/KurG53SonxgMfwqsxgdD3jI77yyJwsN0aMdBDotcL+pXSJqlC1gpDsVHtMIyQs5PqYTx
Y3uUJVbBERchLFLv/2VJ0iBGXg009lyNVULa9VFcG/F2UF34YranOWBW4OSQowf1kJYNXr4A
eKhpLnNhv30/fdIMRrihygQCPaMJ0nQAEuBVbFSfOUQPvMDDBwYKC+yMkcm5QWgnVGXAeyrA
x7k8+rKPfNbYqnyeL9aAnyUMkYm6FtUsaM5I6HNWJY63gfqqPeprFuogZNY1Rwq2mNMCAwEA
AaNjMGEwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPI2hs+9
pNZ53zKZjNBZaR0FlSyGMB8GA1UdIwQYMBaAFLRs9TBBLMA8kYw0J2P6Vbz857Q/MA0GCSqG
SIb3DQEBBQUAA4IBAQCuHGJh9r2LiKenYuA4Imi1TZ0YWVB0o2Kfo6HD3CPZwavyPzXiShM0
0PGIoX/bs+K36PYj24E6gdp78B4hzqPP525wUapDy/WX8nur8XbrcdEwffWy+Cmz593an7Xy
iFl18wIDGLGkpGpwtM/Jiu2QLUughU7Eh0/i6R1+oUPLF9wYcB0eoYnDBK0KWFvTEWkLAWYb
F45PV4tsBXWI+UTQBB93rgdjQbJNxSv7K/kLAQY/mWs9fF2jp4X8+UMthm28TkHE7VAok0md
Ma9x3X1ZrMDmb3ijkUxwJhFewelg9vMZdcXUHjezw5J83L5I8aBQmfKIHLDEg2XVcQUhMi/B
MIIDwDCCAqigAwIBAgIJAOjyHqbBu/cuMA0GCSqGSIb3DQEBBQUAMHYxCzAJBgNVBAYTAkNI
MRIwEAYDVQQKEwlTd2lzc1NpZ24xMjAwBgNVBAMTKVN3aXNzU2lnbiBDQSAoUlNBIElLIE1h
eSA2IDE5OTkgMTg6MDA6NTgpMR8wHQYJKoZIhvcNAQkBFhBjYUBTd2lzc1NpZ24uY29tMB4X
DTAzMTAwNjEzMzY1N1oXDTE1MTAwNjEzMzY1N1owZDEcMBoGA1UEAxMTU3dpc3NTaWduIEJy
b256ZSBDQTEjMCEGCSqGSIb3DQEJARYUYnJvbnplQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoT
CVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDA0TvGY7vE2Z2U4Ootl3tb6AZN4SPTTN6HYMyzL9OeKWzlMfnwJqEzv4yjkFMcaStrmyRO
PMkwLEWcd3FiaxKBmr0eCN9ybgZuhKvSxYfaqcM5QAgPqK6yA2WQ+sgWAUlEH4PdhCUYd84q
eOlswzzrtbggVWQsbh/LoT7edOeBJlDiIHufmmXTl5X7psFIImkWJbnegd7fidhRuUxMJF0X
LcA/9WaJzZDZSmGONRSP+WOzlM/o4xunjPwIoCWKSIo9NMWtJ29az01/TcLehpyMjQg7a+PJ
3yFtl5PbS25Jm7W9IopISNPGYzucjOIVKYo9BQ5F32lGn8NJl418yNttAgMBAAGjYzBhMA4G
A1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRygIjtngs9r6moa09a
F+LUoY5lJDAfBgNVHSMEGDAWgBSW13HNOSrU/IixiqtTeGnvj0d+FjANBgkqhkiG9w0BAQUF
AAOCAQEApFfZjNGeQ7OtxCPI3mI1rjF2gbxMTMtMeJeaxH2QSJsrvcKRQ29v0wzDLMmeKFR8
d3B8PDh8aqw2IGz1X3FcIn7CUTdoOvFCGuW0SpdvKzgt3RVOpp4HFcfMK6mxubSHCBV6f66A
UyxbK+Sv7Rpwn3BZ6AYndMzYMEk6IrAvrurIz6h2DTrwEO3oH1GKRpYljlcoh+mKEnvZit6b
vGNcLpLTMZNe+0dlKzw1uHNI9gqteNqn/BqunMDAqPcBX4uZ0em7P/ZJ8+SACnsz96+R5MSV
EeoFqWQoRQAxNgjUXTy0xYa4cGRqeXtTO/s3mKgDBWktCFXU0f0kb0IQIBmGqDCCA/gwggLg
oAMCAQICCQDemCdyDdsdVTANBgkqhkiG9w0BAQUFADBkMRwwGgYDVQQDExNTd2lzc1NpZ24g
QnJvbnplIENBMSMwIQYJKoZIhvcNAQkBFhRicm9uemVAc3dpc3NzaWduLmNvbTESMBAGA1UE
ChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDAeFw0wMzEwMTIxMTM2MzJaFw0xNTEwMDYxMzM2
NTdaMGQxHDAaBgNVBAMTE1N3aXNzU2lnbiBTaWx2ZXIgQ0ExIzAhBgkqhkiG9w0BCQEWFHNp
bHZlckBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzPdBfCH+e+kxpt0cSTkKm1pJXXdRCNJ8
mrbsNpuX2O290pzz1dEF7DKFCH+k9bm8Yqj1KgyhKrt7JoNGUHW83sU+8jjrYG/ZPrfusCH+
4iiVZciBCvPdM1t0qvPZvWrKVYdIb+3t8aQz8+L08zFLdkxG49M+4cMW5srECPy4YJ3kJzVr
awrXBMAchqviMngsyWuKw5qV5FA9pp36wDsumItoZXL3BOsMsU2lh3z/OLhDpXA5D83mgEOW
RbqkfSWyaT1lcIuoMZ/XMdT8ahU+3GWnZ8O9tQFg0//SfrlT3Zsp7Hhx0XEtsuIKQZTrsUHj
QzR+bk9RlKLz3Sy5nxPRRQIDAQABo4GsMIGpMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E
BTADAQH/MB0GA1UdDgQWBBQS+gyBW/9/0SXYHnMwNQ9GGDaydTAfBgNVHSMEGDAWgBRygIjt
ngs9r6moa09aF+LUoY5lJDBGBgNVHR8EPzA9MDugOaA3hjVodHRwczovL3N3aXNzc2lnbi5u
ZXQvY2dpLWJpbi9hdXRob3JpdHkvY3JsP2NhPUJyb256ZTANBgkqhkiG9w0BAQUFAAOCAQEA
qaVWxVi644azmxYNNglkRVA5pFsU3zN4zepYrjEmamFgGROsNKYCwf06cGDHXsJyxZzkzFPG
FTR5/pRLoDWnEuFgfm+a6XA9qTUecun+909Dkz8EbNk/KsWaGEG+HxMjwnusctjeWhO32rRH
+AWJW9VhNR+ggbkGwbVadRClY7359ChoWTwkySWb2hjTZU3BOnqAOYJ2QPKiWMrGODN9Jo94
+hfxcD6o08ak5KY/5Bza4EEL/sbS/quhoCZsg8TBD4+KeXgbVqU9XlPHk/gq1RTy49SPmRkQ
lgwFSvQRRAD/5oQX3ZKxhXAVsEYHyGvqCsFvXWKagulb5NjNdD0pyTCCBAEwggLpoAMCAQIC
CQCVT/juYWAhTDANBgkqhkiG9w0BAQUFADBpMSMwIQYDVQQDExpTd2lzc1NpZ24gUGVyc29u
YWwgR29sZCBDQTEhMB8GCSqGSIb3DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQK
EwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMB4XDTAzMTIxMDIxNDAwMVoXDTA0MTIxMDIxNDAw
MVoweDEkMCIGA1UEAxMbSm9zZXBoIEFudG9uaXVzIERvZWticmlqZGVyMS8wLQYJKoZIhvcN
AQkBFiBqb3NlcGguZG9la2JyaWpkZXJAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NT
aWduMQswCQYDVQQGEwJDSDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJVGvsFb
4Ufs++D4cxTnv2yHvmLjKZQ2qfPT7YO2dfffZbiba4qkKQ8xLE05D1EqlLvXm+4dRksjDhty
OzwZeWajZ/TGwPgP3jXOURlqkyhVrX0kt5EzW5EokcMC/Ais422LqtJ5kq2nOvK7NGYtevS0
pMbHi5NZtkWUwVZaRjjOJaTGO2xDkjAOdYIyI8vdEIedJIW6LGHIZsYjI+yW7sUlI6hCXhrV
nsmdu/shG/TTsvDQUW28Yl7/l/uvikFsuy4erDKDHcbth/xKsI/KkfX40jGqGI0SlQ7fHBph
DwbnbOKJJSu1wgMT1dvuwLyFEBqyf0OSPZROpK11T3d2LdcCAwEAAaOBnDCBmTAfBgNVHSME
GDAWgBTyNobPvaTWed8ymYzQWWkdBZUshjAOBgNVHQ8BAf8EBAMCA8gwKQYDVR0lBCIwIAYI
KwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3FAICMDsGA1UdEQQ0MDKgMAYKKwYBBAGCNxQC
A6AiDCBqb3NlcGguZG9la2JyaWpkZXJAc3dpc3NzaWduLmNvbTANBgkqhkiG9w0BAQUFAAOC
AQEAZTUBqQgk5nB+0W7Mozv/uD6lRurjZhWShstlaQ43qvVHcsDgb4mW/bynla9BDmM/NsQU
43ZsoFxjkJsxFCpgm5BuMt1KuD7FSHJ0mxRswaGf9mHxftU1cu/YhY/AjrsFHEnsPHZaYAAm
jcKunHgT+yckvUZR3RQDkgVE4PQ3YpsG1EPKQSEAFbmWAd4+TxJmuBXThDM63gOkY4Q7gE1b
Y1kjkdRlJ2TZ/gOItQ3AsfwS7mq+ANYnUBrWkrnUd85Nmgzv5ys7zxuz9tp64vS+xYW98mri
ruGl9stN/b7SbOFTsp8SUm83e9qPOQZRYPS6TYYKUObj3LbaXJEIqKD51DGCA2IwggNeAgEB
MHYwaTEjMCEGA1UEAxMaU3dpc3NTaWduIFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0B
CQEWEmdvbGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJD
SAIJAJVP+O5hYCFMMAkGBSsOAwIaBQCgggHBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTA0MDcyMDA5NDkwNVowIwYJKoZIhvcNAQkEMRYEFPsQjDKAfN16
PQ3cLhzCMYqNiUPiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGEBgkrBgEEAYI3
EAQxdzB1MGkxIzAhBgNVBAMTGlN3aXNzU2lnbiBQZXJzb25hbCBHb2xkIENBMSEwHwYJKoZI
hvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UE
BhMCQ0gCCGQgZ70rBHuyMIGGBgsqhkiG9w0BCRACCzF3oHUwaTEjMCEGA1UEAxMaU3dpc3NT
aWduIFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNv
bTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSAIIZCBnvSsEe7IwDQYJKoZIhvcN
AQEBBQAEggEAUibz/rnjBYH2gqFJ3tTAEkaF6+Y1A4otwihodHSF06wGQLD9zj/GG09awCHz
xDcS0qi8CGHcn7LUx3hpr/etjOD2vCYJjFVGtHSE6y9wG3+vz2Eh7Ons4NRGhNt7Lu/CB8yu
sMQ9La5hpxiiT2NP3xE2EFuSPpWZKoW3lIC9OM+lYVB5J3sWc7vYX2HNcMBpg+wqkXQd35E8
pXokxaGC3/9lzbVJNYjx0eeeDqWeE8VFyAP5p0nKZ3TQA6ZHtUKiW1TQcacYRwfWFkuKq59t
VdCRoxlaRXovPN43OPKMdCp4SicM1CFsZgisuUSreKOM3WTXMt2BjnH0Zl8Uz8P8xAAAAAAA
AA==
--------------ms080600090600050304000002--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K7gLlJ013877; Tue, 20 Jul 2004 00:42:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K7gLJF013876; Tue, 20 Jul 2004 00:42:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail6.hitachi.co.jp (mail6.hitachi.co.jp [133.145.228.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K7gK6Q013868 for <[e-mail]>; Tue, 20 Jul 2004 00:42:21 -0700 (PDT) (envelope-from [e-mail])
Received: from mc3.mcg.hitachi.co.jp by mail6.hitachi.co.jp (8.9.3p3/3.7W-mail6) id QAA16835; Tue, 20 Jul 2004 16:42:20 +0900 (JST)
Received: (from root@localhost) by mc3.mcg.hitachi.co.jp (8.11.6+Sun/8.11.6) id i6K7gJX08473 for [e-mail]; Tue, 20 Jul 2004 16:42:19 +0900 (JST)
Received: from unknown [192.168.2.1]  by mc3.mcg.hitachi.co.jp with SMTP id SAA08468; Tue, 20 Jul 2004 16:42:18 +0900
Received: from navsg2.hitachi.co.jp by navsg2.hitachi.co.jp (8.9.3/3.7W-navsg2) id QAA03869; Tue, 20 Jul 2004 16:42:18 +0900 (JST)
Received: from hsdlgw92.sdl.hitachi.co.jp ([133.144.7.20]) by navsg2.hitachi.co.jp (SAVSMTP 3.1.6.45) with SMTP id M2004072016421724041 for <[e-mail]>; Tue, 20 Jul 2004 16:42:17 +0900
Received: from vgate2.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.9.3/3.7W01100113) id QAA13162; Tue, 20 Jul 2004 16:42:19 +0900
Received: from yokolab1.sdl.hitachi.co.jp ([133.144.101.11]) by vgate2.sdl.hitachi.co.jp (SAVSMTP 3.1.1.32) with SMTP id M2004072016385824606 for <[e-mail]>; Tue, 20 Jul 2004 16:38:58 +0900
Received: from sdl.hitachi.co.jp (ip06145.sdl.hitachi.co.jp [133.144.6.145]) by yokolab1.sdl.hitachi.co.jp (8.12.11/3.7W04031011) with ESMTP id i6K7gI3C029699 for <[e-mail]>; Tue, 20 Jul 2004 16:42:18 +0900
Message-ID: <[e-mail]>
Date: Tue, 20 Jul 2004 16:43:53 +0900
From: Hisanori Mishima <[e-mail]>
Organization: Systems Development Lab., Hitachi, Ltd., Japan
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, ko-kr, zh
MIME-Version: 1.0
To: [e-mail]
Subject: Asia PKI Interoperability Guideline v1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear PKIX members,

I'm Hisanori Mishima, chair of Interoperability WG (IOWG),
Asia PKI Forum (APKI-F).

I'd like to announce our recent two news
related to multi-domain PKI Interoperability.


First is,
we have finalized
"Asia PKI Interoperability Guideline v1.0"
as a technical standard for multi-domain PKI interoperability
during its annual meeting in March 2004 (Singapore).

We opened it to public from our Web site;
http://www.asia-pkiforum.org/
"Resource".


Second is,
JKST-IWG (PKI interoperability proof experiment team in APKI-F,
consisted of Japan, Korea, Singapore and Chinese Taipei)
have opened the Web version of "Asia PKI Interoperability Guideline".
URL is following;

  "CA-CA Interoperability Guideline, 1st edition"
http://www.japanpkiforum.jp/CAGuideline/guideline/index.html


I hope many people will visit to our web sites.


Best Regards,
Hisanori Mishima

------------------------------------------------------------------
The Asia PKI Forum is an international, non-profit-organization,
established on June 13, 2001, promoting joint-work for the secure
interoperability between country's/area's PKIs
as the infrastructures in the Asia/Oceania Region.

http://www.asia-pkiforum.org/
------------------------------------------------------------------

[e-mail]

Senior Manager
7th Research Dept.
(Security systems Research Dept.)
Hitachi, Ltd., Systems Development Laboratory

Tel:[phone]
Fax:[phone]

Hitachi System Plaza Shinkawasaki,
890, Kashimada, Saiwai-ku, Kawasaki-shi,
Kanagawa-ken, 212-8567 Japan




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K0V43E079077; Mon, 19 Jul 2004 17:31:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K0V4Ut079075; Mon, 19 Jul 2004 17:31:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail5.atl.registeredsite.com ([e-mail] [64.224.219.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K0V3pa079062; Mon, 19 Jul 2004 17:31:03 -0700 (PDT) (envelope-from [e-mail])
Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail5.atl.registeredsite.com (8.12.11/8.12.8) with ESMTP id i6K0V8Zu006417; Tue, 20 Jul 2004 00:31:08 GMT
Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Mon, 19 Jul 2004 19:31:05 -0500
Message-ID: <[e-mail]>
Date: Mon, 19 Jul 2004 17:26:02 -0700
From: Ed Gerck <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christine Karman <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Request: Send me signed messages
References: <[e-mail]> <[e-mail]> <4.3.2.7.2.20040719124821.0280f818@localhost>
In-Reply-To: <4.3.2.7.2.20040719124821.0280f818@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Christine Karman wrote:

> At 09:43 PM 7/16/2004, Ed Gerck wrote:
> 
>> An obvious problem with email certificates is that they open us to spam.
> 
> 
> How's that?

A repository of certs with email addresses is a repository of email addresses.

> If you accept encrypted email, then you can refuse unsigned email. 

You can do the latter without doing the former. Beseides, while it's relatively easy
to send signed email to many people (as it depends only on your cert), in order
to send encrypted email to many people you need each recipient's cert (and you also
want to make sure they are not revoked at the time they receive the message, which
is yet another problem).

Cheers,
Ed  Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K075aV074611; Mon, 19 Jul 2004 17:07:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K0752i074609; Mon, 19 Jul 2004 17:07:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.vtcif.telstra.com.au (mailbo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K073Q0074573 for <[e-mail]>; Mon, 19 Jul 2004 17:07:04 -0700 (PDT) (envelope-from [e-mail])
Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailbo.vtcif.telstra.com.au (Postfix) with ESMTP id 98A3F234AC for <[e-mail]>; Tue, 20 Jul 2004 10:07:02 +1000 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 423311DA83 for <[e-mail]>; Tue, 20 Jul 2004 10:07:02 +1000 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA00607 for <[e-mail]>; Tue, 20 Jul 2004 10:07:02 +1000 (EST)
content-class: urn:content-classes:message
Subject: RE: PI: 10: single serialNumber attribute
Date: Tue, 20 Jul 2004 10:05:59 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: I-D ACTION:draft-ietf-pkix-pi-10.txt
Thread-Index: AcRpISpRw39Rj0boTiKQ1oDDudjrzgEIUs5QACocGpA=
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6K074Q0074598
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sure, that DN has 2 permanent identifiers.
However, only one is a PI for this subject.  A cert for this subject can ignore the other PI.  An 'instanceNumber' is unnecessary as DNs are hierarchical so the "deepest" serialNumber attribute will always be the most specific to the subject.

> 	----------
> 	From: 	Anders Rundgren [mailto:[e-mail]] 
> 	Sent:	Monday, 19 July 2004 7:52 PM
> 	To:	Manger, James H; [e-mail]
> 
> 	But is this not actually a prime example of a scheme using TWO PIs?
> 
> 	This would however also require an updated specification where something like an optional "instanceNumber" would be featured to point out the actual serialNumber to use.
> 
> 
	>> For example: cn="John Doe" serialNumber=12345, o="Acme Ltd" serialNumber="DUNS 554433", c=US.  The PI extension would refer to 12345.

>  



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JJx0Lf028999; Mon, 19 Jul 2004 12:59:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JJx0TW028998; Mon, 19 Jul 2004 12:59:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JJwv2T028991 for <[e-mail]>; Mon, 19 Jul 2004 12:58:59 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19612; Mon, 19 Jul 2004 15:58:59 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldap-ac-schema-01.txt
Date: Mon, 19 Jul 2004 15:58:59 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure LDAP 
			  Schema for X.509 Attribute Certificates
	Author(s)	: D. Chadwick, M. Sahalayev
	Filename	: draft-ietf-pkix-ldap-ac-schema-01.txt
	Pages		: 0
	Date		: 2004-7-19
	
This document describes an LDAP schema for X.509 attribute certificates (ACs). Each AC is broken down into a set of attribute types. These attributes can then be stored in an AC entry. An object class is defined for this AC entry. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-ldap-ac-schema-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-ldap-ac-schema-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-ldap-ac-schema-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ldap-ac-schema-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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JFmasj083788; Mon, 19 Jul 2004 08:48:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JFmaUo083787; Mon, 19 Jul 2004 08:48:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from FatDNS.com (host166-69.discord.birch.net [65.16.166.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JFmZ6Z083779 for <[e-mail]>; Mon, 19 Jul 2004 08:48:35 -0700 (PDT) (envelope-from [e-mail])
Received: from SN [65.16.166.68] by FatDNS.com with ESMTP (SMTPD32-7.07) id AD51D710086; Mon, 19 Jul 2004 10:48:33 -0500
Reply-To: <[e-mail]>
From: "Scott Harris" <[e-mail]>
To: "'Joseph Doekbrijder'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Request: Send me signed messages
Date: Mon, 19 Jul 2004 10:47:40 -0500
Organization: XRamp Technologies, Inc.
MIME-Version: 1.0
Content-Type: application/x-pkcs7-mime; smime-type=signed-data; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <[e-mail]>
thread-index: AcRtgpcDRr6T6OxBQTmM3crI8ubp4QAHWf2w
Message-Id: <200407191048444.SM01248@SN>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEVUNvbnRl
bnQtVHlwZTogdGV4dC9wbGFpbjsNCgljaGFyc2V0PSJpc28tODg1OS0xIg0KQ29udGVudC1UcmFu
c2Zlci1FbmNvZGluZzogOGJpdA0KDQoEghAASGksDQoNCkFsdGhvdWdoIHRoaXMgaXMgbXkgZmly
c3QgcG9zdCwgSSBoYXZlIGJlZW4gc3Vic2NyaWJlZCB0byB0aGlzIGxpc3QgZm9yDQpxdWl0ZSBz
b21lIHRpbWUgYW5kIEkga25vdyBhIGZldyBvZiB5b3UgcGVyc29uYWxseS4NCg0KSSB3b3JrIGZv
ciBhIGNvbXBhbnkgY2FsbGVkIFhSYW1wIGFuZCB3ZSBhcmUgYSBUcnVzdGVkIENBIHdobyBpc3N1
ZXMNCldlYnNlcnZlciBDZXJ0cyBhbmQgZW1haWwgY2VydHMuDQoNCkkgYW0gdmVyeSBpbnRlcmVz
dGVkIGluIGNyZWF0aW5nIGEgY2VudHJhbGl6ZWQgcmVwb3NpdG9yeSBmb3IgZW1haWwNCmNlcnRp
ZmljYXRlcyB0aGF0IHdpbGwgaW50ZXJmYWNlIHdpdGggT3V0bG9vayBhbmQgRXVkb3JhIChhcyB3
ZWxsIGFzIG90aGVyDQpwb3B1bGFyIG1haWwgc3lzdGVtcykgYW5kIGFsbG93IHBlb3BsZSB0byBn
cmFiIHNvbWVvbmUncyBlbWFpbCBjZXJ0aWZpY2F0ZQ0KYmFzZWQgb24gdGhlaXIgZW1haWwgYWRk
cmVzcyBhbmQgZW5jcnlwdCBhIG1lc3NhZ2UgdG8gdGhlbSB3aXRob3V0IHRoZQ0Kc3RhbmRhcmQg
c3dhcHBpbmcgb2YgY2VydGlmaWNhdGVzLiAgVGhlIHN5c3RlbSBzaG91bGQgYmUgZmFpcmx5IHNl
YW1sZXNzIGFuZA0KZWFzeSB0byB1c2UuDQoNClRoaXMgZG9lcyBub3QgY2F1c2UgYW55IHNwYW0g
cHJvYmxlbXMgYXMgdGhlIHNwYW1tZXIgd291bGQgaGF2ZSB0byBoYXZlIHRoZQ0KZW1haWwgYWRk
cmVzcyBpbiBvcmRlciB0byBnZXQgYSBjZXJ0aWZpY2F0ZSBiYWNrLiAgV2UgY2FuIGFsc28gc2V0
IHVwIHRoZQ0KcmVwb3NpdG9yeSBzbyB0aGF0IGl0IHJlcXVpcmVzIGEgbG9naW4gdGhhdCBjYW4g
YmUgcmVqZWN0ZWQgaWYgc29tZW9uZSBpcw0KYWJ1c2luZyB0aGUgc3lzdGVtLg0KDQpJIGhhdmUg
cGxheWVkIGFyb3VuZCB3aXRoIHRoaXMgaWRlYSB1c2luZyBMREFQLCBob3dldmVyIGl0IHdhcyBx
dWl0ZQ0KYW50aWNsaW1hY3RpYyAtIHBvc3NpYmx5IEkgc2ltcGx5IGRvIG5vdCB1bmRlcnN0YW5k
IExEQVAgd2VsbCBlbm91Z2guICBJDQp0aGluayBpdCB3aWxsIGhhdmUgdG8gYmUgYSBjdXN0b20g
dG9vbGJhciBhcHAuICBJIGhhdmUgYWxzbyBwbGF5ZWQgYXJvdW5kDQp3aXRoIGFkZGluZyBhICJD
b250YWN0IiB3aXRoIHRoZSBjZXJ0aWZpY2F0ZSwgYnV0IEkgY2FuJ3Qgc2VlbSB0byBiZSBhYmxl
IHRvDQpkbyB0aGlzIHByb2dyYW1tYXRpY2FsbHkgLSBNUyBsZXRzIHlvdSBhZGQgYSBjb250YWN0
IHByb2dyYW1tYXRpY2FsbHksIGJ1dA0KdGhlIHBpZWNlIHRvIGFkZCBhIGNlcnQgaXMgbm90IGlt
cGxlbWVudGVkICh0aGVyZSBpcyBhIHZhcmlhYmxlIHRoZXJlLCBidXQNCk1TIGFkbWl0cyB0aGF0
IGl0IGRvZXNuJ3Qgd29yaykuICBNYXliZSB3ZSB3aWxsIGhhdmUgdG8gc3RvcmUgdmNhcmRzIHdp
dGgNCnRoZSBjZXJ0aWZpY2F0ZSBpbiB0aGVtIGluIGEgZGF0YWJhc2UgYW5kIGRvbGUgdGhlbSBv
dXQgdGhhdCB3YXkuDQoNCkFueWhvdywgbG9uZyBzdG9yeSBzaG9ydCwgZW1haWwgY2VydHMgc2hv
dWxkIGJlIGdvaW5nIG1haW5zdHJlYW0gc29vbiwgYW5kDQppdCBtYXkgZXZlbnR1YWxseSBiZSB0
aGUgYW5zd2VyIHRvIHNwYW0sIGJ1dCB0aGVyZSBuZWVkcyB0byBiZSBhIGJldHRlciB3YXkNCnRv
IGhhbmRsZSB0aGUgZGlzdHJpYnV0aW9uIG9mIGNlcnRpZmljYXRlcyBmb3IgdGhlbSB0byByZWFs
bHkgc3RhcnQgdGFraW5nDQpvZmYuDQoNCklmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBwYXJ0aWNp
cGF0aW5nIGluIHRoZSBwcm9qZWN0LCBwbGVhc2UgY29udGFjdCBtZSBhbmQNCmluZGljYXRlIHdo
YXQgeW91IHdhbnQgdG8gY29udHJpYnV0ZSwgdGhlIHByb2plY3Qgd2lsbCBuZWVkIHByb2dyYW1t
ZXJzLCBhDQpwb2xpY3kvcGxhbm5pbmcgYm9hcmQsIHdlYiBkZXZlbG9wZXJzLCBhbmQgb3RoZXJz
IHRoYXQgSSBoYXZlbid0IHRob3VnaHQgb2YNCnlldC4gIFhSYW1wIHdpbGwgY29udHJpYnV0ZSBz
ZXJ2ZXJzLCBhY2Nlc3MgdG8gYSBUcnVzdGVkIENBLCBwcm9ncmFtbWVycyBhbmQNCndlYiBkZXZl
bG9wZXJzLiAgKFByb2dyYW1tZXJzIGFuZCB3ZWIgZGV2ZWxvcGVycyBmcm9tIFhSYW1wIGFyZSBv
biBhIGxpbWl0ZWQNCmJhc2lzIGFzIG91ciBpbnRlcm5hbCBwcm9qZWN0IGxpc3QgaXMgcXVpdGUg
bG9uZykuDQoNCkkgbG9vayBmb3J3YXJkIHRvIGhlYXJpbmcgcmVzcG9uc2VzIHRvIHRoaXMgcHJv
amVjdCBhbmQgYW55IGlkZWFzIHRoYXQgeW91DQpndXlzIG1heSBoYXZlIGluIHRoaXMgcmVnYXJk
LiAgQWRkaXRpb25hbGx5LCBpZiB0aGVyZSBpcyBhbnl0aGluZyB0aGF0IFhSYW1wDQpjYW4gZG8g
dG8gYXNzaXN0IG90aGVyIHByb2plY3RzIHRoYXQgeW91IG1heSBiZSBpbnZvbHZlZCBpbiwgcGxl
YXNlIGZlZWwNCmZyZWUgdG8gYXNrLg0KDQpCZXN0IFJlZ2FyZHMsDQpTY290dCBIYXJyaXMNClhS
YW1wIFRlY2hub2xvZ2llcywgSW5jLg0KODg4LTkwLVhSQU1QICAoODg4LTkwOS03MjY3KQ0KMjEw
LTY5NS00MzQ1DQoNCmh0dHA6Ly93d3cuWFJhbXAuY29tDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogb3duZXItaWV0Zi1wa2l4QG1haWwuaW1jLm9yZyBbbWFpbHRvOm93
bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmddIE9uDQpCZWhhbGYgT2YgSm9zZXBoIERvZWticmlq
ZGVyDQpTZW50OiBNb25kYXksIEp1bHkgMTksIDIwMDQgNDoyMCBBTQ0KVG86IFN0ZXBoZW4gS2Vu
dA0KQ2M6IEVkIEdlcmNrOyBpZXRmLXBraXhAaW1jLm9yZw0KU3ViamVjdDogUmU6IFJlcXVlc3Q6
IFNlbmQgbWUgc2lnbmVkIG1lc3NhZ2VzDQoNCkludGVyZXN0aW5nIGlzc3VlLCB3aGljaCBsZWF2
ZXMgbWUgd2l0aCBhIHF1ZXN0aW9uOg0KVGhlIG9ubHkgdGhpbmcgYSBzcGFtbWVyIGNhbiBub3Qg
ZG8gKG9yIG1heWJlIG9ubHkgb25jZSkgaXMgZGlnaXRhbGx5IHNpZ24NCmhpcyBzcGFtISBVcG9u
IGFidXNlLCBUaGUgY2VydCBjYW4gYmUgcHV0IG9uIHRoZSByZWNlaXZlcnMgImJsYWNrLWxpc3Qi
LCB0aGUNCmNlcnQgY291bGQgYmUgcmV2b2tlZCBieSBDQSBhbmQvb3IgUkEgYW5kIHRoZSBJc3N1
aW5nUGFydHkgY2FuIGJlIGNvbnRhY3RlZA0KaWYgYWJ1c2UgY29udGludWVzLi4uDQpXb3VsZCBp
dCB0aHVzIG5vdCBiZSBhbiBpbnRlcmVzdGluZyBhcHByb2FjaCB0byBidWlsZCBhIG1haWwgZmls
dGVyIHRoYXQNCmZpbHRlcnMgb3V0IGFsbCBub24gZGlnaXRhbGx5IHNpZ25lZCBlbWFpbD8NCkl0
IGlzIGNsZWFyLCB0aGlzIGlzIHNvbWV0aGluZyBmb3IgdGhlIGZ1dHVyZSwgYnV0IGZyb20gYSB0
aGVvcmV0aWNhbA0KcG9pbnQtb2YtdmlldzogU29tZSBmZWVkYmFjayBmcm9tIHRoZSBleHBlcnRz
IG91dCB0aGVyZSB3b3VsZCBiZSBpbnRlcmVzdGluZw0KZm9yIG1lLiBJbiBvdGhlciB3b3Jkcywg
Y2FuIHdlIHRha2UgdGhpcyBhbnkgZnVydGhlcj8NCg0KQ2hlZXJzDQoNCkpvc2gNCg0KU3RlcGhl
biBLZW50IHdyb3RlOg0KDQo+DQo+IEkgdmlldyBQZXRlcidzIHNvbGljaXRhdGlvbiBmb3Igc2ln
bmVkIGUtbWFpbCB0byBiZSBhcHByb3ByaWF0ZSBmb3INCj4gdGhlIFBLSVggV0cgbGlzdC4NCj4N
Cj4gU3RldmUNCj4NCg0KLS0NCkpvc2VwaCBBLiBEb2VrYnJpamRlcg0KLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClN3aXNzU2lnbiBBRw0KTPZ3ZW5z
dHJhc3NlIDEsIENILTgwMDEgWvxyaWNoDQpUZWw6ICs0MSA0MyAzNDQgODggMTEgLyBNb2JpbGU6
ICs0MSA3OSAyMTEgMjQgNDYgd3d3LnN3aXNzc2lnbi5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBk
aWdpdGFsbHkgc2lnbmVkIHRvIGVuc3VyZSB1bmFsdGVyZWQgYW5kIGF1dGhlbnRpY2F0ZWQNCnJl
Y2VwdGlvbi4gU2hvdWxkIHlvdSByZWNlaXZlIGFuIGVycm9yIG1lc3NhZ2UgcmVnYXJkaW5nIHRo
ZSB2YWxpZGl0eSBvZiB0aGUNCnNpZ25hdHVyZSwgcGxlYXNlIGNsaWNrIGFuZCBkb3dubG9hZCB0
aGUgU3dpc3NTaWduIHJvb3QgY2VydGlmaWNhdGUgdXNpbmcNCnRoZSBmb2xsb3dpbmcgbGluayAg
aHR0cHM6Ly9zd2lzc3NpZ24ubgSBrWV0L3RydXN0LyBBZnRlciBpbnN0YWxsYXRpb24sIHlvdXIN
Cm1haWwgY2xpZW50IHdpbGwgYmUgYWJsZSB0byBhdXRvbWF0aWNhbGx5IHZlcmlmeSB0aGUgYXV0
aGVudGljaXR5IG9mIGUtbWFpbA0KbWVzc2FnZXMgc2VudCB0byB5b3UgYnkgdXNlcnMgb2YgU3dp
c3NTaWduIGNlcnRpZmljYXRlcy4NCg0KAAAAAAAAoIIPqTCCA3UwggJdoAMCAQICCwIAAAAAANZ4
t5QFMA0GCSqGSIb3DQEBBAUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52
LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNOTgw
OTAxMTIwMDAwWhcNMTQwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFs
U2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENB
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3Oo+NPin778YuDJWvqSB/xKrC5
lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsurHExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu
9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8GPIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW
3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounICjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGr
CVNukM57N3S5cEeRIlFjFnmusa5BJgjIGSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKf
f5OQzwIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAAYwHQYDVR0OBBYEFGB7ZhpFDZfKiVAvfQTNNKj/
/P1LMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADggEBAK6qn/y30ssfXzkpKBieNMls
T28a8GSicEpPE4abYCie6IFJmH0Ku+WwnT02248FUf8JMSof3Yl3ng8ubJUE7YbLtAA/hAJNgGoq
LXgLrm8rooNEgx/NUIJMJK+996W0yFoP9OdHXkmON5b+mogFOtnA2ymH5hmWR6c6poyLPHf+RmOn
U9oh0ax+SaJL5sNnWS+zig67LL2pqkJ8NcHYf9WnMTpOY0M5rwiwYTSM05ipQzT2D4cpO53CVliY
d8P3G6z2nfg+qqdURfD1+dUxZf5rWJxxsx7XUuoyF/xAYB3JeSSy9mz9qGYOgt2Yy9rCRE8uoHvy
92ssdhGERop4o+MwggPnMIICz6ADAgECAgsEAAAAAAD5f6ouHjANBgkqhkiG9w0BAQUFADBXMQsw
CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEb
MBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTAzMTIxNjEzMDAwMFoXDTE0MDEyNzExMDAw
MFowcTEoMCYGA1UEAxMfR2xvYmFsU2lnbiBSb290U2lnbiBQYXJ0bmVycyBDQTEdMBsGA1UECxMU
Um9vdFNpZ24gUGFydG5lcnMgQ0ExGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExCzAJBgNVBAYT
AkJFMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve8w8TDxNKmJZXdNRqeNkP2uT47K
KBe6WeOokgpFAyqKj+UJUFVSgfCjkbHZEiqB9sIDHDyCwHLN8acA1/VUnApH7pqVQZKOoK0JPdPr
onStnxkgCbZ9pl41n085agO1iq0flmJrF7mrh2DVXW3ZksnQE67UiNlQqESRBLDqR+pfsu0EwdcB
fCH4xHEj/GtMZUQzw40d5tJmHFIpRsQG5ws18FkBZgCJz5zje3iqU+LurDWV5/1d10KUldMabjFV
R9frrcdMn1RxgxoXyPnnzlgB9Da/rj9Zn2V8QAdccyA0ohLDSfRoQGkeieCF6Tq3l2O7R7A5a0EA
fvVLuH/jIQIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud
DgQWBBRWhOy1caXnY9jbUQTW+ubwSFJJzjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmds
b2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaAFGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0G
CSqGSIb3DQEBBQUAA4IBAQBcLy5nSiaz57U/NTzdoAPtVpr5RDdSFjBlx9FOog+Nt7a2Z47nTOyN
lb7mzqcieHSs1/h0mbP3zosTONWWzI12xS84sjquYb4Lh5njIWJkIzmNhPaFjfd3/7A4BvB+wUhf
te5YJgZmBSJ0koOn27X5kuPowxksLmPvux/f+fcHR2YNB4mXfvgzLJ7LrhQ98Rzfo/F5r8iSj5Rx
xNFExVTbHrULCqlCo6/WQzkd7o+TmFhbvm6cC/Vj7F6ZwvlU+gEHRtoNsGQkz47RBh1PPKJjd0Vb
pLxfsIC7MeALVAFcFh1yTtUqaUfRG2Z+XwFu8TWRa+Au/rBF2BYntcWLwtpTMIIEDDCCAvSgAwIB
AgIKfKQP3gAAAAAF6jANBgkqhkiG9w0BAQUFADCBkTELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBVRl
eGFzMRQwEgYDVQQHEwtTYW4gQW50b25pbzEOMAwGA1UECxMFR1MgQ0ExJDAiBgNVBAoTG1hSYW1w
IFNlY3VyaXR5IFNlcnZpY2VzIEluYzEmMCQGA1UEAxMdWFJhbXAgU2VjdXJpdHkgU2VydmljZXMg
R1MgQ0EwHhcNMDQwNDA5MjExMTQ5WhcNMDUwNDA5MjEyMTQ5WjCBjTELMAkGA1UEBhMCVVMxDjAM
BgNVBAgTBVRleGFzMRQwEgYDVQQHEwtTYW4gQW50b25pbzEhMB8GA1UEChMYWFJhbXAgVGVjaG5v
bG9naWVzLCBJbmMuMRUwEwYDVQQDEwxTY290dCBIYXJyaXMxHjAcBgkqhkiG9w0BCQEWD1Njb3R0
QFhSYW1wLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzP2qtvPX0qnTIHsvsHox0TRY
5vuhx6/77MqoD4iEYVp4Zmey71lBvFe8nrXFwTQUtrl/S8iBS6Cn1oXyVea3NlWgqkI6lriHxQ1C
1kWfPUL+zfEgsXdjx9I80dJGfnP9hjjn/KtRs8v6YFddAXbhax/EWt83hXrwQK1TcCs9sjECAwEA
AaOB6zCB6DAOBgNVHQ8BAf8EBAMCBPAwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAw
DgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBQf+NR5JpQ/MUDn
/NM+Hy4ixsLZtDATBgNVHSUEDDAKBggrBgEFBQcDBDAfBgNVHSMEGDAWgBSeH6VOTvHoSAQQ8/1t
bwoGr//HOzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLnhyYW1wc2VjdXJpdHkuY29tL1hS
YW1wR1NDQS5jcmwwDQYJKoZIhvcNAQEFBQADggEBAHouQ+vfoX9OlwXvnI5AIo2LZ0Ns9FDaE1Py
5B8oBj8Qsfd343/5SqG8lPGugZXBsFFokvm7961zaqkydYkGpTkOwzoqN2iYcYAfON69SlHLHtFs
NVQKlo3IUYSTovDmX/cxFeVLT/petV0NGqYF7gOOowTSqAnZIT9oVnYMFX/nQ9WWCr5cRYAMIveE
GuABQooGOjgHUiMxpK2kaGtwbLlrPyObYkyOITulrdB1gDN2suVmZe4Sq/uoe06r5llOG8uMf/zJ
4r/x5Jj0eTEkTN7iw85SIKS7xghk1dzY8kKqEX8Sy588gmwUBJKfFC399l5M2jmrONZM3Dg2TXX5
R3gwggQxMIIDGaADAgECAgsEAAAAAAD5f8YjKTANBgkqhkiG9w0BAQUFADBxMSgwJgYDVQQDEx9H
bG9iYWxTaWduIFJvb3RTaWduIFBhcnRuZXJzIENBMR0wGwYDVQQLExRSb290U2lnbiBQYXJ0bmVy
cyBDQTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTELMAkGA1UEBhMCQkUwHhcNMDMxMjE2MTQw
MDAwWhcNMTMxMjE2MTQwMDAwWjCBkTELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBVRleGFzMRQwEgYD
VQQHEwtTYW4gQW50b25pbzEOMAwGA1UECxMFR1MgQ0ExJDAiBgNVBAoTG1hSYW1wIFNlY3VyaXR5
IFNlcnZpY2VzIEluYzEmMCQGA1UEAxMdWFJhbXAgU2VjdXJpdHkgU2VydmljZXMgR1MgQ0EwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiuD+bhQX0A4z92419hSIstqoMYI4PaD2L5f4f
yWzvDPT3WohDXbyJltBN0sTbrtjD3574pZXa0TEOVB/cMHe8I3xsjpilFhBpBMPDBgU+6+aTPsb0
5d/Ao2VAt3r/psj98tmwE0+Ng/LBrMLhiv3Qj5EW0wQqbhsdODeNDVmM5yMyZAguF8duskI667SM
8CVNQMpEF71pNPs851mVP8xKHpM7uyQBwHi0hLswaDaEcJuRL701t3ZmLNlMTtnaTMxWP8SuatF9
TeTko6/nWE4707o1FDtxn6xp8ReR3+nHffg1WSc+GZwvtXNK31zZeCNctr6R4Q6VIZwbSIxjDB7F
AgMBAAGjgagwgaUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYE
FJ4fpU5O8ehIBBDz/W1vCgav/8c7MD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwuZ2xvYmFs
c2lnbi5uZXQvUm9vdFNpZ25QYXJ0bmVycy5jcmwwHwYDVR0jBBgwFoAUVoTstXGl52PY21EE1vrm
8EhSSc4wDQYJKoZIhvcNAQEFBQADggEBALcBJaUFHLyJFOtXqvfnKh+L1eat3lnq7taPdL7V3prH
BPxxIJDyKPVYiwD5w9/eFtYn6b+a9RhIWilxL3lc+zZYt3OuphmJmrrmEOIAg6JvsKmjIesqRY6H
iKCw5MLS5VxIZCgOERIdoIRVLTdkRhcKAWsp1TZkWLHaZDdBr6SLl6P0wtCxitj7asf7kEeEamHe
SNoM5urDtwkF0PQ1jLxyVNg8SEpMSPW64VO1gcGUKWuzsQlWH1mp4b/FGAjnXcGwBwiuN8RmfG4l
Efbw5bMYts+Adxop8EN0psDo+PVB8L+LAabZAtWTyJkHK/thLvDhlpdtpoDQs3ZeHoA2fhExggNs
MIIDaAIBATCBoDCBkTELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBVRleGFzMRQwEgYDVQQHEwtTYW4g
QW50b25pbzEOMAwGA1UECxMFR1MgQ0ExJDAiBgNVBAoTG1hSYW1wIFNlY3VyaXR5IFNlcnZpY2Vz
IEluYzEmMCQGA1UEAxMdWFJhbXAgU2VjdXJpdHkgU2VydmljZXMgR1MgQ0ECCnykD94AAAAABeow
CQYFKw4DAhoFAKCCAiEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MDQwNzE5MTU0NzQwWjAjBgkqhkiG9w0BCQQxFgQURSDflsVAkBprQkNgxb3HimRdj48wWAYJKoZI
hvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgbEGCSsGAQQBgjcQBDGBozCBoDCBkTELMAkGA1UE
BhMCVVMxDjAMBgNVBAgTBVRleGFzMRQwEgYDVQQHEwtTYW4gQW50b25pbzEOMAwGA1UECxMFR1Mg
Q0ExJDAiBgNVBAoTG1hSYW1wIFNlY3VyaXR5IFNlcnZpY2VzIEluYzEmMCQGA1UEAxMdWFJhbXAg
U2VjdXJpdHkgU2VydmljZXMgR1MgQ0ECCnykD94AAAAABeowgbMGCyqGSIb3DQEJEAILMYGjoIGg
MIGRMQswCQYDVQQGEwJVUzEOMAwGA1UECBMFVGV4YXMxFDASBgNVBAcTC1NhbiBBbnRvbmlvMQ4w
DAYDVQQLEwVHUyBDQTEkMCIGA1UEChMbWFJhbXAgU2VjdXJpdHkgU2VydmljZXMgSW5jMSYwJAYD
VQQDEx1YUmFtcCBTZWN1cml0eSBTZXJ2aWNlcyBHUyBDQQIKfKQP3gAAAAAF6jANBgkqhkiG9w0B
AQEFAASBgArdRnMLEDCDgUIb5peomrdeacCUy8QsY1fYZvoVrNPIgZtFeOdCthPSmWIerXABqLq/
RH353C6c1FSYwnEU0PwED5SvEenh+tXVawJwjdk5oMarqU90gxaTzWkpAi/RVsHADDeSQuCGSPXu
5ipTwtNLgPzc5lUM/+9LgFoJg2BfAAAAAAAA



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JDNfo0058916; Mon, 19 Jul 2004 06:23:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JDNfge058913; Mon, 19 Jul 2004 06:23:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JDNeQl058899; Mon, 19 Jul 2004 06:23:40 -0700 (PDT) (envelope-from [e-mail])
Received: from pengo (extra1.izecom.com [195.64.86.233]) by smtp-vbr1.xs4all.nl (8.12.11/8.12.11) with SMTP id i6JDNcB2002686; Mon, 19 Jul 2004 15:23:38 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <4.3.2.7.2.20040719151703.01558ec0@localhost>
X-Sender: [e-mail]@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 19 Jul 2004 15:19:57 +0200
To: [e-mail], [e-mail]
From: Christine Karman <[e-mail]>
Subject: Re: Request: Send me signed messages
In-Reply-To: <[e-mail]>
References: <4.3.2.7.2.20040719124821.0280f818@localhost> <[e-mail]> <[e-mail]> <4.3.2.7.2.20040719124821.0280f818@localhost>
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="{39DCBED5-7FEB-4056-8C10-05B4D010B916}"
X-Izemail-Send-Version: 1.4.1.516 (POP3)
X-Virus-Scanned: by XS4ALL Virus Scanner
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--{39DCBED5-7FEB-4056-8C10-05B4D010B916}
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 03:13 PM 7/19/2004, you wrote:

>Um, the cert tends to have your (valid) email address in it.

Peter already has my email address through this list, so why shouldn't I 
send him my certificates?

dagdag
Christine
--
Izecom BV
Secure e-mail and digital signatures
www.izecom.com

if your outlook can't reply to a signed message, go to 
www.izecom.com/reply.html

--{39DCBED5-7FEB-4056-8C10-05B4D010B916}
Content-Type: application/x-pkcs7-signature; 
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIJ/rwYJKoZIhvcNAQcCoIJ/oDCCf5wCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCfVAw
ggH6MIIBYwICAaMwDQYJKoZIhvcNAQEEBQAwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBD
b3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdDAeFw05NjAyMjMyMzAxMDBa
Fw0wNjAyMjMyMzU5MDBaMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24x
HDAaBgNVBAMTE0dURSBDeWJlclRydXN0IFJvb3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
ALjmT7rbmHxxfK9Et9MPRtlk5ZPBQo7HukmNNS1654u95QUxWcaxLwoM+5+nP6IJZoRWHjcpG4fp
fgzKmp+lf/UVlKPVokaC2GhM0TcVBmivvfiws/Ap9ZVaCRZhdwoiJdRPRarHveWW3/nUqI5CzCTA
HpEnSrVtBoBjOcSiXjgDAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAErN1xl8d4WFVgADUgUt7MQ8j
Y+c98wP59Daou9njpZdN6isp4NZqc4HmwImj0/HgpaUiN5pjwkggtNty48j22Xy+sa9T2hS0IbjW
1Zbj/k4MWWK2mkr5Qt2Mb4Gpcf/0CnJtbUQOnfN0dKjVNEnpXp7ptHrh5VofhDCc05+lJdgwggH6
MIIBYwICAaMwDQYJKoZIhvcNAQEEBQAwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jw
b3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdDAeFw05NjAyMjMyMzAxMDBaFw0w
NjAyMjMyMzU5MDBaMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAa
BgNVBAMTE0dURSBDeWJlclRydXN0IFJvb3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALjm
T7rbmHxxfK9Et9MPRtlk5ZPBQo7HukmNNS1654u95QUxWcaxLwoM+5+nP6IJZoRWHjcpG4fpfgzK
mp+lf/UVlKPVokaC2GhM0TcVBmivvfiws/Ap9ZVaCRZhdwoiJdRPRarHveWW3/nUqI5CzCTAHpEn
SrVtBoBjOcSiXjgDAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAErN1xl8d4WFVgADUgUt7MQ8jY+c9
8wP59Daou9njpZdN6isp4NZqc4HmwImj0/HgpaUiN5pjwkggtNty48j22Xy+sa9T2hS0IbjW1Zbj
/k4MWWK2mkr5Qt2Mb4Gpcf/0CnJtbUQOnfN0dKjVNEnpXp7ptHrh5VofhDCc05+lJdgwggI9MIIB
pgIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTI4MDgwMTIzNTk1OVowXzELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0fzGVuDLDQVoQYh5oG
mxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHiTkVWaR94AoDa3EeRKbs2yWNcxeDX
LYd7obcysHswuiovMaruo2fa2wIDAQABMA0GCSqGSIb3DQEBAgUAA4GBAEw/uIvGaN/uQzMOXemm
yweETXoz/5Ib9Dat2JUiNmgRbHxCzPOcLsQHPxSwD0//kJJ2+eK8SumPzaCACvfFKfGCIl24sd2B
I6N7JRVGMHkW+OoFS5R/HcIcyOO39BBAPBPDXx9T6EjkhrR7oTWweyW6uNOOqz84nQA0AJjz0XGU
MIIDYjCCAsugAwIBAgIQC9oLF8E/iY6rCXR6tM4uMzANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFBy
aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1
OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k
aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lI
E1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zG
mo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaOBsDCBrTAPBgNVHRMECDAGAQH/AgEAMEcG
A1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w
Y2ExLmNybDALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GB
AAJ9nm9FSziguN7pU2QhvORMK48e/pJArNgKOWqhMiEsB5urWf7SYhp9VTiwN3Pc9AdmY2K94VNw
UofnqNhS6VstquHez6wxVNSLGcjYI6jvBCsyfSwYHMh8iagud/JE0WUKTXS17tMbknN0Lok7NRNy
50AxmtOyxKvnVr6L4/sVMIIDgTCCAmmgAwIBAgIRAK9oyzx6IyABA/lsASJjcVowDQYJKoZIhvcN
AQEFBQAwgYMxEjAQBgNVBAoTCUl6ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWls
LmNvbTEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQG
EwJOTDETMBEGA1UEAxMKSXplbWFpbCBDQTAeFw0wNDA3MDIxMzI1NThaFw0wNTA4MDkxMzI1NTha
MGwxCzAJBgNVBAYTAk5MMRIwEAYDVQQHEwlBbXN0ZXJkYW0xEDAOBgNVBAoTB2l6ZW1haWwxIDAe
BgkqhkiG9w0BCQEWEWl6ZW1haWxAeHM0YWxsLm5sMRUwEwYDVQQDEwxpemVtYWlsIHVzZXIwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALUhMm9LUQrLi84yO6NkKaR61aqySUIjs8YIyZfkqMmP
zj5akgD6pGs0lT45iiEiq54gsqjQM/i2z/ewq67L7elOpE5q2au4Qbw99u10QNPuk/o1EEOFcuNC
ybnYib4YfZP7ZDjK+1lDELtiJEsXIZDEDPHBsZoHefaXPOSiRF6tAgMBAAGjgYkwgYYwCQYDVR0T
BAIwADA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8vd3d3Lml6ZWNvbS5jb20vaXplbWFpbC9pemVt
YWlsLjEuY3JsMBwGA1UdEQQVMBOBEWl6ZW1haWxAeHM0YWxsLm5sMB0GA1UdJQQWMBQGCCsGAQUF
BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQUFAAOCAQEAVAzoUYQrRYeIqkp9RMvUtah7JYIv/dLb
LOHfzUSCl69ZsE5ViKgXiHZZnbCE7CmenF/uIr4/zhgHD8refpBMrA2w10adrHsDV2CJTYhJ5XmX
r++5454iqCIG3EJ6C4sDWo9S685iF+rv7tpWUim+zmhbcHcLLp9pJ4u7tQz+Zs9Rj4CdbXpeUA8Y
RES4ahyw9rjUAs3aRXTxFUFrEFOrmM0UnXz9HjDeNTjHpFLS14jwXP/ymN8YaDzXaP06nTHSHiP/
BMnkBHgRtAIpVUzpCdO+BP61E9QEJ2KIgGZWveQWHvZB3stwVYPTmkICPAu0V7faiKwGY/feO+UR
P38XyTCCA4QwggJsoAMCAQICEQDKIGQhZRNna+i/El4nuWG0MA0GCSqGSIb3DQEBBQUAMIGDMRIw
EAYDVQQKEwlJemVjb20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFpbC5jb20xFjAUBgNV
BAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxEzARBgNV
BAMTCkl6ZW1haWwgQ0EwHhcNMDQwMzEyMTQwMTI0WhcNMDUwNDE5MTQwMTI0WjBrMQswCQYDVQQG
EwJOTDESMBAGA1UEBxMJQW1zdGVyZGFtMRIwEAYDVQQKEwlJemVjb20gQlYxHjAcBgkqhkiG9w0B
CQEWD2luZm9AaXplY29tLmNvbTEUMBIGA1UEAxMLSW5mbyBJemVjb20wgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBAO1S2s95QBpWP86MDekCIQqu9WjXTurDRV/qgq5Dx7ZjuJlrO+NlRRGM/JjS
OqZ0gAq14PSUm5HZfaorxANZxuw+g6+rd5kTUZZcWKca3yt+zc3h+xkF+AIrbcYAMxHSjYZP6SvN
sFn8TV1wcwRgo3GVxR1uUiXNJoBz44JSmqFDAgMBAAGjgY0wgYowDwYDVR0TBAgwBgEBAAIBADA8
BgNVHR8ENTAzMDGgL6AthitodHRwOi8vd3d3Lml6ZWNvbS5jb20vaXplbWFpbC9pemVtYWlsLjEu
Y3JsMBoGA1UdEQQTMBGBD2luZm9AaXplY29tLmNvbTAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYB
BQUHAwIwDQYJKoZIhvcNAQEFBQADggEBAFt+s913of0Jm1T5Pw1Tyw6voXR0dYCW+aoXfjasJKPN
K0fIqo5QZPZpZj4XZ2mOaJfztu55xg8hojMrmragzJgArWcGqmM1HRrUjlr4QKbn0HmC7gwVp/g2
b187mWu9CIBHFmhyHxOSx6JsgX2ORXJYu+JL3sa5rLiK6iNzVNjN/aSlzQNdZaUxZ2WRq1p/7BWC
jP9zPN/bLhgP1nE5uTF2vQ1scvMn2J5Gt575FYeN9Xm59D1/Eu59q/I248AhR3gqrnS7u/ky+zVs
I0pp0q5RXHZDa5PlmuMNFef5CwbKere6hQSZ5GP2MWtPoHZvipfqvurM7/XMEP/VtH8ZlzgwggOH
MIICb6ADAgECAhAWMW7s5NRjM+GG8hzGoth4MA0GCSqGSIb3DQEBBQUAMIGDMRIwEAYDVQQKEwlJ
emVjb20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFpbC5jb20xFjAUBgNVBAgTDU5vb3Jk
LUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxEzARBgNVBAMTCkl6ZW1h
aWwgQ0EwHhcNMDQwNzA1MjA0NjEyWhcNMDUwODEyMjA0NjEyWjBxMQswCQYDVQQGEwJOTDEPMA0G
A1UEBxMGSHVpemVuMRIwEAYDVQQKEwlaYXBob2QgQlYxIjAgBgkqhkiG9w0BCQEWE2NocmlzdGlu
ZUBrYXJtYW4ubmwxGTAXBgNVBAMTEENocmlzdGluZSBLYXJtYW4wgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAKcx2YA0uKM0aXWukpbfrLj3ird+UNKTcpnG6h9ZncOOt3ZWfc7fZpEhNC8dFjk2
meJeenNVjwfqeRuZCCmIROfYpyLl2s7GENUPoqo6lKjaYtU6O8GlLOY850BDv880vs8SzavmzbkH
QOd/mO8NTmObAnjdAzJJiGJ4ywF1/Yh5AgMBAAGjgYswgYgwCQYDVR0TBAIwADA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vd3d3Lml6ZWNvbS5jb20vaXplbWFpbC9pemVtYWlsLjEuY3JsMB4GA1Ud
EQQXMBWBE2NocmlzdGluZUBrYXJtYW4ubmwwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MA0GCSqGSIb3DQEBBQUAA4IBAQAorgNK9BiyU48AcCw/ywgHuhkkhZ2LvFo+DE1GJdufaAcb6Ko4
5tqCLQcIZNlLdX5zBH5uuPVaV7i9nkOk8A3dech2Zdv0V/3yfsFyHy8DUdmiH66qezEKwUkLZo4R
oGT/Yi+FRxdUtMgek56YBhWlqCaXqZwUchbMfUN4WzV6fN159x2zhc6Uv+ktFnILLcNKvOpCCy+M
5yDOeq6aiG0KOpuxy0ZiXPF3LHKEkBsdfSkzokFd9xda3vGVFa3e7gSCUv7QrYJdHIRtlq5nszi9
8DYudJsBfkLOizWNn8F85XMb0yHBAyDTIO2Z+NcHhlMOy2XbvtmwxP3IEDcy1j8AMIIDjjCCAnag
AwIBAgIRANv4dRuNkzqiKDNkv8sV0R0wDQYJKoZIhvcNAQEFBQAwgY4xEjAQBgNVBAoTCUl6ZWNv
bSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYD
VQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSgwJgYDVQQDEx9JemVtYWlsIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MB4XDTA0MDExOTE2MTc1NloXDTA1MDExMTIzMDAwMFowaTELMAkGA1UEBhMC
TkwxEjAQBgNVBAcTCWFtc3RlcmRhbTENMAsGA1UEChMEbm9uZTEhMB8GCSqGSIb3DQEJARYSWDEw
X19fQGhvdG1haWwuY29tMRQwEgYDVQQDEwtXZW5keSBXZWJlcjCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEAtTPyFNVgiHFXAeq3A1IB+QjHq1VffIS4loWiGAguoEKZD37WLpK7wjuBaN2ful4F
p99ORUSXlP3DRwJH2XnVwJAaGlHYz/k05nLS+XAP/Sy/hivYi6M+Am+IpDM4sYhZsRp7dofwUclJ
NUjWrHAWN2R4EHiTQWxBQSV8A/zRrBECAwEAAaOBjjCBizAPBgNVHRMECDAGAQEAAgEAMDoGA1Ud
HwQzMDEwL6AtoCuGKWh0dHA6Ly93d3cuaXplY29tLmNvbS9pemVtYWlsL2l6ZW1haWwuY3JsMB0G
A1UdEQQWMBSBElgxMF9fX0Bob3RtYWlsLmNvbTAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUH
AwIwDQYJKoZIhvcNAQEFBQADggEBABhGlLSdO5r0yl9prOweu3krWAZA5obMTSkWA0azKR/2u2OW
5+8TS4CsLEQ2+I7iza1C7Qz62fuc+mcLBRGW0Zc5h0htbY50noAJhrWAmWHPcJtB6xVmyNg2T5m8
0WE2xujRWFPeoj1ZeOzcuWoVeuTpxqgO/t1i1JJgYDsYCSMRdVE0ZkwP0THl3P+WnAiDJog2y3ai
N+CaVKrmKxlNdTr+5Hj3QKSf78MwDN62cjV4LMBa1YK2QhhsfeQWKW7Tq6RAZPaSbyzmncmBmj10
x+MtbiyElMc0PY0V1x4VoUvdIrAOZnjUkb8rgsIhqWDFf54oG3/L1X7lD2pj0qOwdyUwggOQMIIC
eKADAgECAhEA8bb9H6pp50jmGkQbFyVs8DANBgkqhkiG9w0BAQUFADCBgzESMBAGA1UEChMJSXpl
Y29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMRYwFAYDVQQIEw1Ob29yZC1I
b2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMRMwEQYDVQQDEwpJemVtYWls
IENBMB4XDTA0MDUwNDE1NTUyOFoXDTA1MDYxMTE1NTUyOFowczELMAkGA1UEBhMCTkwxEjAQBgNV
BAcTCUFtc3RlcmRhbTEQMA4GA1UEChMHaXplbWFpbDEiMCAGCSqGSIb3DQEJARYTbGljZW5zZUBp
emVtYWlsLmNvbTEaMBgGA1UEAxMRSXplbWFpbCBsaWNlbnNpbmcwgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBANtw+PIWiwmBSgp7DOdw7fV12nHM9DvzhyK3SGnnsVIL7qCz64vyLc+MVYV/aTxV
qu0j7s+uxmFyR36wwPjAdJnvOSyVd9cB0ZKByzAbgKhWfVUiEt7NhC0HDXa7yxMll8JvV1OIM13c
aVKD6stM/n84abjKH+AIniYP2EKNDaPxAgMBAAGjgZEwgY4wDwYDVR0TBAgwBgEBAAIBADA8BgNV
HR8ENTAzMDGgL6AthitodHRwOi8vd3d3Lml6ZWNvbS5jb20vaXplbWFpbC9pemVtYWlsLjEuY3Js
MB4GA1UdEQQXMBWBE2xpY2Vuc2VAaXplbWFpbC5jb20wHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsG
AQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBAQBeOiT+ZsP/fivt9J8ADDvSvTIGXuja4HuwUFZQGg70
FUkccBVedgGQPspfWwK61IJilCrjGiHzTcVKdbDEuX0hSuMjU0tZ1qQI6LRJjNOsS9+ui8KegxYL
GY4YwIlXCKYwslxDZKH5eFtN9GLZ/MiA4630uciywMO015bepJtNiGy/LPfDZuRFvEm2RLGp5Gk4
jh9v9o45rbnAdQh9EWQ0JkNxxNkjpxPqCMZ1Q9r8jVtUlXaxg2jyTgUniKX6Hsc6YQykB3wlAAsV
eiitoAK4FFlXvIAXzx85QbvARXX+sfpekrCb4WwZ7DkQqHeG2yMXmsiP2IBAcXhhJX84EihfMIID
kjCCAnqgAwIBAgIQTFu6Av1P0TWBAjiHCtoWWTANBgkqhkiG9w0BAQUFADCBgzESMBAGA1UEChMJ
SXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMRYwFAYDVQQIEw1Ob29y
ZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMRMwEQYDVQQDEwpJemVt
YWlsIENBMB4XDTA0MDUwNDE0MDQyOFoXDTA1MDYxMTE0MDQyOFowdDELMAkGA1UEBhMCTkwxEjAQ
BgNVBAcTCUFtc3RlcmRhbTEQMA4GA1UEChMHaXplbWFpbDEkMCIGCSqGSIb3DQEJARYVY2hyaXN0
aW5lQGl6ZW1haWwuY29tMRkwFwYDVQQDExBDaHJpc3RpbmUgS2FybWFuMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDO3icNfM1EKNiU3Gkhy8AJXObNtWRtop78Yqpxr/KoHEvjQlLW2g6SQ7Qn
xvPS5EV7kjda/nkpRTknyVLSy9zzPEYZ0LTpjjYEnLI0//QEK6MyKRdQmilz+Q+avnGDSFIG9O8f
MLVZZenTibAV3EZXF+mQ3dIExe9fVgwDYLEXtwIDAQABo4GTMIGQMA8GA1UdEwQIMAYBAQACAQAw
PAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL3d3dy5pemVjb20uY29tL2l6ZW1haWwvaXplbWFpbC4x
LmNybDAgBgNVHREEGTAXgRVjaHJpc3RpbmVAaXplbWFpbC5jb20wHQYDVR0lBBYwFAYIKwYBBQUH
AwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBAQB/k/ue+oOkz3q1h4c1Ijbv0tfo6kfGc3XG
CIcvG4s8RC/QohqrTQJ5BM/w4YtufKchQIR/mp8yY2l67F8V2pdr5FXxsX59pwb451NZ+crkWA7e
lG95WxBT+i8fAhwS1SErVhOt3bMO/0m7eN2Z70sQ4eqFfl1rhbhD9X4VEXavvCfW9GtwP5aSDbuu
wro2eQP5mQVn5dPCpHl6kAzFrPiSou+1MGiV+Gox7JTogbni3N7GylM9mhWn/+2cNok2i17PuDNt
Qf8NjPCYQ8WPJXto3XOZXszWY5qYHPoQcZHl9QYivYQioIlpmLN0dTurKJuE7Hy+O4BKex0djPkx
eVn6MIIDmTCCAoGgAwIBAgIRAKeR0C5POj1DS7I/H+1RU4wwDQYJKoZIhvcNAQEFBQAwgY4xEjAQ
BgNVBAoTCUl6ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNvbTEMMAoGA1UE
CBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSgwJgYDVQQDEx9JemVtYWls
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMDkyOTA5NTYxM1oXDTA0MTAwNTA5NTYxM1ow
cjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCWFtc3RlcmRhbTEPMA0GA1UEChMGaXplY29tMSMwIQYJ
KoZIhvcNAQkBFhRjaHJpc3RpbmVAaXplY29tLmNvbTEZMBcGA1UEAxMQY2hyaXN0aW5lIGthcm1h
bjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvMeT43uZD+4Iuo3WHApeGdDHkMds8EUJopnw
t6CGb8RvOA57/Jj7DPaSEJ7sYzSaG7/hs0EkAJP22glMdvF/HWWOXIwfCRlgJQuuV18xlhidrvnH
PC7id+ZF2llKYOpPMgYgmD0TPAkZrC/a/be2LrdGEo4LOZ1Lv8A5oBEpCbMCAwEAAaOBkDCBjTAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDwYDVR0TBAgwBgEBAAIBADA6BgNVHR8EMzAx
MC+gLaArhilodHRwOi8vd3d3Lml6ZWNvbS5jb20vaXplbWFpbC9pemVtYWlsLmNybDAfBgNVHREE
GDAWgRRjaHJpc3RpbmVAaXplY29tLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPCwtn5fWFkkulP1Q
cr4Csh3/dOX0MSdea9ytcZSyt3qHuPXtohTjLDIgs06dUfFUixg84cmCTUz6J0VQ+X5iLsTWLSqs
nLgAMnGkoi74P1NpF14Hc7lRwUFvZeAlrZfR95DOIZut9FjSUSkzSb+l93rf8VMvwLf8Vw094ebY
xSYHLnftzarEYzaKurmEbxE88awii4/zy0O5SNjL55uhssF10DNRiXA480XG+xknI4l37AbWrmSh
CQ2tG6Cn1LRk+gmAMZSIHIkLUpBvuCCH/jlH3hrmQPJ4QPxnyJMsoFD4sQfwpAGGDhbxhxZlROLt
iLRl0fHaOpdnF6cWL7VWPDCCA5wwggKEoAMCAQICEQD9iPEGreUnKhViN1t47Me5MA0GCSqGSIb3
DQEBBQUAMIGDMRIwEAYDVQQKEwlJemVjb20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFp
bC5jb20xFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UE
BhMCTkwxEzARBgNVBAMTCkl6ZW1haWwgQ0EwHhcNMDQwNzAyMTMzOTExWhcNMDUwODA5MTMzOTEx
WjB7MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQW1zdGVyZGFtMQ8wDQYDVQQKEwZJemVjb20xLDAq
BgkqhkiG9w0BCQEWHWNocmlzdGluZUBleGNoYW5nZS5pemVjb20uY29tMRkwFwYDVQQDExBDaHJp
c3RpbmUgS2FybWFuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCoZ5kxMcLcP7Y+HaLur1Tr
JI3taGLC8AyMkhqJEnkqAjKZdNrOaz6UvcLk8kS1oDh8IfqydERMqc3YqA7r0Je+Sx4yF2vhJz1x
sD+lFoudDCYaFc2trCn1KeJZLlCZhp5Ahgx0F7bYz/y5cXaAqUAUzXjKE8ShIEt4JI0NeJHHMwID
AQABo4GVMIGSMAkGA1UdEwQCMAAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL3d3dy5pemVjb20u
Y29tL2l6ZW1haWwvaXplbWFpbC4xLmNybDAoBgNVHREEITAfgR1jaHJpc3RpbmVAZXhjaGFuZ2Uu
aXplY29tLmNvbTAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQAD
ggEBADuKmNoozkq4RkR2lHw/FpOQGOijr/i1YkHtngXh9IPGxLxRhRbL6eKA4/y+5fLO1GqtHTiz
TQehu88l6EboqRcLySNxiLgg7M8QpO29L9EfJ6e3B+WWVtrBYWSzWoGQmOs7xcQd2NdYglByDe1Y
35YjLnXwXrjtj2SQ/T5KNTkZ15SIQ1e6FSDHvkz7qRj1FVEh/OKZt1msNaZV+wEF/J1HShlEewSK
kDbRNdtzHn+w9WDZhZ7dyrINQnDegkpYzCy4BlT9rZ3ks4APrgUcw2pO9XSgpNoOYqX20eHygJ/k
gWpmmwvUcIzPV5Hbgk1zqhYGg+Dj7f7I82lYWiPOy/swggOrMIICk6ADAgECAhEA9+XuYyRdDqQq
pEhPtyq8FzANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcN
AQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQsw
CQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDMwMTI5MTYyMDQ2WhcNMTYwMjAyMTYyMDQ2WjCBkTESMBAGA1UEChMJSXplY29tIEJWMR4w
HAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1z
dGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQD1d6FaoPQAryNJ6kaXmYym
fctZb3fQ9evlG1yQ/9G1UC7TxMg4CQgu+XHlKObac6pt1hQdq8hGAwujIjSBofy8og2LEsOBv++C
1NVCR3T2T5UYg4n+OrjQ+9ZDgFVEiZ3/SZsxiAB4+EVJCuBF8AuF3R76k3B4EQ7kaD45iQSUZTp/
kH5wfcseIyF8nskQkoaMwewUYYMCn+N5BNwr2JyoKD42pH8VP/HDp6Hfm5zEvkDviEW+iDTq7ybk
wA4HZjtFPY08cChjLdYJ1h5JmZZidBrQZGfRYEK959B20vqYKQx/Bw/QQEFXZ2fP6fP3dcTuWfTq
PyBrDVsEwMSJsej7AgERMA0GCSqGSIb3DQEBBQUAA4IBAQCLt6PZessm/z3pSZ8HVBKwLPzsxsGA
fwgkMwo4NAb193WYQGRguu1JRqYyBgunXJj+MsvCgxr0Cbr7AvVSN4GKK/QJcfL4rr24zUOdqt6d
ioMgk6gsn7ts2J8bbzK4+Jp6UJPco9IHhnTorqI5jZlNTZ43D4chALTqZH3HShJr3vJZ/nUKyIpu
P7ITYZR3x1S4RUyqIIcHkosAkaH8yyhqlUnKA5xFeHUkeFE86JyrM1c5lowvZETWCWQkmy6Au6X1
kbk60lpptDdPn15RUHnSYzwVeXkpmZEPhS7cs134nBRXB5RFDGmQDbcMH6E9xMvJDI/FUCvyJ1Z1
F8+nciUHMIIDqzCCApOgAwIBAgIRAPfl7mMkXQ6kKqRIT7cqvBcwDQYJKoZIhvcNAQEFBQAwgZEx
EjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYD
VQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNv
bSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMDEyOTE2MjA0NloXDTE2MDIwMjE2
MjA0NlowgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20u
Y29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNV
BAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIDANBgkqhkiG9w0BAQEF
AAOCAQ0AMIIBCAKCAQEA9XehWqD0AK8jSepGl5mMpn3LWW930PXr5RtckP/RtVAu08TIOAkILvlx
5Sjm2nOqbdYUHavIRgMLoyI0gaH8vKINixLDgb/vgtTVQkd09k+VGIOJ/jq40PvWQ4BVRImd/0mb
MYgAePhFSQrgRfALhd0e+pNweBEO5Gg+OYkElGU6f5B+cH3LHiMhfJ7JEJKGjMHsFGGDAp/jeQTc
K9icqCg+NqR/FT/xw6eh35ucxL5A74hFvog06u8m5MAOB2Y7RT2NPHAoYy3WCdYeSZmWYnQa0GRn
0WBCvefQdtL6mCkMfwcP0EBBV2dnz+nz93XE7ln06j8gaw1bBMDEibHo+wIBETANBgkqhkiG9w0B
AQUFAAOCAQEAi7ej2XrLJv896UmfB1QSsCz87MbBgH8IJDMKODQG9fd1mEBkYLrtSUamMgYLp1yY
/jLLwoMa9Am6+wL1UjeBiiv0CXHy+K69uM1DnarenYqDIJOoLJ+7bNifG28yuPiaelCT3KPSB4Z0
6K6iOY2ZTU2eNw+HIQC06mR9x0oSa97yWf51CsiKbj+yE2GUd8dUuEVMqiCHB5KLAJGh/MsoapVJ
ygOcRXh1JHhRPOicqzNXOZaML2RE1glkJJsugLul9ZG5OtJaabQ3T59eUVB50mM8FXl5KZmRD4Uu
3LNd+JwUVweURQxpkA23DB+hPcTLyQyPxVAr8idWdRfPp3IlBzCCA6swggKToAMCAQICEQD35e5j
JF0OpCqkSE+3KrwXMA0GCSqGSIb3DQEBBQUAMIGRMRIwEAYDVQQKEwlJemVjb20gQlYxHjAcBgkq
hkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJk
YW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eTAeFw0wMzAxMjkxNjIwNDZaFw0xNjAyMDIxNjIwNDZaMIGRMRIwEAYDVQQKEwlJemVjb20g
QlYxHjAcBgkqhkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQH
EwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAPV3oVqg9ACvI0nq
RpeZjKZ9y1lvd9D16+UbXJD/0bVQLtPEyDgJCC75ceUo5tpzqm3WFB2ryEYDC6MiNIGh/LyiDYsS
w4G/74LU1UJHdPZPlRiDif46uND71kOAVUSJnf9JmzGIAHj4RUkK4EXwC4XdHvqTcHgRDuRoPjmJ
BJRlOn+QfnB9yx4jIXyeyRCShozB7BRhgwKf43kE3CvYnKgoPjakfxU/8cOnod+bnMS+QO+IRb6I
NOrvJuTADgdmO0U9jTxwKGMt1gnWHkmZlmJ0GtBkZ9FgQr3n0HbS+pgpDH8HD9BAQVdnZ8/p8/d1
xO5Z9Oo/IGsNWwTAxImx6PsCAREwDQYJKoZIhvcNAQEFBQADggEBAIu3o9l6yyb/PelJnwdUErAs
/OzGwYB/CCQzCjg0BvX3dZhAZGC67UlGpjIGC6dcmP4yy8KDGvQJuvsC9VI3gYor9Alx8viuvbjN
Q52q3p2KgyCTqCyfu2zYnxtvMrj4mnpQk9yj0geGdOiuojmNmU1NnjcPhyEAtOpkfcdKEmve8ln+
dQrIim4/shNhlHfHVLhFTKoghweSiwCRofzLKGqVScoDnEV4dSR4UTzonKszVzmWjC9kRNYJZCSb
LoC7pfWRuTrSWmm0N0+fXlFQedJjPBV5eSmZkQ+FLtyzXficFFcHlEUMaZANtwwfoT3Ey8kMj8VQ
K/InVnUXz6dyJQcwggOrMIICk6ADAgECAhEA9+XuYyRdDqQqpEhPtyq8FzANBgkqhkiG9w0BAQUF
ADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20x
DDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMj
SXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDMwMTI5MTYyMDQ2WhcNMTYw
MjAyMTYyMDQ2WjCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6
ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEs
MCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEgMA0GCSqGSIb3
DQEBAQUAA4IBDQAwggEIAoIBAQD1d6FaoPQAryNJ6kaXmYymfctZb3fQ9evlG1yQ/9G1UC7TxMg4
CQgu+XHlKObac6pt1hQdq8hGAwujIjSBofy8og2LEsOBv++C1NVCR3T2T5UYg4n+OrjQ+9ZDgFVE
iZ3/SZsxiAB4+EVJCuBF8AuF3R76k3B4EQ7kaD45iQSUZTp/kH5wfcseIyF8nskQkoaMwewUYYMC
n+N5BNwr2JyoKD42pH8VP/HDp6Hfm5zEvkDviEW+iDTq7ybkwA4HZjtFPY08cChjLdYJ1h5JmZZi
dBrQZGfRYEK959B20vqYKQx/Bw/QQEFXZ2fP6fP3dcTuWfTqPyBrDVsEwMSJsej7AgERMA0GCSqG
SIb3DQEBBQUAA4IBAQCLt6PZessm/z3pSZ8HVBKwLPzsxsGAfwgkMwo4NAb193WYQGRguu1JRqYy
BgunXJj+MsvCgxr0Cbr7AvVSN4GKK/QJcfL4rr24zUOdqt6dioMgk6gsn7ts2J8bbzK4+Jp6UJPc
o9IHhnTorqI5jZlNTZ43D4chALTqZH3HShJr3vJZ/nUKyIpuP7ITYZR3x1S4RUyqIIcHkosAkaH8
yyhqlUnKA5xFeHUkeFE86JyrM1c5lowvZETWCWQkmy6Au6X1kbk60lpptDdPn15RUHnSYzwVeXkp
mZEPhS7cs134nBRXB5RFDGmQDbcMH6E9xMvJDI/FUCvyJ1Z1F8+nciUHMIIDqzCCApOgAwIBAgIR
APfl7mMkXQ6kKqRIT7cqvBcwDQYJKoZIhvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEe
MBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFt
c3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTAzMDEyOTE2MjA0NloXDTE2MDIwMjE2MjA0NlowgZExEjAQBgNVBAoTCUl6
ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQ
BgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEA9XehWqD0
AK8jSepGl5mMpn3LWW930PXr5RtckP/RtVAu08TIOAkILvlx5Sjm2nOqbdYUHavIRgMLoyI0gaH8
vKINixLDgb/vgtTVQkd09k+VGIOJ/jq40PvWQ4BVRImd/0mbMYgAePhFSQrgRfALhd0e+pNweBEO
5Gg+OYkElGU6f5B+cH3LHiMhfJ7JEJKGjMHsFGGDAp/jeQTcK9icqCg+NqR/FT/xw6eh35ucxL5A
74hFvog06u8m5MAOB2Y7RT2NPHAoYy3WCdYeSZmWYnQa0GRn0WBCvefQdtL6mCkMfwcP0EBBV2dn
z+nz93XE7ln06j8gaw1bBMDEibHo+wIBETANBgkqhkiG9w0BAQUFAAOCAQEAi7ej2XrLJv896Umf
B1QSsCz87MbBgH8IJDMKODQG9fd1mEBkYLrtSUamMgYLp1yY/jLLwoMa9Am6+wL1UjeBiiv0CXHy
+K69uM1DnarenYqDIJOoLJ+7bNifG28yuPiaelCT3KPSB4Z06K6iOY2ZTU2eNw+HIQC06mR9x0oS
a97yWf51CsiKbj+yE2GUd8dUuEVMqiCHB5KLAJGh/MsoapVJygOcRXh1JHhRPOicqzNXOZaML2RE
1glkJJsugLul9ZG5OtJaabQ3T59eUVB50mM8FXl5KZmRD4Uu3LNd+JwUVweURQxpkA23DB+hPcTL
yQyPxVAr8idWdRfPp3IlBzCCA6swggKToAMCAQICEQD35e5jJF0OpCqkSE+3KrwXMA0GCSqGSIb3
DQEBBQUAMIGRMRIwEAYDVQQKEwlJemVjb20gQlYxHjAcBgkqhkiG9w0BCQEWD2luZm9AaXplY29t
LmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYD
VQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMzAxMjkxNjIwNDZa
Fw0xNjAyMDIxNjIwNDZaMIGRMRIwEAYDVQQKEwlJemVjb20gQlYxHjAcBgkqhkiG9w0BCQEWD2lu
Zm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYT
Ak5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJ
KoZIhvcNAQEBBQADggENADCCAQgCggEBAPV3oVqg9ACvI0nqRpeZjKZ9y1lvd9D16+UbXJD/0bVQ
LtPEyDgJCC75ceUo5tpzqm3WFB2ryEYDC6MiNIGh/LyiDYsSw4G/74LU1UJHdPZPlRiDif46uND7
1kOAVUSJnf9JmzGIAHj4RUkK4EXwC4XdHvqTcHgRDuRoPjmJBJRlOn+QfnB9yx4jIXyeyRCShozB
7BRhgwKf43kE3CvYnKgoPjakfxU/8cOnod+bnMS+QO+IRb6INOrvJuTADgdmO0U9jTxwKGMt1gnW
HkmZlmJ0GtBkZ9FgQr3n0HbS+pgpDH8HD9BAQVdnZ8/p8/d1xO5Z9Oo/IGsNWwTAxImx6PsCAREw
DQYJKoZIhvcNAQEFBQADggEBAIu3o9l6yyb/PelJnwdUErAs/OzGwYB/CCQzCjg0BvX3dZhAZGC6
7UlGpjIGC6dcmP4yy8KDGvQJuvsC9VI3gYor9Alx8viuvbjNQ52q3p2KgyCTqCyfu2zYnxtvMrj4
mnpQk9yj0geGdOiuojmNmU1NnjcPhyEAtOpkfcdKEmve8ln+dQrIim4/shNhlHfHVLhFTKoghweS
iwCRofzLKGqVScoDnEV4dSR4UTzonKszVzmWjC9kRNYJZCSbLoC7pfWRuTrSWmm0N0+fXlFQedJj
PBV5eSmZkQ+FLtyzXficFFcHlEUMaZANtwwfoT3Ey8kMj8VQK/InVnUXz6dyJQcwggOrMIICk6AD
AgECAhEA9+XuYyRdDqQqpEhPtyq8FzANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29t
IEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UE
BxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDMwMTI5MTYyMDQ2WhcNMTYwMjAyMTYyMDQ2WjCBkTESMBAGA1UE
ChMJSXplY29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24v
YTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3Qg
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQD1
d6FaoPQAryNJ6kaXmYymfctZb3fQ9evlG1yQ/9G1UC7TxMg4CQgu+XHlKObac6pt1hQdq8hGAwuj
IjSBofy8og2LEsOBv++C1NVCR3T2T5UYg4n+OrjQ+9ZDgFVEiZ3/SZsxiAB4+EVJCuBF8AuF3R76
k3B4EQ7kaD45iQSUZTp/kH5wfcseIyF8nskQkoaMwewUYYMCn+N5BNwr2JyoKD42pH8VP/HDp6Hf
m5zEvkDviEW+iDTq7ybkwA4HZjtFPY08cChjLdYJ1h5JmZZidBrQZGfRYEK959B20vqYKQx/Bw/Q
QEFXZ2fP6fP3dcTuWfTqPyBrDVsEwMSJsej7AgERMA0GCSqGSIb3DQEBBQUAA4IBAQCLt6PZessm
/z3pSZ8HVBKwLPzsxsGAfwgkMwo4NAb193WYQGRguu1JRqYyBgunXJj+MsvCgxr0Cbr7AvVSN4GK
K/QJcfL4rr24zUOdqt6dioMgk6gsn7ts2J8bbzK4+Jp6UJPco9IHhnTorqI5jZlNTZ43D4chALTq
ZH3HShJr3vJZ/nUKyIpuP7ITYZR3x1S4RUyqIIcHkosAkaH8yyhqlUnKA5xFeHUkeFE86JyrM1c5
lowvZETWCWQkmy6Au6X1kbk60lpptDdPn15RUHnSYzwVeXkpmZEPhS7cs134nBRXB5RFDGmQDbcM
H6E9xMvJDI/FUCvyJ1Z1F8+nciUHMIIDqzCCApOgAwIBAgIRAPfl7mMkXQ6kKqRIT7cqvBcwDQYJ
KoZIhvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0Bp
emVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwx
LDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMDEyOTE2
MjA0NloXDTE2MDIwMjE2MjA0NlowgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJ
ARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkG
A1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIB
IDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEA9XehWqD0AK8jSepGl5mMpn3LWW930PXr5Rtc
kP/RtVAu08TIOAkILvlx5Sjm2nOqbdYUHavIRgMLoyI0gaH8vKINixLDgb/vgtTVQkd09k+VGIOJ
/jq40PvWQ4BVRImd/0mbMYgAePhFSQrgRfALhd0e+pNweBEO5Gg+OYkElGU6f5B+cH3LHiMhfJ7J
EJKGjMHsFGGDAp/jeQTcK9icqCg+NqR/FT/xw6eh35ucxL5A74hFvog06u8m5MAOB2Y7RT2NPHAo
Yy3WCdYeSZmWYnQa0GRn0WBCvefQdtL6mCkMfwcP0EBBV2dnz+nz93XE7ln06j8gaw1bBMDEibHo
+wIBETANBgkqhkiG9w0BAQUFAAOCAQEAi7ej2XrLJv896UmfB1QSsCz87MbBgH8IJDMKODQG9fd1
mEBkYLrtSUamMgYLp1yY/jLLwoMa9Am6+wL1UjeBiiv0CXHy+K69uM1DnarenYqDIJOoLJ+7bNif
G28yuPiaelCT3KPSB4Z06K6iOY2ZTU2eNw+HIQC06mR9x0oSa97yWf51CsiKbj+yE2GUd8dUuEVM
qiCHB5KLAJGh/MsoapVJygOcRXh1JHhRPOicqzNXOZaML2RE1glkJJsugLul9ZG5OtJaabQ3T59e
UVB50mM8FXl5KZmRD4Uu3LNd+JwUVweURQxpkA23DB+hPcTLyQyPxVAr8idWdRfPp3IlBzCCA/ww
ggLkoAMCAQICEQCRHMRCX7eVQZ+iLXT3DluVMA0GCSqGSIb3DQEBBQUAMIGRMRIwEAYDVQQKEwlJ
emVjb20gQlYxHjAcBgkqhkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIw
EAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMzAxMjkxNjIxMjhaFw0xNDAyMDIxNjIxMjhaMIGOMRIw
EAYDVQQKEwlJemVjb20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFpbC5jb20xDDAKBgNV
BAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEoMCYGA1UEAxMfSXplbWFp
bCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEB
AKj+sHuVMe3CzjFCVBIDUNLpX7WCFKN8MuJZ8aqJMHvA5Y4+B7mOdLNXfnmNbrlfYw0lMViVeLIs
zvrbte0OVh94ixmbQfxwcSVEmgskUYUcORDUf5g5SD+JNdOxFy59O/A/fLBsp7sAZ2aLelZdVYHq
AnzUC1TWgnsr6H+Dc5SqHv34p3/Mm4QCZ9CuCAN15vffkBbRyQ63JDwWIhJ7Q6nXCfto6q+fSMo0
OeePmCWym1NoExdTni5AcSgiuiVl7JBTG9pFx9gbhQXGEyV+j0N+nlZonFqx8sQU6Yg4SaYl1uwx
PJgXOAujvll3ZKseHhW66gwfba8+Xm85fo0UmxkCARGjUjBQMAsGA1UdDwQEAwIBBjAPBgNVHRME
CDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUH
AwIwDQYJKoZIhvcNAQEFBQADggEBAPHKL+veBSUYXXFoZQwn/2f0sIZbVut+lqdBplaYwYevSXcb
x4DKzDuF5nweUAbuZly7N5GZo80/6isk/O7xKBWSgxRqNVcl/ifUVdtwNbYqvCxSMn50APyoMJSg
1cmKf9SNKRLf4GSXsyZzEO8LqamzJJqHSCCpai0/TP7/xYpdjScMW7k+57KyEJnF+8chKv16hGWW
NmVXHVM1WyUOaobjaT4VH6tQmD5PyuBenKJ4Tp66xQHdD0CiuGSyoVh9jLegx61JV2f3JvHB8Erz
wa0mQf4pY0iL2icbkAQQgM7BRwxHhs5lt7FEB1rYFItwvTF01jVL1VvTFHsR9iRGJM8wggP8MIIC
5KADAgECAhEAkRzEQl+3lUGfoi109w5blTANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXpl
Y29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAG
A1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwHhcNMDMwMTI5MTYyMTI4WhcNMTQwMjAyMTYyMTI4WjCBjjESMBAG
A1UEChMJSXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMQwwCgYDVQQI
EwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxKDAmBgNVBAMTH0l6ZW1haWwg
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQCo
/rB7lTHtws4xQlQSA1DS6V+1ghSjfDLiWfGqiTB7wOWOPge5jnSzV355jW65X2MNJTFYlXiyLM76
27XtDlYfeIsZm0H8cHElRJoLJFGFHDkQ1H+YOUg/iTXTsRcufTvwP3ywbKe7AGdmi3pWXVWB6gJ8
1AtU1oJ7K+h/g3OUqh79+Kd/zJuEAmfQrggDdeb335AW0ckOtyQ8FiISe0Op1wn7aOqvn0jKNDnn
j5glsptTaBMXU54uQHEoIrolZeyQUxvaRcfYG4UFxhMlfo9Dfp5WaJxasfLEFOmIOEmmJdbsMTyY
FzgLo75Zd2SrHh4VuuoMH22vPl5vOX6NFJsZAgERo1IwUDALBgNVHQ8EBAMCAQYwDwYDVR0TBAgw
BgEB/wIBADARBglghkgBhvhCAQEEBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MA0GCSqGSIb3DQEBBQUAA4IBAQDxyi/r3gUlGF1xaGUMJ/9n9LCGW1brfpanQaZWmMGHr0l3G8eA
ysw7heZ8HlAG7mZcuzeRmaPNP+orJPzu8SgVkoMUajVXJf4n1FXbcDW2KrwsUjJ+dAD8qDCUoNXJ
in/UjSkS3+Bkl7MmcxDvC6mpsySah0ggqWotP0z+/8WKXY0nDFu5PueyshCZxfvHISr9eoRlljZl
Vx1TNVslDmqG42k+FR+rUJg+T8rgXpyieE6eusUB3Q9AorhksqFYfYy3oMetSVdn9ybxwfBK88Gt
JkH+KWNIi9onG5AEEIDOwUcMR4bOZbexRAda2BSLcL0xdNY1S9Vb0xR7EfYkRiTPMIIEDTCCAvWg
AwIBAgIQZukaRJOd0047Jqoo58OaMjANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29t
IEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UE
BxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDMxMDA5MDkzOTIyWhcNMTQxMDEzMDkzOTIyWjCBgzESMBAGA1UE
ChMJSXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMRYwFAYDVQQIEw1O
b29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMRMwEQYDVQQDEwpJ
emVtYWlsIENBMIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAk5I0X5lf7qjlX7k8iWRz
Rxh+BHrQRCT+Wc3elx2OF1BkIPpYgxrfbik9z2+Ag3N2ya6fh1oQ83XcxnP7OuHaT/ePKFEVzBo3
0pqfSd+QuGERp99iAnglxeTDwtatd86vIMB7/XwlZtrbjo0v3FC4vE7zoBHnNL5D+IjxFbcEBaVZ
vMJT7f8SZShzM23yrnlXVYcaC4C6H9p2cyafag1KVe1+rSUgpefKt16wxVQFuTJOl1tViFJdiGlA
COwUvQ0buhcCmY5uaH5owOolEjNUjfy3F4iPTj3QDS/lD4Kc+zeBHTNIe4iPyN1G12Lu2GQl+NAY
7t5KM0xK3svD+L18XwIBEaNvMG0wOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL3d3dy5pemVjb20u
Y29tL2l6ZW1haWwvaXplcm9vdC5jcmwwCwYDVR0PBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQEwEQYJ
YIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCfSVaVl9acK4iqjnOwhPjzZAuy7Hhb
XraNK7Zl0ZAmCLgDlWGe+tjPTOJ5jg6miO1u4jKY/T4+WltYt1m4OcqSNT8ZsXWA4vDZZ69Br7jJ
eOHwr99UZtTLJSwNtURgeDb0390XiCyiMJgF/yRlPrPBBoXutyZ7OImIypYytrHDq//esWntMZgk
sYk6XvIw0yLvrbIiFJzQvpR8F3I03XGu1xEswWd/1NA+D13JYLv4J6WXLKR7KR81qqfkj9Jds31C
7R1rl6AZpnVHHtaGAS8SjHQbgrh/PtLFTCFTFcZvAvTawPpGRvxZlDgZDI+TQf50EJY47zHdUMch
VuSnY2UBMIIEDTCCAvWgAwIBAgIQZukaRJOd0047Jqoo58OaMjANBgkqhkiG9w0BAQUFADCBkTES
MBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNV
BAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29t
IFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDMxMDA5MDkzOTIyWhcNMTQxMDEzMDkz
OTIyWjCBgzESMBAGA1UEChMJSXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwu
Y29tMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYT
Ak5MMRMwEQYDVQQDEwpJemVtYWlsIENBMIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEA
k5I0X5lf7qjlX7k8iWRzRxh+BHrQRCT+Wc3elx2OF1BkIPpYgxrfbik9z2+Ag3N2ya6fh1oQ83Xc
xnP7OuHaT/ePKFEVzBo30pqfSd+QuGERp99iAnglxeTDwtatd86vIMB7/XwlZtrbjo0v3FC4vE7z
oBHnNL5D+IjxFbcEBaVZvMJT7f8SZShzM23yrnlXVYcaC4C6H9p2cyafag1KVe1+rSUgpefKt16w
xVQFuTJOl1tViFJdiGlACOwUvQ0buhcCmY5uaH5owOolEjNUjfy3F4iPTj3QDS/lD4Kc+zeBHTNI
e4iPyN1G12Lu2GQl+NAY7t5KM0xK3svD+L18XwIBEaNvMG0wOgYDVR0fBDMwMTAvoC2gK4YpaHR0
cDovL3d3dy5pemVjb20uY29tL2l6ZW1haWwvaXplcm9vdC5jcmwwCwYDVR0PBAQDAgEGMA8GA1Ud
EwQIMAYBAf8CAQEwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCfSVaVl9ac
K4iqjnOwhPjzZAuy7HhbXraNK7Zl0ZAmCLgDlWGe+tjPTOJ5jg6miO1u4jKY/T4+WltYt1m4OcqS
NT8ZsXWA4vDZZ69Br7jJeOHwr99UZtTLJSwNtURgeDb0390XiCyiMJgF/yRlPrPBBoXutyZ7OImI
ypYytrHDq//esWntMZgksYk6XvIw0yLvrbIiFJzQvpR8F3I03XGu1xEswWd/1NA+D13JYLv4J6WX
LKR7KR81qqfkj9Jds31C7R1rl6AZpnVHHtaGAS8SjHQbgrh/PtLFTCFTFcZvAvTawPpGRvxZlDgZ
DI+TQf50EJY47zHdUMchVuSnY2UBMIIEDTCCAvWgAwIBAgIQZukaRJOd0047Jqoo58OaMjANBgkq
hkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6
ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEs
MCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDMxMDA5MDkz
OTIyWhcNMTQxMDEzMDkzOTIyWjCBgzESMBAGA1UEChMJSXplY29tIEJWMR8wHQYJKoZIhvcNAQkB
FhBpbmZvQGl6ZW1haWwuY29tMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0
ZXJkYW0xCzAJBgNVBAYTAk5MMRMwEQYDVQQDEwpJemVtYWlsIENBMIIBIDANBgkqhkiG9w0BAQEF
AAOCAQ0AMIIBCAKCAQEAk5I0X5lf7qjlX7k8iWRzRxh+BHrQRCT+Wc3elx2OF1BkIPpYgxrfbik9
z2+Ag3N2ya6fh1oQ83XcxnP7OuHaT/ePKFEVzBo30pqfSd+QuGERp99iAnglxeTDwtatd86vIMB7
/XwlZtrbjo0v3FC4vE7zoBHnNL5D+IjxFbcEBaVZvMJT7f8SZShzM23yrnlXVYcaC4C6H9p2cyaf
ag1KVe1+rSUgpefKt16wxVQFuTJOl1tViFJdiGlACOwUvQ0buhcCmY5uaH5owOolEjNUjfy3F4iP
Tj3QDS/lD4Kc+zeBHTNIe4iPyN1G12Lu2GQl+NAY7t5KM0xK3svD+L18XwIBEaNvMG0wOgYDVR0f
BDMwMTAvoC2gK4YpaHR0cDovL3d3dy5pemVjb20uY29tL2l6ZW1haWwvaXplcm9vdC5jcmwwCwYD
VR0PBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQEwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEB
BQUAA4IBAQCfSVaVl9acK4iqjnOwhPjzZAuy7HhbXraNK7Zl0ZAmCLgDlWGe+tjPTOJ5jg6miO1u
4jKY/T4+WltYt1m4OcqSNT8ZsXWA4vDZZ69Br7jJeOHwr99UZtTLJSwNtURgeDb0390XiCyiMJgF
/yRlPrPBBoXutyZ7OImIypYytrHDq//esWntMZgksYk6XvIw0yLvrbIiFJzQvpR8F3I03XGu1xEs
wWd/1NA+D13JYLv4J6WXLKR7KR81qqfkj9Jds31C7R1rl6AZpnVHHtaGAS8SjHQbgrh/PtLFTCFT
FcZvAvTawPpGRvxZlDgZDI+TQf50EJY47zHdUMchVuSnY2UBMIIEDTCCAvWgAwIBAgIQZukaRJOd
0047Jqoo58OaMjANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZI
hvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFt
MQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkwHhcNMDMxMDA5MDkzOTIyWhcNMTQxMDEzMDkzOTIyWjCBgzESMBAGA1UEChMJSXplY29tIEJW
MR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5k
MRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMRMwEQYDVQQDEwpJemVtYWlsIENBMIIB
IDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAk5I0X5lf7qjlX7k8iWRzRxh+BHrQRCT+Wc3e
lx2OF1BkIPpYgxrfbik9z2+Ag3N2ya6fh1oQ83XcxnP7OuHaT/ePKFEVzBo30pqfSd+QuGERp99i
AnglxeTDwtatd86vIMB7/XwlZtrbjo0v3FC4vE7zoBHnNL5D+IjxFbcEBaVZvMJT7f8SZShzM23y
rnlXVYcaC4C6H9p2cyafag1KVe1+rSUgpefKt16wxVQFuTJOl1tViFJdiGlACOwUvQ0buhcCmY5u
aH5owOolEjNUjfy3F4iPTj3QDS/lD4Kc+zeBHTNIe4iPyN1G12Lu2GQl+NAY7t5KM0xK3svD+L18
XwIBEaNvMG0wOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL3d3dy5pemVjb20uY29tL2l6ZW1haWwv
aXplcm9vdC5jcmwwCwYDVR0PBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQEwEQYJYIZIAYb4QgEBBAQD
AgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCfSVaVl9acK4iqjnOwhPjzZAuy7HhbXraNK7Zl0ZAmCLgD
lWGe+tjPTOJ5jg6miO1u4jKY/T4+WltYt1m4OcqSNT8ZsXWA4vDZZ69Br7jJeOHwr99UZtTLJSwN
tURgeDb0390XiCyiMJgF/yRlPrPBBoXutyZ7OImIypYytrHDq//esWntMZgksYk6XvIw0yLvrbIi
FJzQvpR8F3I03XGu1xEswWd/1NA+D13JYLv4J6WXLKR7KR81qqfkj9Jds31C7R1rl6AZpnVHHtaG
AS8SjHQbgrh/PtLFTCFTFcZvAvTawPpGRvxZlDgZDI+TQf50EJY47zHdUMchVuSnY2UBMIIEDTCC
AvWgAwIBAgIQZukaRJOd0047Jqoo58OaMjANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXpl
Y29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAG
A1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwHhcNMDMxMDA5MDkzOTIyWhcNMTQxMDEzMDkzOTIyWjCBgzESMBAG
A1UEChMJSXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMRYwFAYDVQQI
Ew1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMRMwEQYDVQQD
EwpJemVtYWlsIENBMIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAk5I0X5lf7qjlX7k8
iWRzRxh+BHrQRCT+Wc3elx2OF1BkIPpYgxrfbik9z2+Ag3N2ya6fh1oQ83XcxnP7OuHaT/ePKFEV
zBo30pqfSd+QuGERp99iAnglxeTDwtatd86vIMB7/XwlZtrbjo0v3FC4vE7zoBHnNL5D+IjxFbcE
BaVZvMJT7f8SZShzM23yrnlXVYcaC4C6H9p2cyafag1KVe1+rSUgpefKt16wxVQFuTJOl1tViFJd
iGlACOwUvQ0buhcCmY5uaH5owOolEjNUjfy3F4iPTj3QDS/lD4Kc+zeBHTNIe4iPyN1G12Lu2GQl
+NAY7t5KM0xK3svD+L18XwIBEaNvMG0wOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL3d3dy5pemVj
b20uY29tL2l6ZW1haWwvaXplcm9vdC5jcmwwCwYDVR0PBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQEw
EQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCfSVaVl9acK4iqjnOwhPjzZAuy
7HhbXraNK7Zl0ZAmCLgDlWGe+tjPTOJ5jg6miO1u4jKY/T4+WltYt1m4OcqSNT8ZsXWA4vDZZ69B
r7jJeOHwr99UZtTLJSwNtURgeDb0390XiCyiMJgF/yRlPrPBBoXutyZ7OImIypYytrHDq//esWnt
MZgksYk6XvIw0yLvrbIiFJzQvpR8F3I03XGu1xEswWd/1NA+D13JYLv4J6WXLKR7KR81qqfkj9Jd
s31C7R1rl6AZpnVHHtaGAS8SjHQbgrh/PtLFTCFTFcZvAvTawPpGRvxZlDgZDI+TQf50EJY47zHd
UMchVuSnY2UBMIIEDTCCAvWgAwIBAgIQZukaRJOd0047Jqoo58OaMjANBgkqhkiG9w0BAQUFADCB
kTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAK
BgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXpl
Y29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDMxMDA5MDkzOTIyWhcNMTQxMDEz
MDkzOTIyWjCBgzESMBAGA1UEChMJSXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1h
aWwuY29tMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNV
BAYTAk5MMRMwEQYDVQQDEwpJemVtYWlsIENBMIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKC
AQEAk5I0X5lf7qjlX7k8iWRzRxh+BHrQRCT+Wc3elx2OF1BkIPpYgxrfbik9z2+Ag3N2ya6fh1oQ
83XcxnP7OuHaT/ePKFEVzBo30pqfSd+QuGERp99iAnglxeTDwtatd86vIMB7/XwlZtrbjo0v3FC4
vE7zoBHnNL5D+IjxFbcEBaVZvMJT7f8SZShzM23yrnlXVYcaC4C6H9p2cyafag1KVe1+rSUgpefK
t16wxVQFuTJOl1tViFJdiGlACOwUvQ0buhcCmY5uaH5owOolEjNUjfy3F4iPTj3QDS/lD4Kc+zeB
HTNIe4iPyN1G12Lu2GQl+NAY7t5KM0xK3svD+L18XwIBEaNvMG0wOgYDVR0fBDMwMTAvoC2gK4Yp
aHR0cDovL3d3dy5pemVjb20uY29tL2l6ZW1haWwvaXplcm9vdC5jcmwwCwYDVR0PBAQDAgEGMA8G
A1UdEwQIMAYBAf8CAQEwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCfSVaV
l9acK4iqjnOwhPjzZAuy7HhbXraNK7Zl0ZAmCLgDlWGe+tjPTOJ5jg6miO1u4jKY/T4+WltYt1m4
OcqSNT8ZsXWA4vDZZ69Br7jJeOHwr99UZtTLJSwNtURgeDb0390XiCyiMJgF/yRlPrPBBoXutyZ7
OImIypYytrHDq//esWntMZgksYk6XvIw0yLvrbIiFJzQvpR8F3I03XGu1xEswWd/1NA+D13JYLv4
J6WXLKR7KR81qqfkj9Jds31C7R1rl6AZpnVHHtaGAS8SjHQbgrh/PtLFTCFTFcZvAvTawPpGRvxZ
lDgZDI+TQf50EJY47zHdUMchVuSnY2UBMIIEpjCCBA+gAwIBAgIQSbfsXkUnPyoY6/2SwmV/3TAN
BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNz
IDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wNDAx
MDYwMDAwMDBaFw0wNTAxMDgyMzU5NTlaMIIBGDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20v
cmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl
cnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9z
b2Z0IEZ1bGwgU2VydmljZTEZMBcGA1UEAxQQQ2hyaXN0aW5lIEthcm1hbjEjMCEGCSqGSIb3DQEJ
ARYUY2hyaXN0aW5lQGl6ZWNvbS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAO3VYgkA
Ungi83pdruymuGDn13rt2F6EM/50HnBNf0RNQzHVJ5AqGdqlYlb9LgB4Trv0u3N+SDgiXGtpiGaJ
zPdUbS3foY4wIkrrtWQ0jkcBo7pJtP89z2ou+Rkl0lKaQBzCuvjsDVEm3GGNfgtJNbMMENieRVx2
lVor/Ec0inIFAgMBAAGjggE4MIIBNDAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG
+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsG
AQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBi
eSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4Aw
MAYKYIZIAYb4RQEGBwQiFiA0MWJkN2IwYzE1OTdmYTVmYjllZDk1NTQ0MzJiYmExNDAzBgNVHR8E
LDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEB
BAUAA4GBABkFgcq+QFjgGnGIOU9TQSP1g+8V9+tPYmbwa4tSFqI2x4TSDq0OL5+F0+PzHxabfPJT
LVQfbbueOQCMk3qGSEoKD++iBBuDIgXs5GxDJrfRsemhfzIbnco0xATxL6qUplE8tYo5yDrbDJ7O
NGxLO+wg2yn0nuLTWDE7YCP+GGmUMIIEyDCCBDGgAwIBAgIEAgACmzANBgkqhkiG9w0BAQUFADBF
MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRwwGgYDVQQDExNHVEUgQ3li
ZXJUcnVzdCBSb290MB4XDTAyMDgyNzE5MDcwMFoXDTA2MDIyMzIzNTkwMFowgdwxCzAJBgNVBAYT
AkdCMRcwFQYDVQQKEw5Db21vZG8gTGltaXRlZDEdMBsGA1UECxMUQ29tb2RvIFRydXN0IE5ldHdv
cmsxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5jb21v
ZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDIgQ29tb2RvIExpbWl0ZWQxLDAqBgNV
BAMTI0NvbW9kbyBDbGFzcyAzIFNlY3VyaXR5IFNlcnZpY2VzIENBMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAsR5gZuBDBp4naC8CmceI34Xr22Xs1Elnei4fzdwVLNYerPKdRjpdA8A9
BSxaGA1ZJUKjcsCtKNKtPDHiSwf7XpjrqDPWabJanuosSaYmLkzwzKtA0qreLE6Btbp7uFzQe71H
9cAG0sDk10fbYkCvoRxRAxjbuNC7lMc8eeolZK4mGeE8Zkdnkp17Vas0wnVu2SeOnYzwHdprnIYE
opC16p2Mz/s5Q6jwGC2e9xkQLJwv4dCx/9dZxM1AMvnXgdtRHPJBUoFBsYO4yAn+mSJHgE+cy67g
KNUcrHBHsCWroThCF2v6am6NX3n49ikDMKRuRtSFXapAmTh22x4BfeUMpQIDAQABo4IBpzCCAaMw
RQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3d3dy5wdWJsaWMtdHJ1c3QuY29tL2NnaS1iaW4vQ1JM
LzIwMDYvY2RwLmNybDAdBgNVHQ4EFgQU9lIiFxUTCANZvxiVn0i0uen++GYwgZIGA1UdIASBijCB
hzBJBgoqhkiG+GMBAgEFMDswOQYIKwYBBQUHAgEWLWh0dHA6Ly93d3cucHVibGljLXRydXN0LmNv
bS9DUFMvT21uaVJvb3QuaHRtbDA6BgwrBgEEAbIxAQIBAwEwKjAoBggrBgEFBQcCARYcaHR0cHM6
Ly9zZWN1cmUuY29tb2RvLm5ldC9DUDBYBgNVHSMEUTBPoUmkRzBFMQswCQYDVQQGEwJVUzEYMBYG
A1UEChMPR1RFIENvcnBvcmF0aW9uMRwwGgYDVQQDExNHVEUgQ3liZXJUcnVzdCBSb290ggIBozAr
BgNVHRAEJDAigA8yMDAyMDgyNzE5MDczMVqBDzIwMDUwMjIzMjM1OTAwWjAOBgNVHQ8BAf8EBAMC
AeYwDwYDVR0TBAgwBgEB/wIBADANBgkqhkiG9w0BAQUFAAOBgQC2p7B6cYvgurOBHjYyeoYY1vGr
TTkIcQZaZ6BLAeUwQG2JtZ4VqrHH9ArGXA7pN96ol8fczs1x+3QCB9xfFScIUwd21LkG6cJ3UB7K
ybDCRoGAAK1EqlzWINlVMr5WlvHqvaDjvA2AOurM+5pX7XilNj1W6tHndMo0w8+xUengDDCCBMgw
ggQxoAMCAQICBAIAApswDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dU
RSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdDAeFw0wMjA4MjcxOTA3
MDBaFw0wNjAyMjMyMzU5MDBaMIHcMQswCQYDVQQGEwJHQjEXMBUGA1UEChMOQ29tb2RvIExpbWl0
ZWQxHTAbBgNVBAsTFENvbW9kbyBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29u
ZGl0aW9ucyBvZiB1c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQL
ExYoYykyMDAyIENvbW9kbyBMaW1pdGVkMSwwKgYDVQQDEyNDb21vZG8gQ2xhc3MgMyBTZWN1cml0
eSBTZXJ2aWNlcyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALEeYGbgQwaeJ2gv
ApnHiN+F69tl7NRJZ3ouH83cFSzWHqzynUY6XQPAPQUsWhgNWSVCo3LArSjSrTwx4ksH+16Y66gz
1mmyWp7qLEmmJi5M8MyrQNKq3ixOgbW6e7hc0Hu9R/XABtLA5NdH22JAr6EcUQMY27jQu5THPHnq
JWSuJhnhPGZHZ5Kde1WrNMJ1btknjp2M8B3aa5yGBKKQteqdjM/7OUOo8BgtnvcZECycL+HQsf/X
WcTNQDL514HbURzyQVKBQbGDuMgJ/pkiR4BPnMuu4CjVHKxwR7Alq6E4Qhdr+mpujV95+PYpAzCk
bkbUhV2qQJk4dtseAX3lDKUCAwEAAaOCAacwggGjMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93
d3cucHVibGljLXRydXN0LmNvbS9jZ2ktYmluL0NSTC8yMDA2L2NkcC5jcmwwHQYDVR0OBBYEFPZS
IhcVEwgDWb8YlZ9ItLnp/vhmMIGSBgNVHSAEgYowgYcwSQYKKoZIhvhjAQIBBTA7MDkGCCsGAQUF
BwIBFi1odHRwOi8vd3d3LnB1YmxpYy10cnVzdC5jb20vQ1BTL09tbmlSb290Lmh0bWwwOgYMKwYB
BAGyMQECAQMBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1AwWAYD
VR0jBFEwT6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoG
A1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwKwYDVR0QBCQwIoAPMjAwMjA4MjcxOTA3MzFa
gQ8yMDA1MDIyMzIzNTkwMFowDgYDVR0PAQH/BAQDAgHmMA8GA1UdEwQIMAYBAf8CAQAwDQYJKoZI
hvcNAQEFBQADgYEAtqewenGL4LqzgR42MnqGGNbxq005CHEGWmegSwHlMEBtibWeFaqxx/QKxlwO
6TfeqJfH3M7Ncft0AgfcXxUnCFMHdtS5BunCd1AeysmwwkaBgACtRKpc1iDZVTK+Vpbx6r2g47wN
gDrqzPuaV+14pTY9VurR53TKNMPPsVHp4AwwggV6MIIEYqADAgECAhEAnytBMGb8ejNXdO1SevpL
3zANBgkqhkiG9w0BAQUFADCB3DELMAkGA1UEBhMCR0IxFzAVBgNVBAoTDkNvbW9kbyBMaW1pdGVk
MR0wGwYDVQQLExRDb21vZG8gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRp
dGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMW
KGMpMjAwMiBDb21vZG8gTGltaXRlZDEsMCoGA1UEAxMjQ29tb2RvIENsYXNzIDMgU2VjdXJpdHkg
U2VydmljZXMgQ0EwHhcNMDQwNTEwMDAwMDAwWhcNMDUwNTEwMjM1OTU5WjCB4DE1MDMGA1UECxMs
Q29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRl
cm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRv
cnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQxGTAXBgNVBAMTEENocmlzdGluZSBL
YXJtYW4xIzAhBgkqhkiG9w0BCQEWFGNocmlzdGluZUBpemVjb20uY29tMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDME34pF9A6lo1iaFrD9G8NhNMafomtO8xd4TQiBUlEthWWUctIuYS/JTye
mbCVM+WDkKuSDBZ/weTJNii49ERcfV9xN90BCyZ+do1qoTRb0DYyvwq60Ap7IQd6f6LqPV6RLoQk
OL+vcygQ4CIO4dvz6v9Ek9Bon4CCoK15hho46wIDAQABo4IBszCCAa8wHwYDVR0jBBgwFoAU9lIi
FxUTCANZvxiVn0i0uen++GYwHQYDVR0OBBYEFOJBJQ/E+V7WGdFfLEYJZBOJyqyDMA4GA1UdDwEB
/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjBG
BgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5j
b21vZG8ubmV0L0NQUzCBsAYDVR0fBIGoMIGlMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kby5uZXQv
Q2xhc3MzU2VjdXJpdHlTZXJ2aWNlc18yLmNybDA6oDigNoY0aHR0cDovL2NybC5jb21vZG9jYS5j
b20vQ2xhc3MzU2VjdXJpdHlTZXJ2aWNlc18yLmNybDAtoCugKYEnQ2xhc3MzU2VjdXJpdHlTZXJ2
aWNlc18yQGNybC5jb21vZG8ubmV0MBEGCWCGSAGG+EIBAQQEAwIFIDAfBgNVHREEGDAWgRRjaHJp
c3RpbmVAaXplY29tLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAXiuAsCipKZVyyg5cJrgn8a1hRIbx
EsqAMDFOeEwUiwHwa4SwtvmJnpTermSLUIa2ObLq6hf+ODYknuHFISQlC0nY92XficF6Nz3tRvo1
1CU89/wovFcncSjhrrMqo67CjcKAKcGqf96WC8VL72F+SUF1QL2NIlVGqrBdo6/FQxZ86p6m1Wns
No73V+N2NudMWB5hqvSK0IVbyBJtvDgFzZmqCjsyK1vWS7STMvU0StiKN2zzkg20rrqbaUJHpVJw
WavcPRe65nAqnje5X8qDvCugo+CMdSckflHMeBxm85rgVIe60Q/jdeepxdWtjxQOA4YUtvUdVtlz
wRGDb/wYcTCCBXowggRioAMCAQICEQCfK0EwZvx6M1d07VJ6+kvfMA0GCSqGSIb3DQEBBQUAMIHc
MQswCQYDVQQGEwJHQjEXMBUGA1UEChMOQ29tb2RvIExpbWl0ZWQxHTAbBgNVBAsTFENvbW9kbyBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBvZiB1c2U6IGh0dHA6
Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYykyMDAyIENvbW9kbyBMaW1p
dGVkMSwwKgYDVQQDEyNDb21vZG8gQ2xhc3MgMyBTZWN1cml0eSBTZXJ2aWNlcyBDQTAeFw0wNDA1
MTAwMDAwMDBaFw0wNTA1MTAyMzU5NTlaMIHgMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29y
ayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMg
b2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAw
MyBDb21vZG8gTGltaXRlZDEZMBcGA1UEAxMQQ2hyaXN0aW5lIEthcm1hbjEjMCEGCSqGSIb3DQEJ
ARYUY2hyaXN0aW5lQGl6ZWNvbS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMwTfikX
0DqWjWJoWsP0bw2E0xp+ia07zF3hNCIFSUS2FZZRy0i5hL8lPJ6ZsJUz5YOQq5IMFn/B5Mk2KLj0
RFx9X3E33QELJn52jWqhNFvQNjK/CrrQCnshB3p/ouo9XpEuhCQ4v69zKBDgIg7h2/Pq/0ST0Gif
gIKgrXmGGjjrAgMBAAGjggGzMIIBrzAfBgNVHSMEGDAWgBT2UiIXFRMIA1m/GJWfSLS56f74ZjAd
BgNVHQ4EFgQU4kElD8T5XtYZ0V8sRglkE4nKrIMwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQC
MAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMEYGA1UdIAQ/MD0wOwYMKwYBBAGy
MQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGwBgNV
HR8EgagwgaUwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvLm5ldC9DbGFzczNTZWN1cml0eVNlcnZp
Y2VzXzIuY3JsMDqgOKA2hjRodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DbGFzczNTZWN1cml0eVNl
cnZpY2VzXzIuY3JsMC2gK6ApgSdDbGFzczNTZWN1cml0eVNlcnZpY2VzXzJAY3JsLmNvbW9kby5u
ZXQwEQYJYIZIAYb4QgEBBAQDAgUgMB8GA1UdEQQYMBaBFGNocmlzdGluZUBpemVjb20uY29tMA0G
CSqGSIb3DQEBBQUAA4IBAQBeK4CwKKkplXLKDlwmuCfxrWFEhvESyoAwMU54TBSLAfBrhLC2+Yme
lN6uZItQhrY5surqF/44NiSe4cUhJCULSdj3Zd+JwXo3Pe1G+jXUJTz3/Ci8VydxKOGusyqjrsKN
woApwap/3pYLxUvvYX5JQXVAvY0iVUaqsF2jr8VDFnzqnqbVaew2jvdX43Y250xYHmGq9IrQhVvI
Em28OAXNmaoKOzIrW9ZLtJMy9TRK2Io3bPOSDbSuuptpQkelUnBZq9w9F7rmcCqeN7lfyoO8K6Cj
4Ix1JyR+Ucx4HGbzmuBUh7rRD+N156nF1a2PFA4DhhS29R1W2XPBEYNv/BhxMYICJzCCAiMCAQEw
gfIwgdwxCzAJBgNVBAYTAkdCMRcwFQYDVQQKEw5Db21vZG8gTGltaXRlZDEdMBsGA1UECxMUQ29t
b2RvIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTog
aHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDIgQ29tb2Rv
IExpbWl0ZWQxLDAqBgNVBAMTI0NvbW9kbyBDbGFzcyAzIFNlY3VyaXR5IFNlcnZpY2VzIENBAhEA
nytBMGb8ejNXdO1SevpL3zAJBgUrDgMCGgUAoIGLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTA0MDcxOTEzMjM0MFowIwYJKoZIhvcNAQkEMRYEFHmVwJ8VJ8fnoY/S
49Unxoy4K/FVMCwGCSqGSIb3DQEJDzEfMB0wDwYIKoZIhvcNAwIwAwIBOjAKBggqhkiG9w0DBzAN
BgkqhkiG9w0BAQEFAASBgHi+V3GbiS45daTatiwQgqvKQ25JQeOLLxEH5+0sbDuqBY3FmjtPtZ0B
12ERcrY83B6nx7wRc9iWpPnrkKromqYb3vB84FNpGL8bGgmykIfdWQ5SaZ9n0hE9Wz1PQUWBspyY
+5chtk7l13Rq9a5Lx+kDbdCVn1JD/RcjQGn7qdqX

--{39DCBED5-7FEB-4056-8C10-05B4D010B916}--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JDDfUA057128; Mon, 19 Jul 2004 06:13:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JDDfOd057124; Mon, 19 Jul 2004 06:13:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-mclean.mitre.org (smtpproxy2.mitre.org [192.80.55.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JDDdwM057087; Mon, 19 Jul 2004 06:13:39 -0700 (PDT) (envelope-from [e-mail])
Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.11.6/8.11.6) with ESMTP id i6JDDdM28312; Mon, 19 Jul 2004 09:13:39 -0400
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtp-mclean.mitre.org (8.11.6/8.11.6) with ESMTP id i6JDDbS28237; Mon, 19 Jul 2004 09:13:37 -0400
Received: from unity-15-148.mitre.org (129.83.15.148) by mailhub2.mitre.org with SMTP id 3716441; Mon, 19 Jul 2004 09:13:29 -0400
Message-ID: <[e-mail]>
Date: Mon, 19 Jul 2004 08:13:28 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christine Karman <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Request: Send me signed messages
References: <[e-mail]> <[e-mail]> <4.3.2.7.2.20040719124821.0280f818@localhost>
In-Reply-To: <4.3.2.7.2.20040719124821.0280f818@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Christine Karman wrote:

> How's that?
> If you accept encrypted email, then you can refuse unsigned email. 
> Besides, most of our customers use gateway decryption, which allows them 
> to do content scanning.

Um, the cert tends to have your (valid) email address in it.  (And 
support for certs without an rfc822Name is spotty at best.)

-- Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JAqAGP031515; Mon, 19 Jul 2004 03:52:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6JAqAVO031513; Mon, 19 Jul 2004 03:52:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JAq9X4031492; Mon, 19 Jul 2004 03:52:09 -0700 (PDT) (envelope-from [e-mail])
Received: from pengo (extra1.izecom.com [195.64.86.233]) by smtp-vbr13.xs4all.nl (8.12.11/8.12.11) with SMTP id i6JAq765010006; Mon, 19 Jul 2004 12:52:07 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <4.3.2.7.2.20040719124821.0280f818@localhost>
X-Sender: [e-mail]@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 19 Jul 2004 12:51:33 +0200
To: [e-mail], [e-mail]
From: Christine Karman <[e-mail]>
Subject: Re: Request: Send me signed messages
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="{3F37A849-88DC-48F3-9919-8C59370BA4BF}"
X-Izemail-Send-Version: 1.4.1.516 (POP3)
X-Virus-Scanned: by XS4ALL Virus Scanner
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--{3F37A849-88DC-48F3-9919-8C59370BA4BF}
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 09:43 PM 7/16/2004, Ed Gerck wrote:

>An obvious problem with email certificates is that they open us to spam.

How's that?
If you accept encrypted email, then you can refuse unsigned email. Besides, 
most of our customers use gateway decryption, which allows them to do 
content scanning.

dagdag
Christine

--
Izecom BV
Secure e-mail and digital signatures
www.izecom.com

if your outlook can't reply to a signed message, go to 
www.izecom.com/reply.html

--{3F37A849-88DC-48F3-9919-8C59370BA4BF}
Content-Type: application/x-pkcs7-signature; 
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIJ+YwYJKoZIhvcNAQcCoIJ+VDCCflACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCfF4w
ggH6MIIBYwICAaMwDQYJKoZIhvcNAQEEBQAwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBD
b3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdDAeFw05NjAyMjMyMzAxMDBa
Fw0wNjAyMjMyMzU5MDBaMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24x
HDAaBgNVBAMTE0dURSBDeWJlclRydXN0IFJvb3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
ALjmT7rbmHxxfK9Et9MPRtlk5ZPBQo7HukmNNS1654u95QUxWcaxLwoM+5+nP6IJZoRWHjcpG4fp
fgzKmp+lf/UVlKPVokaC2GhM0TcVBmivvfiws/Ap9ZVaCRZhdwoiJdRPRarHveWW3/nUqI5CzCTA
HpEnSrVtBoBjOcSiXjgDAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAErN1xl8d4WFVgADUgUt7MQ8j
Y+c98wP59Daou9njpZdN6isp4NZqc4HmwImj0/HgpaUiN5pjwkggtNty48j22Xy+sa9T2hS0IbjW
1Zbj/k4MWWK2mkr5Qt2Mb4Gpcf/0CnJtbUQOnfN0dKjVNEnpXp7ptHrh5VofhDCc05+lJdgwggI9
MIIBpgIRAM26f1bw3+S8VP4irLNyqlUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTI4MDgwMTIzNTk1OVowXzEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1
YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0fzGVuDLDQVoQY
h5oGmxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHiTkVWaR94AoDa3EeRKbs2yWNc
xeDXLYd7obcysHswuiovMaruo2fa2wIDAQABMA0GCSqGSIb3DQEBAgUAA4GBAEw/uIvGaN/uQzMO
XemmyweETXoz/5Ib9Dat2JUiNmgRbHxCzPOcLsQHPxSwD0//kJJ2+eK8SumPzaCACvfFKfGCIl24
sd2BI6N7JRVGMHkW+OoFS5R/HcIcyOO39BBAPBPDXx9T6EjkhrR7oTWweyW6uNOOqz84nQA0AJjz
0XGUMIIDYjCCAsugAwIBAgIQC9oLF8E/iY6rCXR6tM4uMzANBgkqhkiG9w0BAQIFADBfMQswCQYD
VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGlj
IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEy
MjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqB
S7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc
48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaOBsDCBrTAPBgNVHRMECDAGAQH/AgEA
MEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNv
bS9yZXBvc2l0b3J5L1JQQTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9wY2ExLmNybDALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBAgUA
A4GBAAJ9nm9FSziguN7pU2QhvORMK48e/pJArNgKOWqhMiEsB5urWf7SYhp9VTiwN3Pc9AdmY2K9
4VNwUofnqNhS6VstquHez6wxVNSLGcjYI6jvBCsyfSwYHMh8iagud/JE0WUKTXS17tMbknN0Lok7
NRNy50AxmtOyxKvnVr6L4/sVMIIDgTCCAmmgAwIBAgIRAK9oyzx6IyABA/lsASJjcVowDQYJKoZI
hvcNAQEFBQAwgYMxEjAQBgNVBAoTCUl6ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVt
YWlsLmNvbTEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYD
VQQGEwJOTDETMBEGA1UEAxMKSXplbWFpbCBDQTAeFw0wNDA3MDIxMzI1NThaFw0wNTA4MDkxMzI1
NThaMGwxCzAJBgNVBAYTAk5MMRIwEAYDVQQHEwlBbXN0ZXJkYW0xEDAOBgNVBAoTB2l6ZW1haWwx
IDAeBgkqhkiG9w0BCQEWEWl6ZW1haWxAeHM0YWxsLm5sMRUwEwYDVQQDEwxpemVtYWlsIHVzZXIw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALUhMm9LUQrLi84yO6NkKaR61aqySUIjs8YIyZfk
qMmPzj5akgD6pGs0lT45iiEiq54gsqjQM/i2z/ewq67L7elOpE5q2au4Qbw99u10QNPuk/o1EEOF
cuNCybnYib4YfZP7ZDjK+1lDELtiJEsXIZDEDPHBsZoHefaXPOSiRF6tAgMBAAGjgYkwgYYwCQYD
VR0TBAIwADA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8vd3d3Lml6ZWNvbS5jb20vaXplbWFpbC9p
emVtYWlsLjEuY3JsMBwGA1UdEQQVMBOBEWl6ZW1haWxAeHM0YWxsLm5sMB0GA1UdJQQWMBQGCCsG
AQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQUFAAOCAQEAVAzoUYQrRYeIqkp9RMvUtah7JYIv
/dLbLOHfzUSCl69ZsE5ViKgXiHZZnbCE7CmenF/uIr4/zhgHD8refpBMrA2w10adrHsDV2CJTYhJ
5XmXr++5454iqCIG3EJ6C4sDWo9S685iF+rv7tpWUim+zmhbcHcLLp9pJ4u7tQz+Zs9Rj4CdbXpe
UA8YRES4ahyw9rjUAs3aRXTxFUFrEFOrmM0UnXz9HjDeNTjHpFLS14jwXP/ymN8YaDzXaP06nTHS
HiP/BMnkBHgRtAIpVUzpCdO+BP61E9QEJ2KIgGZWveQWHvZB3stwVYPTmkICPAu0V7faiKwGY/fe
O+URP38XyTCCA4QwggJsoAMCAQICEQDKIGQhZRNna+i/El4nuWG0MA0GCSqGSIb3DQEBBQUAMIGD
MRIwEAYDVQQKEwlJemVjb20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFpbC5jb20xFjAU
BgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxEzAR
BgNVBAMTCkl6ZW1haWwgQ0EwHhcNMDQwMzEyMTQwMTI0WhcNMDUwNDE5MTQwMTI0WjBrMQswCQYD
VQQGEwJOTDESMBAGA1UEBxMJQW1zdGVyZGFtMRIwEAYDVQQKEwlJemVjb20gQlYxHjAcBgkqhkiG
9w0BCQEWD2luZm9AaXplY29tLmNvbTEUMBIGA1UEAxMLSW5mbyBJemVjb20wgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAO1S2s95QBpWP86MDekCIQqu9WjXTurDRV/qgq5Dx7ZjuJlrO+NlRRGM
/JjSOqZ0gAq14PSUm5HZfaorxANZxuw+g6+rd5kTUZZcWKca3yt+zc3h+xkF+AIrbcYAMxHSjYZP
6SvNsFn8TV1wcwRgo3GVxR1uUiXNJoBz44JSmqFDAgMBAAGjgY0wgYowDwYDVR0TBAgwBgEBAAIB
ADA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8vd3d3Lml6ZWNvbS5jb20vaXplbWFpbC9pemVtYWls
LjEuY3JsMBoGA1UdEQQTMBGBD2luZm9AaXplY29tLmNvbTAdBgNVHSUEFjAUBggrBgEFBQcDBAYI
KwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggEBAFt+s913of0Jm1T5Pw1Tyw6voXR0dYCW+aoXfjas
JKPNK0fIqo5QZPZpZj4XZ2mOaJfztu55xg8hojMrmragzJgArWcGqmM1HRrUjlr4QKbn0HmC7gwV
p/g2b187mWu9CIBHFmhyHxOSx6JsgX2ORXJYu+JL3sa5rLiK6iNzVNjN/aSlzQNdZaUxZ2WRq1p/
7BWCjP9zPN/bLhgP1nE5uTF2vQ1scvMn2J5Gt575FYeN9Xm59D1/Eu59q/I248AhR3gqrnS7u/ky
+zVsI0pp0q5RXHZDa5PlmuMNFef5CwbKere6hQSZ5GP2MWtPoHZvipfqvurM7/XMEP/VtH8Zlzgw
ggOHMIICb6ADAgECAhAWMW7s5NRjM+GG8hzGoth4MA0GCSqGSIb3DQEBBQUAMIGDMRIwEAYDVQQK
EwlJemVjb20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFpbC5jb20xFjAUBgNVBAgTDU5v
b3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxEzARBgNVBAMTCkl6
ZW1haWwgQ0EwHhcNMDQwNzA1MjA0NjEyWhcNMDUwODEyMjA0NjEyWjBxMQswCQYDVQQGEwJOTDEP
MA0GA1UEBxMGSHVpemVuMRIwEAYDVQQKEwlaYXBob2QgQlYxIjAgBgkqhkiG9w0BCQEWE2Nocmlz
dGluZUBrYXJtYW4ubmwxGTAXBgNVBAMTEENocmlzdGluZSBLYXJtYW4wgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBAKcx2YA0uKM0aXWukpbfrLj3ird+UNKTcpnG6h9ZncOOt3ZWfc7fZpEhNC8d
Fjk2meJeenNVjwfqeRuZCCmIROfYpyLl2s7GENUPoqo6lKjaYtU6O8GlLOY850BDv880vs8Szavm
zbkHQOd/mO8NTmObAnjdAzJJiGJ4ywF1/Yh5AgMBAAGjgYswgYgwCQYDVR0TBAIwADA8BgNVHR8E
NTAzMDGgL6AthitodHRwOi8vd3d3Lml6ZWNvbS5jb20vaXplbWFpbC9pemVtYWlsLjEuY3JsMB4G
A1UdEQQXMBWBE2NocmlzdGluZUBrYXJtYW4ubmwwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUF
BwMCMA0GCSqGSIb3DQEBBQUAA4IBAQAorgNK9BiyU48AcCw/ywgHuhkkhZ2LvFo+DE1GJdufaAcb
6Ko45tqCLQcIZNlLdX5zBH5uuPVaV7i9nkOk8A3dech2Zdv0V/3yfsFyHy8DUdmiH66qezEKwUkL
Zo4RoGT/Yi+FRxdUtMgek56YBhWlqCaXqZwUchbMfUN4WzV6fN159x2zhc6Uv+ktFnILLcNKvOpC
Cy+M5yDOeq6aiG0KOpuxy0ZiXPF3LHKEkBsdfSkzokFd9xda3vGVFa3e7gSCUv7QrYJdHIRtlq5n
szi98DYudJsBfkLOizWNn8F85XMb0yHBAyDTIO2Z+NcHhlMOy2XbvtmwxP3IEDcy1j8AMIIDjjCC
AnagAwIBAgIRANv4dRuNkzqiKDNkv8sV0R0wDQYJKoZIhvcNAQEFBQAwgY4xEjAQBgNVBAoTCUl6
ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNvbTEMMAoGA1UECBMDbi9hMRIw
EAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSgwJgYDVQQDEx9JemVtYWlsIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTA0MDExOTE2MTc1NloXDTA1MDExMTIzMDAwMFowaTELMAkGA1UE
BhMCTkwxEjAQBgNVBAcTCWFtc3RlcmRhbTENMAsGA1UEChMEbm9uZTEhMB8GCSqGSIb3DQEJARYS
WDEwX19fQGhvdG1haWwuY29tMRQwEgYDVQQDEwtXZW5keSBXZWJlcjCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAtTPyFNVgiHFXAeq3A1IB+QjHq1VffIS4loWiGAguoEKZD37WLpK7wjuBaN2f
ul4Fp99ORUSXlP3DRwJH2XnVwJAaGlHYz/k05nLS+XAP/Sy/hivYi6M+Am+IpDM4sYhZsRp7dofw
UclJNUjWrHAWN2R4EHiTQWxBQSV8A/zRrBECAwEAAaOBjjCBizAPBgNVHRMECDAGAQEAAgEAMDoG
A1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly93d3cuaXplY29tLmNvbS9pemVtYWlsL2l6ZW1haWwuY3Js
MB0GA1UdEQQWMBSBElgxMF9fX0Bob3RtYWlsLmNvbTAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYB
BQUHAwIwDQYJKoZIhvcNAQEFBQADggEBABhGlLSdO5r0yl9prOweu3krWAZA5obMTSkWA0azKR/2
u2OW5+8TS4CsLEQ2+I7iza1C7Qz62fuc+mcLBRGW0Zc5h0htbY50noAJhrWAmWHPcJtB6xVmyNg2
T5m80WE2xujRWFPeoj1ZeOzcuWoVeuTpxqgO/t1i1JJgYDsYCSMRdVE0ZkwP0THl3P+WnAiDJog2
y3aiN+CaVKrmKxlNdTr+5Hj3QKSf78MwDN62cjV4LMBa1YK2QhhsfeQWKW7Tq6RAZPaSbyzmncmB
mj10x+MtbiyElMc0PY0V1x4VoUvdIrAOZnjUkb8rgsIhqWDFf54oG3/L1X7lD2pj0qOwdyUwggOQ
MIICeKADAgECAhEA8bb9H6pp50jmGkQbFyVs8DANBgkqhkiG9w0BAQUFADCBgzESMBAGA1UEChMJ
SXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMRYwFAYDVQQIEw1Ob29y
ZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMRMwEQYDVQQDEwpJemVt
YWlsIENBMB4XDTA0MDUwNDE1NTUyOFoXDTA1MDYxMTE1NTUyOFowczELMAkGA1UEBhMCTkwxEjAQ
BgNVBAcTCUFtc3RlcmRhbTEQMA4GA1UEChMHaXplbWFpbDEiMCAGCSqGSIb3DQEJARYTbGljZW5z
ZUBpemVtYWlsLmNvbTEaMBgGA1UEAxMRSXplbWFpbCBsaWNlbnNpbmcwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBANtw+PIWiwmBSgp7DOdw7fV12nHM9DvzhyK3SGnnsVIL7qCz64vyLc+MVYV/
aTxVqu0j7s+uxmFyR36wwPjAdJnvOSyVd9cB0ZKByzAbgKhWfVUiEt7NhC0HDXa7yxMll8JvV1OI
M13caVKD6stM/n84abjKH+AIniYP2EKNDaPxAgMBAAGjgZEwgY4wDwYDVR0TBAgwBgEBAAIBADA8
BgNVHR8ENTAzMDGgL6AthitodHRwOi8vd3d3Lml6ZWNvbS5jb20vaXplbWFpbC9pemVtYWlsLjEu
Y3JsMB4GA1UdEQQXMBWBE2xpY2Vuc2VAaXplbWFpbC5jb20wHQYDVR0lBBYwFAYIKwYBBQUHAwQG
CCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBAQBeOiT+ZsP/fivt9J8ADDvSvTIGXuja4HuwUFZQ
Gg70FUkccBVedgGQPspfWwK61IJilCrjGiHzTcVKdbDEuX0hSuMjU0tZ1qQI6LRJjNOsS9+ui8Ke
gxYLGY4YwIlXCKYwslxDZKH5eFtN9GLZ/MiA4630uciywMO015bepJtNiGy/LPfDZuRFvEm2RLGp
5Gk4jh9v9o45rbnAdQh9EWQ0JkNxxNkjpxPqCMZ1Q9r8jVtUlXaxg2jyTgUniKX6Hsc6YQykB3wl
AAsVeiitoAK4FFlXvIAXzx85QbvARXX+sfpekrCb4WwZ7DkQqHeG2yMXmsiP2IBAcXhhJX84Eihf
MIIDkjCCAnqgAwIBAgIQTFu6Av1P0TWBAjiHCtoWWTANBgkqhkiG9w0BAQUFADCBgzESMBAGA1UE
ChMJSXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMRYwFAYDVQQIEw1O
b29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMRMwEQYDVQQDEwpJ
emVtYWlsIENBMB4XDTA0MDUwNDE0MDQyOFoXDTA1MDYxMTE0MDQyOFowdDELMAkGA1UEBhMCTkwx
EjAQBgNVBAcTCUFtc3RlcmRhbTEQMA4GA1UEChMHaXplbWFpbDEkMCIGCSqGSIb3DQEJARYVY2hy
aXN0aW5lQGl6ZW1haWwuY29tMRkwFwYDVQQDExBDaHJpc3RpbmUgS2FybWFuMIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDO3icNfM1EKNiU3Gkhy8AJXObNtWRtop78Yqpxr/KoHEvjQlLW2g6S
Q7QnxvPS5EV7kjda/nkpRTknyVLSy9zzPEYZ0LTpjjYEnLI0//QEK6MyKRdQmilz+Q+avnGDSFIG
9O8fMLVZZenTibAV3EZXF+mQ3dIExe9fVgwDYLEXtwIDAQABo4GTMIGQMA8GA1UdEwQIMAYBAQAC
AQAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL3d3dy5pemVjb20uY29tL2l6ZW1haWwvaXplbWFp
bC4xLmNybDAgBgNVHREEGTAXgRVjaHJpc3RpbmVAaXplbWFpbC5jb20wHQYDVR0lBBYwFAYIKwYB
BQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBAQB/k/ue+oOkz3q1h4c1Ijbv0tfo6kfG
c3XGCIcvG4s8RC/QohqrTQJ5BM/w4YtufKchQIR/mp8yY2l67F8V2pdr5FXxsX59pwb451NZ+crk
WA7elG95WxBT+i8fAhwS1SErVhOt3bMO/0m7eN2Z70sQ4eqFfl1rhbhD9X4VEXavvCfW9GtwP5aS
Dbuuwro2eQP5mQVn5dPCpHl6kAzFrPiSou+1MGiV+Gox7JTogbni3N7GylM9mhWn/+2cNok2i17P
uDNtQf8NjPCYQ8WPJXto3XOZXszWY5qYHPoQcZHl9QYivYQioIlpmLN0dTurKJuE7Hy+O4BKex0d
jPkxeVn6MIIDkjCCAnqgAwIBAgIQTFu6Av1P0TWBAjiHCtoWWTANBgkqhkiG9w0BAQUFADCBgzES
MBAGA1UEChMJSXplY29tIEJWMR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMRYwFAYD
VQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMRMwEQYD
VQQDEwpJemVtYWlsIENBMB4XDTA0MDUwNDE0MDQyOFoXDTA1MDYxMTE0MDQyOFowdDELMAkGA1UE
BhMCTkwxEjAQBgNVBAcTCUFtc3RlcmRhbTEQMA4GA1UEChMHaXplbWFpbDEkMCIGCSqGSIb3DQEJ
ARYVY2hyaXN0aW5lQGl6ZW1haWwuY29tMRkwFwYDVQQDExBDaHJpc3RpbmUgS2FybWFuMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDO3icNfM1EKNiU3Gkhy8AJXObNtWRtop78Yqpxr/KoHEvj
QlLW2g6SQ7QnxvPS5EV7kjda/nkpRTknyVLSy9zzPEYZ0LTpjjYEnLI0//QEK6MyKRdQmilz+Q+a
vnGDSFIG9O8fMLVZZenTibAV3EZXF+mQ3dIExe9fVgwDYLEXtwIDAQABo4GTMIGQMA8GA1UdEwQI
MAYBAQACAQAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL3d3dy5pemVjb20uY29tL2l6ZW1haWwv
aXplbWFpbC4xLmNybDAgBgNVHREEGTAXgRVjaHJpc3RpbmVAaXplbWFpbC5jb20wHQYDVR0lBBYw
FAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBAQB/k/ue+oOkz3q1h4c1Ijbv
0tfo6kfGc3XGCIcvG4s8RC/QohqrTQJ5BM/w4YtufKchQIR/mp8yY2l67F8V2pdr5FXxsX59pwb4
51NZ+crkWA7elG95WxBT+i8fAhwS1SErVhOt3bMO/0m7eN2Z70sQ4eqFfl1rhbhD9X4VEXavvCfW
9GtwP5aSDbuuwro2eQP5mQVn5dPCpHl6kAzFrPiSou+1MGiV+Gox7JTogbni3N7GylM9mhWn/+2c
Nok2i17PuDNtQf8NjPCYQ8WPJXto3XOZXszWY5qYHPoQcZHl9QYivYQioIlpmLN0dTurKJuE7Hy+
O4BKex0djPkxeVn6MIIDmTCCAoGgAwIBAgIRAKeR0C5POj1DS7I/H+1RU4wwDQYJKoZIhvcNAQEF
BQAwgY4xEjAQBgNVBAoTCUl6ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNv
bTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSgwJgYDVQQD
Ex9JemVtYWlsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMDkyOTA5NTYxM1oXDTA0MTAw
NTA5NTYxM1owcjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCWFtc3RlcmRhbTEPMA0GA1UEChMGaXpl
Y29tMSMwIQYJKoZIhvcNAQkBFhRjaHJpc3RpbmVAaXplY29tLmNvbTEZMBcGA1UEAxMQY2hyaXN0
aW5lIGthcm1hbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvMeT43uZD+4Iuo3WHApeGdDH
kMds8EUJopnwt6CGb8RvOA57/Jj7DPaSEJ7sYzSaG7/hs0EkAJP22glMdvF/HWWOXIwfCRlgJQuu
V18xlhidrvnHPC7id+ZF2llKYOpPMgYgmD0TPAkZrC/a/be2LrdGEo4LOZ1Lv8A5oBEpCbMCAwEA
AaOBkDCBjTAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDwYDVR0TBAgwBgEBAAIBADA6
BgNVHR8EMzAxMC+gLaArhilodHRwOi8vd3d3Lml6ZWNvbS5jb20vaXplbWFpbC9pemVtYWlsLmNy
bDAfBgNVHREEGDAWgRRjaHJpc3RpbmVAaXplY29tLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPCwt
n5fWFkkulP1Qcr4Csh3/dOX0MSdea9ytcZSyt3qHuPXtohTjLDIgs06dUfFUixg84cmCTUz6J0VQ
+X5iLsTWLSqsnLgAMnGkoi74P1NpF14Hc7lRwUFvZeAlrZfR95DOIZut9FjSUSkzSb+l93rf8VMv
wLf8Vw094ebYxSYHLnftzarEYzaKurmEbxE88awii4/zy0O5SNjL55uhssF10DNRiXA480XG+xkn
I4l37AbWrmShCQ2tG6Cn1LRk+gmAMZSIHIkLUpBvuCCH/jlH3hrmQPJ4QPxnyJMsoFD4sQfwpAGG
DhbxhxZlROLtiLRl0fHaOpdnF6cWL7VWPDCCA5wwggKEoAMCAQICEQD9iPEGreUnKhViN1t47Me5
MA0GCSqGSIb3DQEBBQUAMIGDMRIwEAYDVQQKEwlJemVjb20gQlYxHzAdBgkqhkiG9w0BCQEWEGlu
Zm9AaXplbWFpbC5jb20xFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRh
bTELMAkGA1UEBhMCTkwxEzARBgNVBAMTCkl6ZW1haWwgQ0EwHhcNMDQwNzAyMTMzOTExWhcNMDUw
ODA5MTMzOTExWjB7MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQW1zdGVyZGFtMQ8wDQYDVQQKEwZJ
emVjb20xLDAqBgkqhkiG9w0BCQEWHWNocmlzdGluZUBleGNoYW5nZS5pemVjb20uY29tMRkwFwYD
VQQDExBDaHJpc3RpbmUgS2FybWFuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCoZ5kxMcLc
P7Y+HaLur1TrJI3taGLC8AyMkhqJEnkqAjKZdNrOaz6UvcLk8kS1oDh8IfqydERMqc3YqA7r0Je+
Sx4yF2vhJz1xsD+lFoudDCYaFc2trCn1KeJZLlCZhp5Ahgx0F7bYz/y5cXaAqUAUzXjKE8ShIEt4
JI0NeJHHMwIDAQABo4GVMIGSMAkGA1UdEwQCMAAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL3d3
dy5pemVjb20uY29tL2l6ZW1haWwvaXplbWFpbC4xLmNybDAoBgNVHREEITAfgR1jaHJpc3RpbmVA
ZXhjaGFuZ2UuaXplY29tLmNvbTAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwDQYJKoZI
hvcNAQEFBQADggEBADuKmNoozkq4RkR2lHw/FpOQGOijr/i1YkHtngXh9IPGxLxRhRbL6eKA4/y+
5fLO1GqtHTizTQehu88l6EboqRcLySNxiLgg7M8QpO29L9EfJ6e3B+WWVtrBYWSzWoGQmOs7xcQd
2NdYglByDe1Y35YjLnXwXrjtj2SQ/T5KNTkZ15SIQ1e6FSDHvkz7qRj1FVEh/OKZt1msNaZV+wEF
/J1HShlEewSKkDbRNdtzHn+w9WDZhZ7dyrINQnDegkpYzCy4BlT9rZ3ks4APrgUcw2pO9XSgpNoO
YqX20eHygJ/kgWpmmwvUcIzPV5Hbgk1zqhYGg+Dj7f7I82lYWiPOy/swggOrMIICk6ADAgECAhEA
9+XuYyRdDqQqpEhPtyq8FzANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4w
HAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1z
dGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkwHhcNMDMwMTI5MTYyMDQ2WhcNMTYwMjAyMTYyMDQ2WjCBkTESMBAGA1UEChMJSXpl
Y29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAG
A1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQD1d6FaoPQA
ryNJ6kaXmYymfctZb3fQ9evlG1yQ/9G1UC7TxMg4CQgu+XHlKObac6pt1hQdq8hGAwujIjSBofy8
og2LEsOBv++C1NVCR3T2T5UYg4n+OrjQ+9ZDgFVEiZ3/SZsxiAB4+EVJCuBF8AuF3R76k3B4EQ7k
aD45iQSUZTp/kH5wfcseIyF8nskQkoaMwewUYYMCn+N5BNwr2JyoKD42pH8VP/HDp6Hfm5zEvkDv
iEW+iDTq7ybkwA4HZjtFPY08cChjLdYJ1h5JmZZidBrQZGfRYEK959B20vqYKQx/Bw/QQEFXZ2fP
6fP3dcTuWfTqPyBrDVsEwMSJsej7AgERMA0GCSqGSIb3DQEBBQUAA4IBAQCLt6PZessm/z3pSZ8H
VBKwLPzsxsGAfwgkMwo4NAb193WYQGRguu1JRqYyBgunXJj+MsvCgxr0Cbr7AvVSN4GKK/QJcfL4
rr24zUOdqt6dioMgk6gsn7ts2J8bbzK4+Jp6UJPco9IHhnTorqI5jZlNTZ43D4chALTqZH3HShJr
3vJZ/nUKyIpuP7ITYZR3x1S4RUyqIIcHkosAkaH8yyhqlUnKA5xFeHUkeFE86JyrM1c5lowvZETW
CWQkmy6Au6X1kbk60lpptDdPn15RUHnSYzwVeXkpmZEPhS7cs134nBRXB5RFDGmQDbcMH6E9xMvJ
DI/FUCvyJ1Z1F8+nciUHMIIDqzCCApOgAwIBAgIRAPfl7mMkXQ6kKqRIT7cqvBcwDQYJKoZIhvcN
AQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20u
Y29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNV
BAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMDEyOTE2MjA0NloX
DTE2MDIwMjE2MjA0NlowgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5m
b0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMC
TkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIDANBgkq
hkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEA9XehWqD0AK8jSepGl5mMpn3LWW930PXr5RtckP/RtVAu
08TIOAkILvlx5Sjm2nOqbdYUHavIRgMLoyI0gaH8vKINixLDgb/vgtTVQkd09k+VGIOJ/jq40PvW
Q4BVRImd/0mbMYgAePhFSQrgRfALhd0e+pNweBEO5Gg+OYkElGU6f5B+cH3LHiMhfJ7JEJKGjMHs
FGGDAp/jeQTcK9icqCg+NqR/FT/xw6eh35ucxL5A74hFvog06u8m5MAOB2Y7RT2NPHAoYy3WCdYe
SZmWYnQa0GRn0WBCvefQdtL6mCkMfwcP0EBBV2dnz+nz93XE7ln06j8gaw1bBMDEibHo+wIBETAN
BgkqhkiG9w0BAQUFAAOCAQEAi7ej2XrLJv896UmfB1QSsCz87MbBgH8IJDMKODQG9fd1mEBkYLrt
SUamMgYLp1yY/jLLwoMa9Am6+wL1UjeBiiv0CXHy+K69uM1DnarenYqDIJOoLJ+7bNifG28yuPia
elCT3KPSB4Z06K6iOY2ZTU2eNw+HIQC06mR9x0oSa97yWf51CsiKbj+yE2GUd8dUuEVMqiCHB5KL
AJGh/MsoapVJygOcRXh1JHhRPOicqzNXOZaML2RE1glkJJsugLul9ZG5OtJaabQ3T59eUVB50mM8
FXl5KZmRD4Uu3LNd+JwUVweURQxpkA23DB+hPcTLyQyPxVAr8idWdRfPp3IlBzCCA6swggKToAMC
AQICEQD35e5jJF0OpCqkSE+3KrwXMA0GCSqGSIb3DQEBBQUAMIGRMRIwEAYDVQQKEwlJemVjb20g
QlYxHjAcBgkqhkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQH
EwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTAeFw0wMzAxMjkxNjIwNDZaFw0xNjAyMDIxNjIwNDZaMIGRMRIwEAYDVQQK
EwlJemVjb20gQlYxHjAcBgkqhkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9h
MRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAPV3
oVqg9ACvI0nqRpeZjKZ9y1lvd9D16+UbXJD/0bVQLtPEyDgJCC75ceUo5tpzqm3WFB2ryEYDC6Mi
NIGh/LyiDYsSw4G/74LU1UJHdPZPlRiDif46uND71kOAVUSJnf9JmzGIAHj4RUkK4EXwC4XdHvqT
cHgRDuRoPjmJBJRlOn+QfnB9yx4jIXyeyRCShozB7BRhgwKf43kE3CvYnKgoPjakfxU/8cOnod+b
nMS+QO+IRb6INOrvJuTADgdmO0U9jTxwKGMt1gnWHkmZlmJ0GtBkZ9FgQr3n0HbS+pgpDH8HD9BA
QVdnZ8/p8/d1xO5Z9Oo/IGsNWwTAxImx6PsCAREwDQYJKoZIhvcNAQEFBQADggEBAIu3o9l6yyb/
PelJnwdUErAs/OzGwYB/CCQzCjg0BvX3dZhAZGC67UlGpjIGC6dcmP4yy8KDGvQJuvsC9VI3gYor
9Alx8viuvbjNQ52q3p2KgyCTqCyfu2zYnxtvMrj4mnpQk9yj0geGdOiuojmNmU1NnjcPhyEAtOpk
fcdKEmve8ln+dQrIim4/shNhlHfHVLhFTKoghweSiwCRofzLKGqVScoDnEV4dSR4UTzonKszVzmW
jC9kRNYJZCSbLoC7pfWRuTrSWmm0N0+fXlFQedJjPBV5eSmZkQ+FLtyzXficFFcHlEUMaZANtwwf
oT3Ey8kMj8VQK/InVnUXz6dyJQcwggOrMIICk6ADAgECAhEA9+XuYyRdDqQqpEhPtyq8FzANBgkq
hkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6
ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEs
MCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDMwMTI5MTYy
MDQ2WhcNMTYwMjAyMTYyMDQ2WjCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcNAQkB
Fg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYD
VQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEg
MA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQD1d6FaoPQAryNJ6kaXmYymfctZb3fQ9evlG1yQ
/9G1UC7TxMg4CQgu+XHlKObac6pt1hQdq8hGAwujIjSBofy8og2LEsOBv++C1NVCR3T2T5UYg4n+
OrjQ+9ZDgFVEiZ3/SZsxiAB4+EVJCuBF8AuF3R76k3B4EQ7kaD45iQSUZTp/kH5wfcseIyF8nskQ
koaMwewUYYMCn+N5BNwr2JyoKD42pH8VP/HDp6Hfm5zEvkDviEW+iDTq7ybkwA4HZjtFPY08cChj
LdYJ1h5JmZZidBrQZGfRYEK959B20vqYKQx/Bw/QQEFXZ2fP6fP3dcTuWfTqPyBrDVsEwMSJsej7
AgERMA0GCSqGSIb3DQEBBQUAA4IBAQCLt6PZessm/z3pSZ8HVBKwLPzsxsGAfwgkMwo4NAb193WY
QGRguu1JRqYyBgunXJj+MsvCgxr0Cbr7AvVSN4GKK/QJcfL4rr24zUOdqt6dioMgk6gsn7ts2J8b
bzK4+Jp6UJPco9IHhnTorqI5jZlNTZ43D4chALTqZH3HShJr3vJZ/nUKyIpuP7ITYZR3x1S4RUyq
IIcHkosAkaH8yyhqlUnKA5xFeHUkeFE86JyrM1c5lowvZETWCWQkmy6Au6X1kbk60lpptDdPn15R
UHnSYzwVeXkpmZEPhS7cs134nBRXB5RFDGmQDbcMH6E9xMvJDI/FUCvyJ1Z1F8+nciUHMIIDqzCC
ApOgAwIBAgIRAPfl7mMkXQ6kKqRIT7cqvBcwDQYJKoZIhvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6
ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQ
BgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMDEyOTE2MjA0NloXDTE2MDIwMjE2MjA0NlowgZExEjAQ
BgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQI
EwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBS
b290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKC
AQEA9XehWqD0AK8jSepGl5mMpn3LWW930PXr5RtckP/RtVAu08TIOAkILvlx5Sjm2nOqbdYUHavI
RgMLoyI0gaH8vKINixLDgb/vgtTVQkd09k+VGIOJ/jq40PvWQ4BVRImd/0mbMYgAePhFSQrgRfAL
hd0e+pNweBEO5Gg+OYkElGU6f5B+cH3LHiMhfJ7JEJKGjMHsFGGDAp/jeQTcK9icqCg+NqR/FT/x
w6eh35ucxL5A74hFvog06u8m5MAOB2Y7RT2NPHAoYy3WCdYeSZmWYnQa0GRn0WBCvefQdtL6mCkM
fwcP0EBBV2dnz+nz93XE7ln06j8gaw1bBMDEibHo+wIBETANBgkqhkiG9w0BAQUFAAOCAQEAi7ej
2XrLJv896UmfB1QSsCz87MbBgH8IJDMKODQG9fd1mEBkYLrtSUamMgYLp1yY/jLLwoMa9Am6+wL1
UjeBiiv0CXHy+K69uM1DnarenYqDIJOoLJ+7bNifG28yuPiaelCT3KPSB4Z06K6iOY2ZTU2eNw+H
IQC06mR9x0oSa97yWf51CsiKbj+yE2GUd8dUuEVMqiCHB5KLAJGh/MsoapVJygOcRXh1JHhRPOic
qzNXOZaML2RE1glkJJsugLul9ZG5OtJaabQ3T59eUVB50mM8FXl5KZmRD4Uu3LNd+JwUVweURQxp
kA23DB+hPcTLyQyPxVAr8idWdRfPp3IlBzCCA6swggKToAMCAQICEQD35e5jJF0OpCqkSE+3KrwX
MA0GCSqGSIb3DQEBBQUAMIGRMRIwEAYDVQQKEwlJemVjb20gQlYxHjAcBgkqhkiG9w0BCQEWD2lu
Zm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYT
Ak5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMzAx
MjkxNjIwNDZaFw0xNjAyMDIxNjIwNDZaMIGRMRIwEAYDVQQKEwlJemVjb20gQlYxHjAcBgkqhkiG
9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0x
CzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAPV3oVqg9ACvI0nqRpeZjKZ9y1lvd9D1
6+UbXJD/0bVQLtPEyDgJCC75ceUo5tpzqm3WFB2ryEYDC6MiNIGh/LyiDYsSw4G/74LU1UJHdPZP
lRiDif46uND71kOAVUSJnf9JmzGIAHj4RUkK4EXwC4XdHvqTcHgRDuRoPjmJBJRlOn+QfnB9yx4j
IXyeyRCShozB7BRhgwKf43kE3CvYnKgoPjakfxU/8cOnod+bnMS+QO+IRb6INOrvJuTADgdmO0U9
jTxwKGMt1gnWHkmZlmJ0GtBkZ9FgQr3n0HbS+pgpDH8HD9BAQVdnZ8/p8/d1xO5Z9Oo/IGsNWwTA
xImx6PsCAREwDQYJKoZIhvcNAQEFBQADggEBAIu3o9l6yyb/PelJnwdUErAs/OzGwYB/CCQzCjg0
BvX3dZhAZGC67UlGpjIGC6dcmP4yy8KDGvQJuvsC9VI3gYor9Alx8viuvbjNQ52q3p2KgyCTqCyf
u2zYnxtvMrj4mnpQk9yj0geGdOiuojmNmU1NnjcPhyEAtOpkfcdKEmve8ln+dQrIim4/shNhlHfH
VLhFTKoghweSiwCRofzLKGqVScoDnEV4dSR4UTzonKszVzmWjC9kRNYJZCSbLoC7pfWRuTrSWmm0
N0+fXlFQedJjPBV5eSmZkQ+FLtyzXficFFcHlEUMaZANtwwfoT3Ey8kMj8VQK/InVnUXz6dyJQcw
ggOrMIICk6ADAgECAhEA9+XuYyRdDqQqpEhPtyq8FzANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UE
ChMJSXplY29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24v
YTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3Qg
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDMwMTI5MTYyMDQ2WhcNMTYwMjAyMTYyMDQ2WjCB
kTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZIhvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAK
BgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXpl
Y29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAw
ggEIAoIBAQD1d6FaoPQAryNJ6kaXmYymfctZb3fQ9evlG1yQ/9G1UC7TxMg4CQgu+XHlKObac6pt
1hQdq8hGAwujIjSBofy8og2LEsOBv++C1NVCR3T2T5UYg4n+OrjQ+9ZDgFVEiZ3/SZsxiAB4+EVJ
CuBF8AuF3R76k3B4EQ7kaD45iQSUZTp/kH5wfcseIyF8nskQkoaMwewUYYMCn+N5BNwr2JyoKD42
pH8VP/HDp6Hfm5zEvkDviEW+iDTq7ybkwA4HZjtFPY08cChjLdYJ1h5JmZZidBrQZGfRYEK959B2
0vqYKQx/Bw/QQEFXZ2fP6fP3dcTuWfTqPyBrDVsEwMSJsej7AgERMA0GCSqGSIb3DQEBBQUAA4IB
AQCLt6PZessm/z3pSZ8HVBKwLPzsxsGAfwgkMwo4NAb193WYQGRguu1JRqYyBgunXJj+MsvCgxr0
Cbr7AvVSN4GKK/QJcfL4rr24zUOdqt6dioMgk6gsn7ts2J8bbzK4+Jp6UJPco9IHhnTorqI5jZlN
TZ43D4chALTqZH3HShJr3vJZ/nUKyIpuP7ITYZR3x1S4RUyqIIcHkosAkaH8yyhqlUnKA5xFeHUk
eFE86JyrM1c5lowvZETWCWQkmy6Au6X1kbk60lpptDdPn15RUHnSYzwVeXkpmZEPhS7cs134nBRX
B5RFDGmQDbcMH6E9xMvJDI/FUCvyJ1Z1F8+nciUHMIIDqzCCApOgAwIBAgIRAPfl7mMkXQ6kKqRI
T7cqvBcwDQYJKoZIhvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJ
ARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkG
A1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X
DTAzMDEyOTE2MjA0NloXDTE2MDIwMjE2MjA0NlowgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwG
CSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3Rl
cmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEA9XehWqD0AK8jSepGl5mMpn3L
WW930PXr5RtckP/RtVAu08TIOAkILvlx5Sjm2nOqbdYUHavIRgMLoyI0gaH8vKINixLDgb/vgtTV
Qkd09k+VGIOJ/jq40PvWQ4BVRImd/0mbMYgAePhFSQrgRfALhd0e+pNweBEO5Gg+OYkElGU6f5B+
cH3LHiMhfJ7JEJKGjMHsFGGDAp/jeQTcK9icqCg+NqR/FT/xw6eh35ucxL5A74hFvog06u8m5MAO
B2Y7RT2NPHAoYy3WCdYeSZmWYnQa0GRn0WBCvefQdtL6mCkMfwcP0EBBV2dnz+nz93XE7ln06j8g
aw1bBMDEibHo+wIBETANBgkqhkiG9w0BAQUFAAOCAQEAi7ej2XrLJv896UmfB1QSsCz87MbBgH8I
JDMKODQG9fd1mEBkYLrtSUamMgYLp1yY/jLLwoMa9Am6+wL1UjeBiiv0CXHy+K69uM1DnarenYqD
IJOoLJ+7bNifG28yuPiaelCT3KPSB4Z06K6iOY2ZTU2eNw+HIQC06mR9x0oSa97yWf51CsiKbj+y
E2GUd8dUuEVMqiCHB5KLAJGh/MsoapVJygOcRXh1JHhRPOicqzNXOZaML2RE1glkJJsugLul9ZG5
OtJaabQ3T59eUVB50mM8FXl5KZmRD4Uu3LNd+JwUVweURQxpkA23DB+hPcTLyQyPxVAr8idWdRfP
p3IlBzCCA6swggKToAMCAQICEQD35e5jJF0OpCqkSE+3KrwXMA0GCSqGSIb3DQEBBQUAMIGRMRIw
EAYDVQQKEwlJemVjb20gQlYxHjAcBgkqhkiG9w0BCQEWD2luZm9AaXplY29tLmNvbTEMMAoGA1UE
CBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQDEyNJemVjb20g
Um9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMzAxMjkxNjIwNDZaFw0xNjAyMDIxNjIw
NDZaMIGRMRIwEAYDVQQKEwlJemVjb20gQlYxHjAcBgkqhkiG9w0BCQEWD2luZm9AaXplY29tLmNv
bTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlBbXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSwwKgYDVQQD
EyNJemVjb20gUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQAD
ggENADCCAQgCggEBAPV3oVqg9ACvI0nqRpeZjKZ9y1lvd9D16+UbXJD/0bVQLtPEyDgJCC75ceUo
5tpzqm3WFB2ryEYDC6MiNIGh/LyiDYsSw4G/74LU1UJHdPZPlRiDif46uND71kOAVUSJnf9JmzGI
AHj4RUkK4EXwC4XdHvqTcHgRDuRoPjmJBJRlOn+QfnB9yx4jIXyeyRCShozB7BRhgwKf43kE3CvY
nKgoPjakfxU/8cOnod+bnMS+QO+IRb6INOrvJuTADgdmO0U9jTxwKGMt1gnWHkmZlmJ0GtBkZ9Fg
Qr3n0HbS+pgpDH8HD9BAQVdnZ8/p8/d1xO5Z9Oo/IGsNWwTAxImx6PsCAREwDQYJKoZIhvcNAQEF
BQADggEBAIu3o9l6yyb/PelJnwdUErAs/OzGwYB/CCQzCjg0BvX3dZhAZGC67UlGpjIGC6dcmP4y
y8KDGvQJuvsC9VI3gYor9Alx8viuvbjNQ52q3p2KgyCTqCyfu2zYnxtvMrj4mnpQk9yj0geGdOiu
ojmNmU1NnjcPhyEAtOpkfcdKEmve8ln+dQrIim4/shNhlHfHVLhFTKoghweSiwCRofzLKGqVScoD
nEV4dSR4UTzonKszVzmWjC9kRNYJZCSbLoC7pfWRuTrSWmm0N0+fXlFQedJjPBV5eSmZkQ+FLtyz
XficFFcHlEUMaZANtwwfoT3Ey8kMj8VQK/InVnUXz6dyJQcwggP8MIIC5KADAgECAhEAkRzEQl+3
lUGfoi109w5blTANBgkqhkiG9w0BAQUFADCBkTESMBAGA1UEChMJSXplY29tIEJWMR4wHAYJKoZI
hvcNAQkBFg9pbmZvQGl6ZWNvbS5jb20xDDAKBgNVBAgTA24vYTESMBAGA1UEBxMJQW1zdGVyZGFt
MQswCQYDVQQGEwJOTDEsMCoGA1UEAxMjSXplY29tIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkwHhcNMDMwMTI5MTYyMTI4WhcNMTQwMjAyMTYyMTI4WjCBjjESMBAGA1UEChMJSXplY29tIEJW
MR8wHQYJKoZIhvcNAQkBFhBpbmZvQGl6ZW1haWwuY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcT
CUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxKDAmBgNVBAMTH0l6ZW1haWwgQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQCo/rB7lTHtws4xQlQSA1DS
6V+1ghSjfDLiWfGqiTB7wOWOPge5jnSzV355jW65X2MNJTFYlXiyLM7627XtDlYfeIsZm0H8cHEl
RJoLJFGFHDkQ1H+YOUg/iTXTsRcufTvwP3ywbKe7AGdmi3pWXVWB6gJ81AtU1oJ7K+h/g3OUqh79
+Kd/zJuEAmfQrggDdeb335AW0ckOtyQ8FiISe0Op1wn7aOqvn0jKNDnnj5glsptTaBMXU54uQHEo
IrolZeyQUxvaRcfYG4UFxhMlfo9Dfp5WaJxasfLEFOmIOEmmJdbsMTyYFzgLo75Zd2SrHh4VuuoM
H22vPl5vOX6NFJsZAgERo1IwUDALBgNVHQ8EBAMCAQYwDwYDVR0TBAgwBgEB/wIBADARBglghkgB
hvhCAQEEBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUA
A4IBAQDxyi/r3gUlGF1xaGUMJ/9n9LCGW1brfpanQaZWmMGHr0l3G8eAysw7heZ8HlAG7mZcuzeR
maPNP+orJPzu8SgVkoMUajVXJf4n1FXbcDW2KrwsUjJ+dAD8qDCUoNXJin/UjSkS3+Bkl7MmcxDv
C6mpsySah0ggqWotP0z+/8WKXY0nDFu5PueyshCZxfvHISr9eoRlljZlVx1TNVslDmqG42k+FR+r
UJg+T8rgXpyieE6eusUB3Q9AorhksqFYfYy3oMetSVdn9ybxwfBK88GtJkH+KWNIi9onG5AEEIDO
wUcMR4bOZbexRAda2BSLcL0xdNY1S9Vb0xR7EfYkRiTPMIID/DCCAuSgAwIBAgIRAJEcxEJft5VB
n6ItdPcOW5UwDQYJKoZIhvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3
DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTEL
MAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5
MB4XDTAzMDEyOTE2MjEyOFoXDTE0MDIwMjE2MjEyOFowgY4xEjAQBgNVBAoTCUl6ZWNvbSBCVjEf
MB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNvbTEMMAoGA1UECBMDbi9hMRIwEAYDVQQHEwlB
bXN0ZXJkYW0xCzAJBgNVBAYTAk5MMSgwJgYDVQQDEx9JemVtYWlsIENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAqP6we5Ux7cLOMUJUEgNQ0ulf
tYIUo3wy4lnxqokwe8Dljj4HuY50s1d+eY1uuV9jDSUxWJV4sizO+tu17Q5WH3iLGZtB/HBxJUSa
CyRRhRw5ENR/mDlIP4k107EXLn078D98sGynuwBnZot6Vl1VgeoCfNQLVNaCeyvof4NzlKoe/fin
f8ybhAJn0K4IA3Xm99+QFtHJDrckPBYiEntDqdcJ+2jqr59IyjQ554+YJbKbU2gTF1OeLkBxKCK6
JWXskFMb2kXH2BuFBcYTJX6PQ36eVmicWrHyxBTpiDhJpiXW7DE8mBc4C6O+WXdkqx4eFbrqDB9t
rz5ebzl+jRSbGQIBEaNSMFAwCwYDVR0PBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwEQYJYIZIAYb4
QgEBBAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQUFAAOC
AQEA8cov694FJRhdcWhlDCf/Z/SwhltW636Wp0GmVpjBh69JdxvHgMrMO4XmfB5QBu5mXLs3kZmj
zT/qKyT87vEoFZKDFGo1VyX+J9RV23A1tiq8LFIyfnQA/KgwlKDVyYp/1I0pEt/gZJezJnMQ7wup
qbMkmodIIKlqLT9M/v/Fil2NJwxbuT7nsrIQmcX7xyEq/XqEZZY2ZVcdUzVbJQ5qhuNpPhUfq1CY
Pk/K4F6conhOnrrFAd0PQKK4ZLKhWH2Mt6DHrUlXZ/cm8cHwSvPBrSZB/iljSIvaJxuQBBCAzsFH
DEeGzmW3sUQHWtgUi3C9MXTWNUvVW9MUexH2JEYkzzCCBA0wggL1oAMCAQICEGbpGkSTndNOOyaq
KOfDmjIwDQYJKoZIhvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJ
ARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkG
A1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X
DTAzMTAwOTA5MzkyMloXDTE0MTAxMzA5MzkyMlowgYMxEjAQBgNVBAoTCUl6ZWNvbSBCVjEfMB0G
CSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNvbTEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAG
A1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDETMBEGA1UEAxMKSXplbWFpbCBDQTCCASAwDQYJ
KoZIhvcNAQEBBQADggENADCCAQgCggEBAJOSNF+ZX+6o5V+5PIlkc0cYfgR60EQk/lnN3pcdjhdQ
ZCD6WIMa324pPc9vgINzdsmun4daEPN13MZz+zrh2k/3jyhRFcwaN9Kan0nfkLhhEaffYgJ4JcXk
w8LWrXfOryDAe/18JWba246NL9xQuLxO86AR5zS+Q/iI8RW3BAWlWbzCU+3/EmUoczNt8q55V1WH
GguAuh/adnMmn2oNSlXtfq0lIKXnyrdesMVUBbkyTpdbVYhSXYhpQAjsFL0NG7oXApmObmh+aMDq
JRIzVI38txeIj0490A0v5Q+CnPs3gR0zSHuIj8jdRtdi7thkJfjQGO7eSjNMSt7Lw/i9fF8CARGj
bzBtMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly93d3cuaXplY29tLmNvbS9pemVtYWlsL2l6ZXJv
b3QuY3JsMAsGA1UdDwQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMBEGCWCGSAGG+EIBAQQEAwIBBjAN
BgkqhkiG9w0BAQUFAAOCAQEAn0lWlZfWnCuIqo5zsIT482QLsux4W162jSu2ZdGQJgi4A5VhnvrY
z0zieY4OpojtbuIymP0+PlpbWLdZuDnKkjU/GbF1gOLw2WevQa+4yXjh8K/fVGbUyyUsDbVEYHg2
9N/dF4gsojCYBf8kZT6zwQaF7rcmeziJiMqWMraxw6v/3rFp7TGYJLGJOl7yMNMi762yIhSc0L6U
fBdyNN1xrtcRLMFnf9TQPg9dyWC7+CellyykeykfNaqn5I/SXbN9Qu0da5egGaZ1Rx7WhgEvEox0
G4K4fz7SxUwhUxXGbwL02sD6Rkb8WZQ4GQyPk0H+dBCWOO8x3VDHIVbkp2NlATCCBA0wggL1oAMC
AQICEGbpGkSTndNOOyaqKOfDmjIwDQYJKoZIhvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBC
VjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcT
CUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MB4XDTAzMTAwOTA5MzkyMloXDTE0MTAxMzA5MzkyMlowgYMxEjAQBgNVBAoT
CUl6ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNvbTEWMBQGA1UECBMNTm9v
cmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDETMBEGA1UEAxMKSXpl
bWFpbCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAJOSNF+ZX+6o5V+5PIlkc0cY
fgR60EQk/lnN3pcdjhdQZCD6WIMa324pPc9vgINzdsmun4daEPN13MZz+zrh2k/3jyhRFcwaN9Ka
n0nfkLhhEaffYgJ4JcXkw8LWrXfOryDAe/18JWba246NL9xQuLxO86AR5zS+Q/iI8RW3BAWlWbzC
U+3/EmUoczNt8q55V1WHGguAuh/adnMmn2oNSlXtfq0lIKXnyrdesMVUBbkyTpdbVYhSXYhpQAjs
FL0NG7oXApmObmh+aMDqJRIzVI38txeIj0490A0v5Q+CnPs3gR0zSHuIj8jdRtdi7thkJfjQGO7e
SjNMSt7Lw/i9fF8CARGjbzBtMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly93d3cuaXplY29tLmNv
bS9pemVtYWlsL2l6ZXJvb3QuY3JsMAsGA1UdDwQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMBEGCWCG
SAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAn0lWlZfWnCuIqo5zsIT482QLsux4W162
jSu2ZdGQJgi4A5VhnvrYz0zieY4OpojtbuIymP0+PlpbWLdZuDnKkjU/GbF1gOLw2WevQa+4yXjh
8K/fVGbUyyUsDbVEYHg29N/dF4gsojCYBf8kZT6zwQaF7rcmeziJiMqWMraxw6v/3rFp7TGYJLGJ
Ol7yMNMi762yIhSc0L6UfBdyNN1xrtcRLMFnf9TQPg9dyWC7+CellyykeykfNaqn5I/SXbN9Qu0d
a5egGaZ1Rx7WhgEvEox0G4K4fz7SxUwhUxXGbwL02sD6Rkb8WZQ4GQyPk0H+dBCWOO8x3VDHIVbk
p2NlATCCBA0wggL1oAMCAQICEGbpGkSTndNOOyaqKOfDmjIwDQYJKoZIhvcNAQEFBQAwgZExEjAQ
BgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQI
EwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBS
b290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMTAwOTA5MzkyMloXDTE0MTAxMzA5Mzky
MlowgYMxEjAQBgNVBAoTCUl6ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNv
bTEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJO
TDETMBEGA1UEAxMKSXplbWFpbCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAJOS
NF+ZX+6o5V+5PIlkc0cYfgR60EQk/lnN3pcdjhdQZCD6WIMa324pPc9vgINzdsmun4daEPN13MZz
+zrh2k/3jyhRFcwaN9Kan0nfkLhhEaffYgJ4JcXkw8LWrXfOryDAe/18JWba246NL9xQuLxO86AR
5zS+Q/iI8RW3BAWlWbzCU+3/EmUoczNt8q55V1WHGguAuh/adnMmn2oNSlXtfq0lIKXnyrdesMVU
BbkyTpdbVYhSXYhpQAjsFL0NG7oXApmObmh+aMDqJRIzVI38txeIj0490A0v5Q+CnPs3gR0zSHuI
j8jdRtdi7thkJfjQGO7eSjNMSt7Lw/i9fF8CARGjbzBtMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6
Ly93d3cuaXplY29tLmNvbS9pemVtYWlsL2l6ZXJvb3QuY3JsMAsGA1UdDwQEAwIBBjAPBgNVHRME
CDAGAQH/AgEBMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAn0lWlZfWnCuI
qo5zsIT482QLsux4W162jSu2ZdGQJgi4A5VhnvrYz0zieY4OpojtbuIymP0+PlpbWLdZuDnKkjU/
GbF1gOLw2WevQa+4yXjh8K/fVGbUyyUsDbVEYHg29N/dF4gsojCYBf8kZT6zwQaF7rcmeziJiMqW
Mraxw6v/3rFp7TGYJLGJOl7yMNMi762yIhSc0L6UfBdyNN1xrtcRLMFnf9TQPg9dyWC7+Cellyyk
eykfNaqn5I/SXbN9Qu0da5egGaZ1Rx7WhgEvEox0G4K4fz7SxUwhUxXGbwL02sD6Rkb8WZQ4GQyP
k0H+dBCWOO8x3VDHIVbkp2NlATCCBA0wggL1oAMCAQICEGbpGkSTndNOOyaqKOfDmjIwDQYJKoZI
hvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVj
b20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAq
BgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMTAwOTA5Mzky
MloXDTE0MTAxMzA5MzkyMlowgYMxEjAQBgNVBAoTCUl6ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQ
aW5mb0BpemVtYWlsLmNvbTEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVy
ZGFtMQswCQYDVQQGEwJOTDETMBEGA1UEAxMKSXplbWFpbCBDQTCCASAwDQYJKoZIhvcNAQEBBQAD
ggENADCCAQgCggEBAJOSNF+ZX+6o5V+5PIlkc0cYfgR60EQk/lnN3pcdjhdQZCD6WIMa324pPc9v
gINzdsmun4daEPN13MZz+zrh2k/3jyhRFcwaN9Kan0nfkLhhEaffYgJ4JcXkw8LWrXfOryDAe/18
JWba246NL9xQuLxO86AR5zS+Q/iI8RW3BAWlWbzCU+3/EmUoczNt8q55V1WHGguAuh/adnMmn2oN
SlXtfq0lIKXnyrdesMVUBbkyTpdbVYhSXYhpQAjsFL0NG7oXApmObmh+aMDqJRIzVI38txeIj049
0A0v5Q+CnPs3gR0zSHuIj8jdRtdi7thkJfjQGO7eSjNMSt7Lw/i9fF8CARGjbzBtMDoGA1UdHwQz
MDEwL6AtoCuGKWh0dHA6Ly93d3cuaXplY29tLmNvbS9pemVtYWlsL2l6ZXJvb3QuY3JsMAsGA1Ud
DwQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQUF
AAOCAQEAn0lWlZfWnCuIqo5zsIT482QLsux4W162jSu2ZdGQJgi4A5VhnvrYz0zieY4OpojtbuIy
mP0+PlpbWLdZuDnKkjU/GbF1gOLw2WevQa+4yXjh8K/fVGbUyyUsDbVEYHg29N/dF4gsojCYBf8k
ZT6zwQaF7rcmeziJiMqWMraxw6v/3rFp7TGYJLGJOl7yMNMi762yIhSc0L6UfBdyNN1xrtcRLMFn
f9TQPg9dyWC7+CellyykeykfNaqn5I/SXbN9Qu0da5egGaZ1Rx7WhgEvEox0G4K4fz7SxUwhUxXG
bwL02sD6Rkb8WZQ4GQyPk0H+dBCWOO8x3VDHIVbkp2NlATCCBA0wggL1oAMCAQICEGbpGkSTndNO
OyaqKOfDmjIwDQYJKoZIhvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3
DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTEL
MAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5
MB4XDTAzMTAwOTA5MzkyMloXDTE0MTAxMzA5MzkyMlowgYMxEjAQBgNVBAoTCUl6ZWNvbSBCVjEf
MB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNvbTEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDES
MBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDETMBEGA1UEAxMKSXplbWFpbCBDQTCCASAw
DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAJOSNF+ZX+6o5V+5PIlkc0cYfgR60EQk/lnN3pcd
jhdQZCD6WIMa324pPc9vgINzdsmun4daEPN13MZz+zrh2k/3jyhRFcwaN9Kan0nfkLhhEaffYgJ4
JcXkw8LWrXfOryDAe/18JWba246NL9xQuLxO86AR5zS+Q/iI8RW3BAWlWbzCU+3/EmUoczNt8q55
V1WHGguAuh/adnMmn2oNSlXtfq0lIKXnyrdesMVUBbkyTpdbVYhSXYhpQAjsFL0NG7oXApmObmh+
aMDqJRIzVI38txeIj0490A0v5Q+CnPs3gR0zSHuIj8jdRtdi7thkJfjQGO7eSjNMSt7Lw/i9fF8C
ARGjbzBtMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly93d3cuaXplY29tLmNvbS9pemVtYWlsL2l6
ZXJvb3QuY3JsMAsGA1UdDwQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMBEGCWCGSAGG+EIBAQQEAwIB
BjANBgkqhkiG9w0BAQUFAAOCAQEAn0lWlZfWnCuIqo5zsIT482QLsux4W162jSu2ZdGQJgi4A5Vh
nvrYz0zieY4OpojtbuIymP0+PlpbWLdZuDnKkjU/GbF1gOLw2WevQa+4yXjh8K/fVGbUyyUsDbVE
YHg29N/dF4gsojCYBf8kZT6zwQaF7rcmeziJiMqWMraxw6v/3rFp7TGYJLGJOl7yMNMi762yIhSc
0L6UfBdyNN1xrtcRLMFnf9TQPg9dyWC7+CellyykeykfNaqn5I/SXbN9Qu0da5egGaZ1Rx7WhgEv
Eox0G4K4fz7SxUwhUxXGbwL02sD6Rkb8WZQ4GQyPk0H+dBCWOO8x3VDHIVbkp2NlATCCBA0wggL1
oAMCAQICEGbpGkSTndNOOyaqKOfDmjIwDQYJKoZIhvcNAQEFBQAwgZExEjAQBgNVBAoTCUl6ZWNv
bSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYDVQQIEwNuL2ExEjAQBgNV
BAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNvbSBSb290IENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MB4XDTAzMTAwOTA5MzkyMloXDTE0MTAxMzA5MzkyMlowgYMxEjAQBgNV
BAoTCUl6ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWlsLmNvbTEWMBQGA1UECBMN
Tm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQGEwJOTDETMBEGA1UEAxMK
SXplbWFpbCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAJOSNF+ZX+6o5V+5PIlk
c0cYfgR60EQk/lnN3pcdjhdQZCD6WIMa324pPc9vgINzdsmun4daEPN13MZz+zrh2k/3jyhRFcwa
N9Kan0nfkLhhEaffYgJ4JcXkw8LWrXfOryDAe/18JWba246NL9xQuLxO86AR5zS+Q/iI8RW3BAWl
WbzCU+3/EmUoczNt8q55V1WHGguAuh/adnMmn2oNSlXtfq0lIKXnyrdesMVUBbkyTpdbVYhSXYhp
QAjsFL0NG7oXApmObmh+aMDqJRIzVI38txeIj0490A0v5Q+CnPs3gR0zSHuIj8jdRtdi7thkJfjQ
GO7eSjNMSt7Lw/i9fF8CARGjbzBtMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly93d3cuaXplY29t
LmNvbS9pemVtYWlsL2l6ZXJvb3QuY3JsMAsGA1UdDwQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMBEG
CWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAn0lWlZfWnCuIqo5zsIT482QLsux4
W162jSu2ZdGQJgi4A5VhnvrYz0zieY4OpojtbuIymP0+PlpbWLdZuDnKkjU/GbF1gOLw2WevQa+4
yXjh8K/fVGbUyyUsDbVEYHg29N/dF4gsojCYBf8kZT6zwQaF7rcmeziJiMqWMraxw6v/3rFp7TGY
JLGJOl7yMNMi762yIhSc0L6UfBdyNN1xrtcRLMFnf9TQPg9dyWC7+CellyykeykfNaqn5I/SXbN9
Qu0da5egGaZ1Rx7WhgEvEox0G4K4fz7SxUwhUxXGbwL02sD6Rkb8WZQ4GQyPk0H+dBCWOO8x3VDH
IVbkp2NlATCCBA0wggL1oAMCAQICEGbpGkSTndNOOyaqKOfDmjIwDQYJKoZIhvcNAQEFBQAwgZEx
EjAQBgNVBAoTCUl6ZWNvbSBCVjEeMBwGCSqGSIb3DQEJARYPaW5mb0BpemVjb20uY29tMQwwCgYD
VQQIEwNuL2ExEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxLDAqBgNVBAMTI0l6ZWNv
bSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAzMTAwOTA5MzkyMloXDTE0MTAxMzA5
MzkyMlowgYMxEjAQBgNVBAoTCUl6ZWNvbSBCVjEfMB0GCSqGSIb3DQEJARYQaW5mb0BpemVtYWls
LmNvbTEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFtMQswCQYDVQQG
EwJOTDETMBEGA1UEAxMKSXplbWFpbCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEB
AJOSNF+ZX+6o5V+5PIlkc0cYfgR60EQk/lnN3pcdjhdQZCD6WIMa324pPc9vgINzdsmun4daEPN1
3MZz+zrh2k/3jyhRFcwaN9Kan0nfkLhhEaffYgJ4JcXkw8LWrXfOryDAe/18JWba246NL9xQuLxO
86AR5zS+Q/iI8RW3BAWlWbzCU+3/EmUoczNt8q55V1WHGguAuh/adnMmn2oNSlXtfq0lIKXnyrde
sMVUBbkyTpdbVYhSXYhpQAjsFL0NG7oXApmObmh+aMDqJRIzVI38txeIj0490A0v5Q+CnPs3gR0z
SHuIj8jdRtdi7thkJfjQGO7eSjNMSt7Lw/i9fF8CARGjbzBtMDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly93d3cuaXplY29tLmNvbS9pemVtYWlsL2l6ZXJvb3QuY3JsMAsGA1UdDwQEAwIBBjAPBgNV
HRMECDAGAQH/AgEBMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAn0lWlZfW
nCuIqo5zsIT482QLsux4W162jSu2ZdGQJgi4A5VhnvrYz0zieY4OpojtbuIymP0+PlpbWLdZuDnK
kjU/GbF1gOLw2WevQa+4yXjh8K/fVGbUyyUsDbVEYHg29N/dF4gsojCYBf8kZT6zwQaF7rcmeziJ
iMqWMraxw6v/3rFp7TGYJLGJOl7yMNMi762yIhSc0L6UfBdyNN1xrtcRLMFnf9TQPg9dyWC7+Cel
lyykeykfNaqn5I/SXbN9Qu0da5egGaZ1Rx7WhgEvEox0G4K4fz7SxUwhUxXGbwL02sD6Rkb8WZQ4
GQyPk0H+dBCWOO8x3VDHIVbkp2NlATCCBKYwggQPoAMCAQICEEm37F5FJz8qGOv9ksJlf90wDQYJ
KoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln
biBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB
IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx
IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwMTA2
MDAwMDAwWhcNMDUwMTA4MjM1OTU5WjCCARgxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl
cG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJz
b25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29m
dCBGdWxsIFNlcnZpY2UxGTAXBgNVBAMUEENocmlzdGluZSBLYXJtYW4xIzAhBgkqhkiG9w0BCQEW
FGNocmlzdGluZUBpemVjb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDt1WIJAFJ4
IvN6Xa7sprhg59d67dhehDP+dB5wTX9ETUMx1SeQKhnapWJW/S4AeE679Ltzfkg4IlxraYhmicz3
VG0t36GOMCJK67VkNI5HAaO6SbT/Pc9qLvkZJdJSmkAcwrr47A1RJtxhjX4LSTWzDBDYnkVcdpVa
K/xHNIpyBQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF
AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEF
BQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkg
cmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDAG
CmCGSAGG+EUBBgcEIhYgNDFiZDdiMGMxNTk3ZmE1ZmI5ZWQ5NTU0NDMyYmJhMTQwMwYDVR0fBCww
KjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF
AAOBgQAZBYHKvkBY4BpxiDlPU0Ej9YPvFffrT2Jm8GuLUhaiNseE0g6tDi+fhdPj8x8Wm3zyUy1U
H227njkAjJN6hkhKCg/vogQbgyIF7ORsQya30bHpoX8yG53KNMQE8S+qlKZRPLWKOcg62wyezjRs
SzvsINsp9J7i01gxO2Aj/hhplDCCBMgwggQxoAMCAQICBAIAApswDQYJKoZIhvcNAQEFBQAwRTEL
MAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVy
VHJ1c3QgUm9vdDAeFw0wMjA4MjcxOTA3MDBaFw0wNjAyMjMyMzU5MDBaMIHcMQswCQYDVQQGEwJH
QjEXMBUGA1UEChMOQ29tb2RvIExpbWl0ZWQxHTAbBgNVBAsTFENvbW9kbyBUcnVzdCBOZXR3b3Jr
MUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBvZiB1c2U6IGh0dHA6Ly93d3cuY29tb2Rv
Lm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYykyMDAyIENvbW9kbyBMaW1pdGVkMSwwKgYDVQQD
EyNDb21vZG8gQ2xhc3MgMyBTZWN1cml0eSBTZXJ2aWNlcyBDQTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBALEeYGbgQwaeJ2gvApnHiN+F69tl7NRJZ3ouH83cFSzWHqzynUY6XQPAPQUs
WhgNWSVCo3LArSjSrTwx4ksH+16Y66gz1mmyWp7qLEmmJi5M8MyrQNKq3ixOgbW6e7hc0Hu9R/XA
BtLA5NdH22JAr6EcUQMY27jQu5THPHnqJWSuJhnhPGZHZ5Kde1WrNMJ1btknjp2M8B3aa5yGBKKQ
teqdjM/7OUOo8BgtnvcZECycL+HQsf/XWcTNQDL514HbURzyQVKBQbGDuMgJ/pkiR4BPnMuu4CjV
HKxwR7Alq6E4Qhdr+mpujV95+PYpAzCkbkbUhV2qQJk4dtseAX3lDKUCAwEAAaOCAacwggGjMEUG
A1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93d3cucHVibGljLXRydXN0LmNvbS9jZ2ktYmluL0NSTC8y
MDA2L2NkcC5jcmwwHQYDVR0OBBYEFPZSIhcVEwgDWb8YlZ9ItLnp/vhmMIGSBgNVHSAEgYowgYcw
SQYKKoZIhvhjAQIBBTA7MDkGCCsGAQUFBwIBFi1odHRwOi8vd3d3LnB1YmxpYy10cnVzdC5jb20v
Q1BTL09tbmlSb290Lmh0bWwwOgYMKwYBBAGyMQECAQMBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v
c2VjdXJlLmNvbW9kby5uZXQvQ1AwWAYDVR0jBFEwT6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNV
BAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwKwYD
VR0QBCQwIoAPMjAwMjA4MjcxOTA3MzFagQ8yMDA1MDIyMzIzNTkwMFowDgYDVR0PAQH/BAQDAgHm
MA8GA1UdEwQIMAYBAf8CAQAwDQYJKoZIhvcNAQEFBQADgYEAtqewenGL4LqzgR42MnqGGNbxq005
CHEGWmegSwHlMEBtibWeFaqxx/QKxlwO6TfeqJfH3M7Ncft0AgfcXxUnCFMHdtS5BunCd1Aeysmw
wkaBgACtRKpc1iDZVTK+Vpbx6r2g47wNgDrqzPuaV+14pTY9VurR53TKNMPPsVHp4AwwggV6MIIE
YqADAgECAhEAnytBMGb8ejNXdO1SevpL3zANBgkqhkiG9w0BAQUFADCB3DELMAkGA1UEBhMCR0Ix
FzAVBgNVBAoTDkNvbW9kbyBMaW1pdGVkMR0wGwYDVQQLExRDb21vZG8gVHJ1c3QgTmV0d29yazFG
MEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u
ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMiBDb21vZG8gTGltaXRlZDEsMCoGA1UEAxMj
Q29tb2RvIENsYXNzIDMgU2VjdXJpdHkgU2VydmljZXMgQ0EwHhcNMDQwNTEwMDAwMDAwWhcNMDUw
NTEwMjM1OTU5WjCB4DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5P
VCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDov
L3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0
ZWQxGTAXBgNVBAMTEENocmlzdGluZSBLYXJtYW4xIzAhBgkqhkiG9w0BCQEWFGNocmlzdGluZUBp
emVjb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDME34pF9A6lo1iaFrD9G8NhNMa
fomtO8xd4TQiBUlEthWWUctIuYS/JTyembCVM+WDkKuSDBZ/weTJNii49ERcfV9xN90BCyZ+do1q
oTRb0DYyvwq60Ap7IQd6f6LqPV6RLoQkOL+vcygQ4CIO4dvz6v9Ek9Bon4CCoK15hho46wIDAQAB
o4IBszCCAa8wHwYDVR0jBBgwFoAU9lIiFxUTCANZvxiVn0i0uen++GYwHQYDVR0OBBYEFOJBJQ/E
+V7WGdFfLEYJZBOJyqyDMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG
CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG
AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzCBsAYDVR0fBIGoMIGlMDigNqA0
hjJodHRwOi8vY3JsLmNvbW9kby5uZXQvQ2xhc3MzU2VjdXJpdHlTZXJ2aWNlc18yLmNybDA6oDig
NoY0aHR0cDovL2NybC5jb21vZG9jYS5jb20vQ2xhc3MzU2VjdXJpdHlTZXJ2aWNlc18yLmNybDAt
oCugKYEnQ2xhc3MzU2VjdXJpdHlTZXJ2aWNlc18yQGNybC5jb21vZG8ubmV0MBEGCWCGSAGG+EIB
AQQEAwIFIDAfBgNVHREEGDAWgRRjaHJpc3RpbmVAaXplY29tLmNvbTANBgkqhkiG9w0BAQUFAAOC
AQEAXiuAsCipKZVyyg5cJrgn8a1hRIbxEsqAMDFOeEwUiwHwa4SwtvmJnpTermSLUIa2ObLq6hf+
ODYknuHFISQlC0nY92XficF6Nz3tRvo11CU89/wovFcncSjhrrMqo67CjcKAKcGqf96WC8VL72F+
SUF1QL2NIlVGqrBdo6/FQxZ86p6m1WnsNo73V+N2NudMWB5hqvSK0IVbyBJtvDgFzZmqCjsyK1vW
S7STMvU0StiKN2zzkg20rrqbaUJHpVJwWavcPRe65nAqnje5X8qDvCugo+CMdSckflHMeBxm85rg
VIe60Q/jdeepxdWtjxQOA4YUtvUdVtlzwRGDb/wYcTGCAc0wggHJAgEBMIGYMIGDMRIwEAYDVQQK
EwlJemVjb20gQlYxHzAdBgkqhkiG9w0BCQEWEGluZm9AaXplbWFpbC5jb20xFjAUBgNVBAgTDU5v
b3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTELMAkGA1UEBhMCTkwxEzARBgNVBAMTCkl6
ZW1haWwgQ0ECEExbugL9T9E1gQI4hwraFlkwCQYFKw4DAhoFAKCBizAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA3MTkxMDUyMDhaMCMGCSqGSIb3DQEJBDEWBBSK
3xxsOqnmUCXkl3X8Ue0Mu+IaZzAsBgkqhkiG9w0BCQ8xHzAdMA8GCCqGSIb3DQMCMAMCATowCgYI
KoZIhvcNAwcwDQYJKoZIhvcNAQEBBQAEgYBP+QT4y46F/TPMrHxJu63rl+zauRGQU9xXM1Jm6m7T
3ruTB6UKH+e/XM/JOHfC/ognCrG325VICXmxpBhJuuB1Drc1JNs1zqabnNzdTAtTtYjw7ozamg/E
PNUs2VowKpB+qNNw2v1Q0axy5F2BOU2o/xNstuzLQ4NSpP4WH8ca5A==

--{3F37A849-88DC-48F3-9919-8C59370BA4BF}--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J9tCfV009368; Mon, 19 Jul 2004 02:55:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6J9tC8R009367; Mon, 19 Jul 2004 02:55:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-2-sn3.vrr.skanova.net (av1-2-sn3.vrr.skanova.net [81.228.9.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J9tCiB009319 for <[e-mail]>; Mon, 19 Jul 2004 02:55:12 -0700 (PDT) (envelope-from [e-mail])
Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 6D2C837EC5; Mon, 19 Jul 2004 11:55:07 +0200 (CEST)
Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 5FD6337E43; Mon, 19 Jul 2004 11:55:07 +0200 (CEST)
Received: from arport (t10o913p74.telia.com [213.64.27.194]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id 4209438005; Mon, 19 Jul 2004 11:55:05 +0200 (CEST)
Message-ID: <004001c46d76$11c554d0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Manger, James H" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
Date: Mon, 19 Jul 2004 11:52:12 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Requiring that there only be a single serialNumber attribute, however,
>is unnecessarily restrictive.  It seems quite sensible to use serialNumber
>attributes to hold company numbers, org unit ids and/or personal identifiers. 
>For example: cn="John Doe" serialNumber=12345, o="Acme Ltd" 
>serialNumber="DUNS 554433", c=US.  The PI extension would refer to 12345.

I believe examples like this are very good in order to achieve some
genuine understanding (beyond ASN.1).

But is this not actually a prime example of a scheme using TWO PIs?

This would however also require an updated specification where
something like an optional "instanceNumber" would be featured to
point out the actual serialNumber to use.

Anders



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J9KT35093904; Mon, 19 Jul 2004 02:20:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6J9KT12093903; Mon, 19 Jul 2004 02:20:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.2wire.ch (mail.2wire.ch [62.65.128.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J9KO6n093825 for <[e-mail]>; Mon, 19 Jul 2004 02:20:27 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 41765 invoked by uid 89); 19 Jul 2004 09:20:17 -0000
Received: from unknown (HELO swisssign.com) (62.65.151.222) by mail.2wire.ch with SMTP; 19 Jul 2004 09:20:17 -0000
Message-ID: <[e-mail]>
Date: Mon, 19 Jul 2004 11:20:07 +0200
From: Joseph Doekbrijder <[e-mail]>
Organization: SwissSign AG
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-ch, en-us, en, fr-ch
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Ed Gerck <[e-mail]>, [e-mail]
Subject: Re: Request: Send me signed messages
References: <002101c46b50$342174a0$[e-mail]> <[e-mail]> <p06110403bd1de535f889@[10.20.30.249]> <p06110412bd1df2a828b0@[128.89.89.75]>
In-Reply-To: <p06110412bd1df2a828b0@[128.89.89.75]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080902030006090102000008"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms080902030006090102000008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Interesting issue, which leaves me with a question:
The only thing a spammer can not do (or maybe only once) is digitally 
sign his spam! Upon abuse, The cert can be put on the receivers 
"black-list", the cert could be revoked by CA and/or RA and the 
IssuingParty can be contacted if abuse continues...
Would it thus not be an interesting approach to build a mail filter that 
filters out all non digitally signed email?
It is clear, this is something for the future, but from a theoretical 
point-of-view: Some feedback from the experts out there would be 
interesting for me. In other words, can we take this any further?

Cheers

Josh

Stephen Kent wrote:

>
> I view Peter's solicitation for signed e-mail to be appropriate for 
> the PKIX WG list.
>
> Steve
>

-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: [phone] / Mobile: [phone]
www.swisssign.com
--------------------------------------------------

This message has been digitally signed to ensure unaltered and 
authenticated reception. Should you receive an error message regarding 
the validity of the signature, please click and download the SwissSign 
root certificate using the following link  https://swisssign.net/trust/
After installation, your mail client will be able to automatically 
verify the authenticity of e-mail messages sent to you by users of 
SwissSign certificates.


--------------ms080902030006090102000008
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWiTCC
A2EwggJJoAMCAQICCGQgZ70rBHuyMA0GCSqGSIb3DQEBBQUAMGkxIzAhBgNVBAMTGlN3aXNz
U2lnbiBQZXJzb25hbCBHb2xkIENBMSEwHwYJKoZIhvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5j
b20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMjExMTQzOTA1WhcN
MDQxMjExMTQzOTA1WjB4MSQwIgYDVQQDExtKb3NlcGggQW50b25pdXMgRG9la2JyaWpkZXIx
LzAtBgkqhkiG9w0BCQEWIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMRIwEAYD
VQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQCpc7LucWH/EP2YmDBOMZVmPzy8JfYovxAL8wbfuXjFQLg4/orh+8AonyozzaK0fJzFw/D4
46z3siNvu065E6AKM3BFPSsyS5RrUPnYjtxcLAmfv+OsR5gAMA1hhsS571XCWaVPvEuCIltW
RvpcKVeuAsdpR6p7eW7UPQuO0EgR4QIDAQABo4GBMH8wHwYDVR0jBBgwFoAU8jaGz72k1nnf
MpmM0FlpHQWVLIYwDgYDVR0PAQH/BAQDAgQwMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQGCCsG
AQUFBwMEMCsGA1UdEQQkMCKBIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMA0G
CSqGSIb3DQEBBQUAA4IBAQBY4/HrZkMYrF0LKNWpDrYTbEM7wRjHKtpjMHWb1DlAm1qRBWAB
0Ns/jyCHLedGlRydHuVPh+THO9PPgRESIWoWq88uz+gpue3A4DWpuk7BqrYKXFfKTa1uKsfE
L62LJ0cO8Q09aCkkEpETL8u92s68328QPhSgFmX5wgToyG3Vw2EOMTcbCeKFRYSkZTywe2NV
IMkDKKUDuRYBYZZ1Db8P3SzF26bszuUH+4HsbgIg8K+mrEeln9aHpbujAUVx8huCpYR25Ziz
rtK2vHmDd2VQUfOs+gA4dns7Ys+sOYXYWn2ZvXycCirQktDuaOTAxRXrBXByGLTNDsJBsNQI
FbZdMIIDqTCCApGgAwIBAgIIXLEyej+EomAwDQYJKoZIhvcNAQEFBQAwZDEcMBoGA1UEAxMT
U3dpc3NTaWduIFNpbHZlciBDQTEjMCEGCSqGSIb3DQEJARYUc2lsdmVyQHN3aXNzc2lnbi5j
b20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMDEyMTEzODIyWhcN
MTUxMDA2MTMzNjU3WjBgMRowGAYDVQQDExFTd2lzc1NpZ24gR29sZCBDQTEhMB8GCSqGSIb3
DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYT
AkNIMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAstKfzDugVAxC63Qhl8+Cko7T
Kjh0aMls6o0iYfPE6LU9jRHGRE2FyEoI4+3EgotNIVEX7GOTtQUL3YRzkJ55T/urzNtWDead
etokNxoH1KrYObxIuFeSyepEN/QKcNedliNqwGF3wPqKCGna554QeyV44pRhvNH3+hFL3Mz3
Tazf2wtmE/et/JSAFFUPWfSqrugURE1G2kaB9o2tt/BFtEjslSD41D9g7nexjvgHDyRKsoY3
FoEHexV/ttvFZNzGJJ7NLwgC84JvCdLi3RvNyGfiWnqkjuRdQOohAsWNJcjn7aoksB5y/Ipr
BjsivtY/LBYQ7zq+Sc8v+8bf3T1lzwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUtGz1MEEswDyRjDQnY/pVvPzntD8wHwYDVR0jBBgwFoAU
EvoMgVv/f9El2B5zMDUPRhg2snUwDQYJKoZIhvcNAQEFBQADggEBADG0plqQXp/SAJjFJYax
q1R+3LaDheER1IgXaIem+nofwcBaCvEP+vkWkEuBwFbvI97tKlO6oY1WtVlJHbkfHXcvRAiv
s8W9EbuQlXJ9g1J+ZKJbnI/KmTwsNYvHj5PBe9+PwvA1oZwTJDEEBSaUcdOxaNw3ceka7oTd
dWXfAWUhGXDmS3O2yTHVovUrFAshmYEz9r4YRvbUzkKYcP12zOu2UmdrCOzSWua2EOuSimLM
se00IOJTlhJMfL+ly6O8G1MA7wTqKkSgnDbVe0XsMQYmSJaiVqSkRGIUYE7mvlq9YKCguBZ1
fpmurO0BeWvmzZxZT/7VBjcfMzwS1tZ4CeAwggOuMIIClqADAgECAggQSAsMRGstRTANBgkq
hkiG9w0BAQUFADBgMRowGAYDVQQDExFTd2lzc1NpZ24gR29sZCBDQTEhMB8GCSqGSIb3DQEJ
ARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNI
MB4XDTAzMTAxMjExNTgyMloXDTA2MTAxMjExNTgyMlowaTEjMCEGA1UEAxMaU3dpc3NTaWdu
IFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNvbTES
MBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAMZmnWhcHmQ8GZB+9uoZyb+LmqUqYRWWL6vSFwWMSQdtn7aMT0zVI1N37y2I
LN5/KurG53SonxgMfwqsxgdD3jI77yyJwsN0aMdBDotcL+pXSJqlC1gpDsVHtMIyQs5PqYTx
Y3uUJVbBERchLFLv/2VJ0iBGXg009lyNVULa9VFcG/F2UF34YranOWBW4OSQowf1kJYNXr4A
eKhpLnNhv30/fdIMRrihygQCPaMJ0nQAEuBVbFSfOUQPvMDDBwYKC+yMkcm5QWgnVGXAeyrA
x7k8+rKPfNbYqnyeL9aAnyUMkYm6FtUsaM5I6HNWJY63gfqqPeprFuogZNY1Rwq2mNMCAwEA
AaNjMGEwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPI2hs+9
pNZ53zKZjNBZaR0FlSyGMB8GA1UdIwQYMBaAFLRs9TBBLMA8kYw0J2P6Vbz857Q/MA0GCSqG
SIb3DQEBBQUAA4IBAQCuHGJh9r2LiKenYuA4Imi1TZ0YWVB0o2Kfo6HD3CPZwavyPzXiShM0
0PGIoX/bs+K36PYj24E6gdp78B4hzqPP525wUapDy/WX8nur8XbrcdEwffWy+Cmz593an7Xy
iFl18wIDGLGkpGpwtM/Jiu2QLUughU7Eh0/i6R1+oUPLF9wYcB0eoYnDBK0KWFvTEWkLAWYb
F45PV4tsBXWI+UTQBB93rgdjQbJNxSv7K/kLAQY/mWs9fF2jp4X8+UMthm28TkHE7VAok0md
Ma9x3X1ZrMDmb3ijkUxwJhFewelg9vMZdcXUHjezw5J83L5I8aBQmfKIHLDEg2XVcQUhMi/B
MIIDwDCCAqigAwIBAgIJAOjyHqbBu/cuMA0GCSqGSIb3DQEBBQUAMHYxCzAJBgNVBAYTAkNI
MRIwEAYDVQQKEwlTd2lzc1NpZ24xMjAwBgNVBAMTKVN3aXNzU2lnbiBDQSAoUlNBIElLIE1h
eSA2IDE5OTkgMTg6MDA6NTgpMR8wHQYJKoZIhvcNAQkBFhBjYUBTd2lzc1NpZ24uY29tMB4X
DTAzMTAwNjEzMzY1N1oXDTE1MTAwNjEzMzY1N1owZDEcMBoGA1UEAxMTU3dpc3NTaWduIEJy
b256ZSBDQTEjMCEGCSqGSIb3DQEJARYUYnJvbnplQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoT
CVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDA0TvGY7vE2Z2U4Ootl3tb6AZN4SPTTN6HYMyzL9OeKWzlMfnwJqEzv4yjkFMcaStrmyRO
PMkwLEWcd3FiaxKBmr0eCN9ybgZuhKvSxYfaqcM5QAgPqK6yA2WQ+sgWAUlEH4PdhCUYd84q
eOlswzzrtbggVWQsbh/LoT7edOeBJlDiIHufmmXTl5X7psFIImkWJbnegd7fidhRuUxMJF0X
LcA/9WaJzZDZSmGONRSP+WOzlM/o4xunjPwIoCWKSIo9NMWtJ29az01/TcLehpyMjQg7a+PJ
3yFtl5PbS25Jm7W9IopISNPGYzucjOIVKYo9BQ5F32lGn8NJl418yNttAgMBAAGjYzBhMA4G
A1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRygIjtngs9r6moa09a
F+LUoY5lJDAfBgNVHSMEGDAWgBSW13HNOSrU/IixiqtTeGnvj0d+FjANBgkqhkiG9w0BAQUF
AAOCAQEApFfZjNGeQ7OtxCPI3mI1rjF2gbxMTMtMeJeaxH2QSJsrvcKRQ29v0wzDLMmeKFR8
d3B8PDh8aqw2IGz1X3FcIn7CUTdoOvFCGuW0SpdvKzgt3RVOpp4HFcfMK6mxubSHCBV6f66A
UyxbK+Sv7Rpwn3BZ6AYndMzYMEk6IrAvrurIz6h2DTrwEO3oH1GKRpYljlcoh+mKEnvZit6b
vGNcLpLTMZNe+0dlKzw1uHNI9gqteNqn/BqunMDAqPcBX4uZ0em7P/ZJ8+SACnsz96+R5MSV
EeoFqWQoRQAxNgjUXTy0xYa4cGRqeXtTO/s3mKgDBWktCFXU0f0kb0IQIBmGqDCCA/gwggLg
oAMCAQICCQDemCdyDdsdVTANBgkqhkiG9w0BAQUFADBkMRwwGgYDVQQDExNTd2lzc1NpZ24g
QnJvbnplIENBMSMwIQYJKoZIhvcNAQkBFhRicm9uemVAc3dpc3NzaWduLmNvbTESMBAGA1UE
ChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDAeFw0wMzEwMTIxMTM2MzJaFw0xNTEwMDYxMzM2
NTdaMGQxHDAaBgNVBAMTE1N3aXNzU2lnbiBTaWx2ZXIgQ0ExIzAhBgkqhkiG9w0BCQEWFHNp
bHZlckBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzPdBfCH+e+kxpt0cSTkKm1pJXXdRCNJ8
mrbsNpuX2O290pzz1dEF7DKFCH+k9bm8Yqj1KgyhKrt7JoNGUHW83sU+8jjrYG/ZPrfusCH+
4iiVZciBCvPdM1t0qvPZvWrKVYdIb+3t8aQz8+L08zFLdkxG49M+4cMW5srECPy4YJ3kJzVr
awrXBMAchqviMngsyWuKw5qV5FA9pp36wDsumItoZXL3BOsMsU2lh3z/OLhDpXA5D83mgEOW
RbqkfSWyaT1lcIuoMZ/XMdT8ahU+3GWnZ8O9tQFg0//SfrlT3Zsp7Hhx0XEtsuIKQZTrsUHj
QzR+bk9RlKLz3Sy5nxPRRQIDAQABo4GsMIGpMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E
BTADAQH/MB0GA1UdDgQWBBQS+gyBW/9/0SXYHnMwNQ9GGDaydTAfBgNVHSMEGDAWgBRygIjt
ngs9r6moa09aF+LUoY5lJDBGBgNVHR8EPzA9MDugOaA3hjVodHRwczovL3N3aXNzc2lnbi5u
ZXQvY2dpLWJpbi9hdXRob3JpdHkvY3JsP2NhPUJyb256ZTANBgkqhkiG9w0BAQUFAAOCAQEA
qaVWxVi644azmxYNNglkRVA5pFsU3zN4zepYrjEmamFgGROsNKYCwf06cGDHXsJyxZzkzFPG
FTR5/pRLoDWnEuFgfm+a6XA9qTUecun+909Dkz8EbNk/KsWaGEG+HxMjwnusctjeWhO32rRH
+AWJW9VhNR+ggbkGwbVadRClY7359ChoWTwkySWb2hjTZU3BOnqAOYJ2QPKiWMrGODN9Jo94
+hfxcD6o08ak5KY/5Bza4EEL/sbS/quhoCZsg8TBD4+KeXgbVqU9XlPHk/gq1RTy49SPmRkQ
lgwFSvQRRAD/5oQX3ZKxhXAVsEYHyGvqCsFvXWKagulb5NjNdD0pyTCCBAEwggLpoAMCAQIC
CQCVT/juYWAhTDANBgkqhkiG9w0BAQUFADBpMSMwIQYDVQQDExpTd2lzc1NpZ24gUGVyc29u
YWwgR29sZCBDQTEhMB8GCSqGSIb3DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQK
EwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMB4XDTAzMTIxMDIxNDAwMVoXDTA0MTIxMDIxNDAw
MVoweDEkMCIGA1UEAxMbSm9zZXBoIEFudG9uaXVzIERvZWticmlqZGVyMS8wLQYJKoZIhvcN
AQkBFiBqb3NlcGguZG9la2JyaWpkZXJAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NT
aWduMQswCQYDVQQGEwJDSDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJVGvsFb
4Ufs++D4cxTnv2yHvmLjKZQ2qfPT7YO2dfffZbiba4qkKQ8xLE05D1EqlLvXm+4dRksjDhty
OzwZeWajZ/TGwPgP3jXOURlqkyhVrX0kt5EzW5EokcMC/Ais422LqtJ5kq2nOvK7NGYtevS0
pMbHi5NZtkWUwVZaRjjOJaTGO2xDkjAOdYIyI8vdEIedJIW6LGHIZsYjI+yW7sUlI6hCXhrV
nsmdu/shG/TTsvDQUW28Yl7/l/uvikFsuy4erDKDHcbth/xKsI/KkfX40jGqGI0SlQ7fHBph
DwbnbOKJJSu1wgMT1dvuwLyFEBqyf0OSPZROpK11T3d2LdcCAwEAAaOBnDCBmTAfBgNVHSME
GDAWgBTyNobPvaTWed8ymYzQWWkdBZUshjAOBgNVHQ8BAf8EBAMCA8gwKQYDVR0lBCIwIAYI
KwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3FAICMDsGA1UdEQQ0MDKgMAYKKwYBBAGCNxQC
A6AiDCBqb3NlcGguZG9la2JyaWpkZXJAc3dpc3NzaWduLmNvbTANBgkqhkiG9w0BAQUFAAOC
AQEAZTUBqQgk5nB+0W7Mozv/uD6lRurjZhWShstlaQ43qvVHcsDgb4mW/bynla9BDmM/NsQU
43ZsoFxjkJsxFCpgm5BuMt1KuD7FSHJ0mxRswaGf9mHxftU1cu/YhY/AjrsFHEnsPHZaYAAm
jcKunHgT+yckvUZR3RQDkgVE4PQ3YpsG1EPKQSEAFbmWAd4+TxJmuBXThDM63gOkY4Q7gE1b
Y1kjkdRlJ2TZ/gOItQ3AsfwS7mq+ANYnUBrWkrnUd85Nmgzv5ys7zxuz9tp64vS+xYW98mri
ruGl9stN/b7SbOFTsp8SUm83e9qPOQZRYPS6TYYKUObj3LbaXJEIqKD51DGCA2IwggNeAgEB
MHYwaTEjMCEGA1UEAxMaU3dpc3NTaWduIFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0B
CQEWEmdvbGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJD
SAIJAJVP+O5hYCFMMAkGBSsOAwIaBQCgggHBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTA0MDcxOTA5MjAxM1owIwYJKoZIhvcNAQkEMRYEFGCT59u8lXmH
LUFia3r6w/c+XqpCMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGEBgkrBgEEAYI3
EAQxdzB1MGkxIzAhBgNVBAMTGlN3aXNzU2lnbiBQZXJzb25hbCBHb2xkIENBMSEwHwYJKoZI
hvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UE
BhMCQ0gCCGQgZ70rBHuyMIGGBgsqhkiG9w0BCRACCzF3oHUwaTEjMCEGA1UEAxMaU3dpc3NT
aWduIFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNv
bTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSAIIZCBnvSsEe7IwDQYJKoZIhvcN
AQEBBQAEggEAhsbskbeaasmC7KiKDxCcHq/Wf1EXkYpGRUWbOqeXxdxCzplxpx2BICW4XgGd
+BveCmZRsZbWtHx/6DfLMjUJhelWpptCi8koNE/oAwm5l4ijHgu4eDyJsQ5KL+5+aoovVQsY
yZYsTnlGVgQyOgJasqFq5ddZXM67m5PBRp1LVUXqmnYMj6PXwLvT+JMpSHQtPOlVdEewPl8U
iS0/3qV82bIYVq3wdANbC5mN6bbQdPsjCThyRuNw+PqbDx064fQHdDUU6oN07lqKD6QpQ3MV
wfbEiDpswJYvsgcRi0j8tzRdAl+PdwO63YDPj8UTc1u3gqmhHhTgqjnIwf+gJg4SVAAAAAAA
AA==
--------------ms080902030006090102000008--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J58DVR079231; Sun, 18 Jul 2004 22:08:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6J58D6D079230; Sun, 18 Jul 2004 22:08:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.vtcif.telstra.com.au (mailbo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J58Cs8079178 for <[e-mail]>; Sun, 18 Jul 2004 22:08:13 -0700 (PDT) (envelope-from [e-mail])
Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailbo.vtcif.telstra.com.au (Postfix) with ESMTP id 8103D23198 for <[e-mail]>; Mon, 19 Jul 2004 15:08:12 +1000 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 22C851DA82 for <[e-mail]>; Mon, 19 Jul 2004 15:08:12 +1000 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA01964 for <[e-mail]>; Mon, 19 Jul 2004 15:08:11 +1000 (EST)
content-class: urn:content-classes:message
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
Date: Mon, 19 Jul 2004 15:07:53 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: I-D ACTION:draft-ietf-pkix-pi-10.txt
Thread-Index: AcRpISpRw39Rj0boTiKQ1oDDudjrzgEIUs5Q
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6J58Ds8079225
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

1.
The ability to flag a serialNumber attribute value in the subject name as a permanent identifier is a nice feature.  Requiring that there only be a single serialNumber attribute, however, is unnecessarily restrictive.  It seems quite sensible to use serialNumber attributes to hold company numbers, org unit ids and/or personal identifiers.  For example: cn="John Doe" serialNumber=12345, o="Acme Ltd" serialNumber="DUNS 554433", c=US.  The PI extension would refer to 12345.

[Section 2] Change the ASN.1 comment for the identifierValue field of PermanentIdentifier to:
" -- if absent, use the deepest serialNumber attribute value in the subject DN"

[Section 2] Change the paragraph that begins "When the identifierValue field is absent" to:
"When the identifierValue field is absent, then the deepest serialNumber attribute value from the subject DN is the value to be taken for the identifierValue.  An attribute is "deeper" if it occurs later in the sequence of RDNs that make up the DN.  A "deeper" attribute occurs earlier in the string representation of a DN [RFC2253], which start encoding the last element of the RDN sequence that makes up a DN and moves backwards towards the first.  The PermanentIdentifier SHALL NOT be used if there is no serialNumber attribute in the subject DN.



2.
Why can't the assigner field be present but the identifierValue field be absent (refer to the serialNumber attribute)?  An absent identifierValue is simply "shorthand" to avoid duplicating a value -- it doesn't really have any sematic value so shouldn't have any impact on the assigner field (or vice versa).



3.
The security considerations section mentions an identifierType field that no longer exists.


> ----------
> From: 	[e-mail] [mailto:[e-mail]] 
> Sent:	Wednesday, 14 July 2004 6:05 AM
> 
> 	Title		: Internet X.509 Public Key Infrastructure Permanent Identifier
> 	Author(s)	: D. Pinkas, T. Gindin
> 	Filename	: draft-ietf-pkix-pi-10.txt
> 	Date		: 2004-7-13
> 	
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-10.txt
> 
> 	----------
> 	From: 	Denis Pinkas [mailto:[e-mail]] 
> 	Sent:	Thursday, 15 July 2004 6:06 PM
> 	Cc:	[e-mail]
> 
		... the definition of the PI has been changed to allow to use the serialNumber attribute from the subject DN.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6I8jiL3064410; Sun, 18 Jul 2004 01:45:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6I8jiAb064408; Sun, 18 Jul 2004 01:45:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-1-sn4.m-sp.skanova.net (av7-1-sn4.m-sp.skanova.net [81.228.10.110]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6I8jgjw064305 for <[e-mail]>; Sun, 18 Jul 2004 01:45:43 -0700 (PDT) (envelope-from [e-mail])
Received: by av7-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 612C337EB9; Sun, 18 Jul 2004 10:45:31 +0200 (CEST)
Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av7-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 51FC737E46; Sun, 18 Jul 2004 10:45:31 +0200 (CEST)
Received: from arport (t12o913p98.telia.com [213.64.28.218]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with SMTP id A4D8E37E46; Sun, 18 Jul 2004 10:45:27 +0200 (CEST)
Message-ID: <001001c46ca3$2f126420$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: "David Kemp" <[e-mail]>, "Denis Pinkas" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-10.txt
Date: Sun, 18 Jul 2004 10:42:35 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,
It is good to see that the PI draft is doing progress!

May I comment a bit on this last revision?

>After side discussions initiated by Anders Rundgren and followed
>by Peter Gutmann, I have discussed with my co-editor, the PKIX
>chairs and the security Area Director.

I would like to mention that David Kemp, in his quest for a more
"sane" (Dave's wording) solution for DoD, also posted a scheme
that eliminated the data redundancy or alien CA registry requirements
that my "real world, paper example" :-) showed.  Dave's suggestion
was BTW pretty close to the proposed revision.

Talking about DoD's use of PIs, I do not believe that their current scheme
is "insane" but maybe a tiny, tiny bit "ugly".  A simple RFC3739 "filtering"
process would be enough to make it "beautiful", in X.500 terms.

It is not over until it is over
====================

However, when I performed another "real world, paper example"
on a PI-augmented DoD scheme, I did note a rather significant
loss of "sanity" that I believe the list could comment on as it should
be fairly applicable to most enterprise PKIs.

Assume that a DoD certificate after the PI upgrade contains the following:

Subject DN: CN=John Smith, serialNumber=123456, OU=Army, O=DoD, C=US
PI assigner: 1.23.67.355.23.6.7        (A "sample" OID for the DEERS registry)

The question I tried to answer was simply: How is automated relying
party software supposed to use the enhanced identity information?
Here follows three possible alternatives:

1. X.500-only
==========
ID: CN=John Smith, serialNumber=123456, OU=Army, O=DoD, C=US

This scheme becomes (at least principally) dubious, the moment you start
to deal with multiple assigners (=independent name spaces).   And if you
only intend to use one assigner, the PI extension becomes redundant.


2. X.500 + PI
==========
ID: 1.23.67.355.23.6.7 + CN=John Smith, serialNumber=123456, OU=Army, O=DoD, C=US

This scheme is not exploiting the primary motive for using permanent
identifiers, attribute independence (=being able to change name, location
etc. without getting a "new" identity).


3. PI-only
=======
ID: 1.23.67.355.23.6.7 + 123456

This scheme makes all but one DN attribute redundant.  But the
unused attributes still contribute to shortening the life-time of the
certificate, as well as limiting usage to a single assignment (you will
need a separate certificate for each assignment within the enterprise).


As far as I can see, PI extensions when applied to a large class of
X.500-based systems[1] will probably only add more confusion to
an already complex situation, rather than solving a problem.

Sincerely
Anders Rundgren


1] it is worth noting that PKIs that were designed from scratch to use
PIs (there are several large such), do not suffer from these problems.
However, these PKIs do not follow the X.500 methodology where
an identity is the combination of a set of hierarchical attributes, qualifying
the subject.  In my opinion, the idea that an LDAP entry for an employee
should be linked to a certificate containing a [redundant] copy of the
directory path, is an off-line world relic.  In an on-line world, subject
attributes like location, phone number, bank account, job function etc.
should be dynamically acquired, as well as adapted for the actual
situation and relation.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GNCBtS061614; Fri, 16 Jul 2004 16:12:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GNCBeW061612; Fri, 16 Jul 2004 16:12:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GNC95h061603 for <[e-mail]>; Fri, 16 Jul 2004 16:12:09 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6GNC9897299; Fri, 16 Jul 2004 16:12:09 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Tim Polk" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Fri, 16 Jul 2004 16:11:28 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

I think a face-to-face is useful in this instance.

Mike


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Tim Polk
Sent: Friday, July 16, 2004 7:39 AM
To: Michael Myers; Russ Housley; [e-mail]
Subject: RE: Unsigned DPD responses for SCVP15



Mike,

Why delay to San Diego?

Really, it makes no sense to require a DPV client to be capable of
asserting a flag that will incur a response it cannot hope to
process!!!  That is the result if a client that does not implement path
validation asserts that flag!

I strongly believe that:

(1) some clients will be DPV-only since they will not include an X.509
path
validation module, and need not implement the flag at all;

(2) some clients will be designed for unsigned DPD only, and will be
hard-wired to assert the flag; and

(3) some clients will support unsigned DPD as well asat least one of (a)
signed DPD and (b) DPV, and will need to implement flag and provide
configuration

Let's forward a spec that reflects this reality.

Tim

At 03:14 PM 7/15/2004 -0700, Michael Myers wrote:
>Russ,
>
>Seems a matter for San Diego at this point.
>
>Mike
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Russ Housley
>Sent: Wednesday, July 14, 2004 2:10 PM
>To: Michael Myers; Tim Polk; [e-mail]
>Subject: RE: Unsigned DPD responses for SCVP15
>
>
>
>Mike:
>
>Recently, I have done a fair amount of work in the wireless space, and
I
>am
>convinced that clients on these devices with limited processing
>capabilities will make use of DPV.  So, maybe what we need is a profile
>at
>the end of the document that lists the features that must be
implemented
>to
>be considered a DPV client, a DPV server, a DPD client, and a DPD
>server.  This should be pretty easy to put together, although I doubt
>that
>it can be done before the draft deadline for the San Diego meeting.
>
>Russ
>
>At 04:03 PM 7/14/2004, Michael Myers wrote:
> >I'm not sure that can be predicted to such a degree.
> >
> >When Carlisle Adams, Stephen Farrell and I first addressed introduced
> >DPV and DPD to the WG, it was Stephen who was forceful in convincing
> >Carlisle and I that one of the most difficult issues wrt PKI was
simply
> >acquiring the data necessary to path validation.  This was due in no
> >small part to the various protocols and schemas associated with that
> >process, as now amply documented in 3379.  Further, a "client" is not
> >just, for example, a web browser.  It could be amalgamation of back
> >office mechanisms, AAA, Radius and what have you.  I suspect there
>might
> >come to exist a non-trivial number of such instances.
> >
> >Also, are you saying that in your view an SCVP client is compliant if
>it
> >fails to allow use of id-stc-build-pkc-path in CertChecks syntax and
> >id-swb-pkc-cert-path and id-swb-pkc-revocation-info in the WantBack
> >syntax?
> >
> >Mike
> >
> >-----Original Message-----
> >From: Russ Housley [mailto:[e-mail]]
> >Sent: Wednesday, July 14, 2004 12:37 PM
> >To: Michael Myers; Tim Polk; [e-mail]
> >Subject: RE: Unsigned DPD responses for SCVP15
> >
> >
> >I do not accept your assumption.  I expect many clients to be
DPV-only.
> >
> >Russ
> >
> >At 03:31 PM 7/14/2004, Michael Myers wrote:
> > >True, SCVP clients that assert the OID that drives a server to
>produce
> >a
> > >validity assertion MUST accept and process a signature.  But
assuming
> > >that same client is also implemented to assert simply a return of
> >{path,
> > >rev-info}, then it seems reasonable to assume it should also be
>capable
> > >of asserting the flag.
> > >
> > >
> > >Mike





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GL3LEA040438; Fri, 16 Jul 2004 14:03:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GL3Lol040437; Fri, 16 Jul 2004 14:03:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GL3Kd0040418 for <[e-mail]>; Fri, 16 Jul 2004 14:03:20 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i6GL3G7X001855; Fri, 16 Jul 2004 17:03:16 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06110412bd1df2a828b0@[128.89.89.75]>
In-Reply-To: <p06110403bd1de535f889@[10.20.30.249]>
References: <002101c46b50$342174a0$[e-mail]> <[e-mail]> <p06110403bd1de535f889@[10.20.30.249]>
Date: Fri, 16 Jul 2004 17:03:11 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Request: Send me signed messages
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I view Peter's solicitation for signed e-mail to be appropriate for 
the PKIX WG list.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GJkFIH028283; Fri, 16 Jul 2004 12:46:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GJkFUs028282; Fri, 16 Jul 2004 12:46:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail5.atl.registeredsite.com ([e-mail] [64.224.219.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GJkFYB028263; Fri, 16 Jul 2004 12:46:15 -0700 (PDT) (envelope-from [e-mail])
Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail5.atl.registeredsite.com (8.12.11/8.12.8) with ESMTP id i6GJkIGD027520; Fri, 16 Jul 2004 19:46:18 GMT
Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Fri, 16 Jul 2004 14:46:14 -0500
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 2004 12:43:14 -0700
From: Ed Gerck <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Hesse <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Request: Send me signed messages
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Hesse wrote:

> Obviously before I share the collected certificates with any other
> researchers, I will require a similar promise for those researchers to keep
> the email addresses therein confidential.  

Peter,

An obvious problem with email certificates is that they open us to spam.
You promised you will not share (emails) what you promised to share (certs
with emails).  I am glad you agree your two promises were not consistent.

Also, please take a look at your message in the PKIX archive:
http://www.imc.org/ietf-pkix/mail-archive/msg02908.html
You will notice that PKIX protects your email address.

Of course, I am familiar with your name in this list. One more
reason for you to be thankful that I used my time to point out
what you missed. It can happen to any one of us.

Cheers,
Ed Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GJMPkp023847; Fri, 16 Jul 2004 12:22:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GJMPIw023845; Fri, 16 Jul 2004 12:22:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail19g.dulles19-verio.com (mail19g.dulles19-verio.com [198.170.241.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6GJM9w4023798 for <[e-mail]>; Fri, 16 Jul 2004 12:22:23 -0700 (PDT) (envelope-from [e-mail])
Received: from www.geminisecurity.com (161.58.96.110) by mail19g.dulles19-verio.com (RS ver 1.0.94vs) with SMTP id 0-0169395732; Fri, 16 Jul 2004 15:22:13 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Request: Send me signed messages
Date: Fri, 16 Jul 2004 15:22:12 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcRraAsW0jX4x0V6T5a6urh3NWIY8AAAU4sw
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-Loop-Detect: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed,

I do not see why you felt it necessary to send this spiteful message.  I
have been an active participant in PKIX for 7 years now (S/MIME somewhat
less time), and I'm the editor and co-author of the current PKIX document on
certification path building.  I am not subscribed to the list to spam or to
burden the list.  As I said in my earlier message, I thought that these
lists contained the largest groups of individuals capable of sending signed
email messages.

Obviously before I share the collected certificates with any other
researchers, I will require a similar promise for those researchers to keep
the email addresses therein confidential.  

If anyone is afraid of what I might do with the collected email messages or
certificates, just don't send me a message.  I won't be offended.  I am
confident that those that know me, know of me, or know of my company have no
such fears; many have already sent me messages.  For that I thank you, and I
expect that the resultant set of data will be useful in the creation and
improvement of certification path development and validation software in the
years to come.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Ed Gerck
> Sent: Friday, July 16, 2004 2:53 PM
> To: Peter Hesse
> Cc: [e-mail]; [e-mail]
> Subject: Re: Request: Send me signed messages
> 
> 
> 
> 
> Peter Hesse wrote:
> 
> > All,
> > 
> > We are looking to get a cache of many "real-world" 
> certificates with 
> > which to do some testing related to certificate path 
> building and validation.
>  > Since most email clients send the signer's path (or some 
> portion thereof)
> > with signed messages, I'd love to receive signed messages 
> from anyone 
> > that is willing to send one.  I expect the S/MIME and PKIX 
> lists have 
> > a high quantity of individuals with the capability to send 
> S/MIME signed messages.
> 
> Comments below.
> 
> > You have my personal guarantee that your email addresses 
> will not be 
> > used or stored by us; I have no desire to alienate the community!
> 
> This is your promise #1.
> 
> > You can reply to this message (NOT THE LIST) and sign your 
> reply, or 
> > send directly to [e-mail].
> > 
> > I would be willing to share the resultant set of certificates with 
> > researchers interested in similar work.
> 
> This your promise #2. Do you think there is any conflict with 
> your promise #1?  What do you think we know the "resultant 
> set of certificates"
> contain?
> 
> COMMENTS: Your message is off-topic and a spam. It's free to 
> subscribe and listen to the traffic if you wish. Please don't 
> burden this list.
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GIu8uU019230; Fri, 16 Jul 2004 11:56:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GIu8Dm019227; Fri, 16 Jul 2004 11:56:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail8.atl.registeredsite.com ([e-mail] [64.224.219.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GIu76e019216; Fri, 16 Jul 2004 11:56:07 -0700 (PDT) (envelope-from [e-mail])
Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail8.atl.registeredsite.com (8.12.11/8.12.8) with ESMTP id i6GIu7NJ032231; Fri, 16 Jul 2004 18:56:07 GMT
Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Fri, 16 Jul 2004 13:56:06 -0500
Message-ID: <[e-mail]>
Date: Fri, 16 Jul 2004 11:53:12 -0700
From: Ed Gerck <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Hesse <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Request: Send me signed messages
References: <002101c46b50$342174a0$[e-mail]>
In-Reply-To: <002101c46b50$342174a0$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Hesse wrote:

> All,
> 
> We are looking to get a cache of many "real-world" certificates with which
> to do some testing related to certificate path building and validation.
 > Since most email clients send the signer's path (or some portion thereof)
> with signed messages, I'd love to receive signed messages from anyone that
> is willing to send one.  I expect the S/MIME and PKIX lists have a high
> quantity of individuals with the capability to send S/MIME signed messages.

Comments below.

> You have my personal guarantee that your email addresses will not be used or
> stored by us; I have no desire to alienate the community!

This is your promise #1.

> You can reply to this message (NOT THE LIST) and sign your reply, or send
> directly to [e-mail].
> 
> I would be willing to share the resultant set of certificates with
> researchers interested in similar work. 

This your promise #2. Do you think there is any conflict with your
promise #1?  What do you think we know the "resultant set of certificates"
contain?

COMMENTS: Your message is off-topic and a spam. It's free to subscribe and
listen to the traffic if you wish. Please don't burden this list.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GI20ir010193; Fri, 16 Jul 2004 11:02:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GI202v010192; Fri, 16 Jul 2004 11:02:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GI1xZh010181 for <[e-mail]>; Fri, 16 Jul 2004 11:02:00 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i6GI1jC0023593; Fri, 16 Jul 2004 14:01:45 -0400
Received: from krdp8.nist.gov (seclab14.ncsl.nist.gov [129.6.52.54]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i6GI1Umb025296; Fri, 16 Jul 2004 14:01:30 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 16 Jul 2004 14:05:06 -0400
To: [e-mail], [e-mail]
From: Tim Polk <[e-mail]>
Subject: forwarding
Cc: Stephen Kent <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

Last Call for "Certification Path Building" has been successfully completed.
All technical issues raised on the list have been resolved in the
current draft, available at

   http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-04.txt

As a result, I am forwarding the document to the ADs and requesting
progression as an informational track RFC.

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GHrLHv008986; Fri, 16 Jul 2004 10:53:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GHrLGC008985; Fri, 16 Jul 2004 10:53:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GHrK1c008971 for <[e-mail]>; Fri, 16 Jul 2004 10:53:20 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i6GHrGaK031049 for <[e-mail]>; Fri, 16 Jul 2004 13:53:16 -0400
Received: from krdp8.nist.gov (seclab14.ncsl.nist.gov [129.6.52.54]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i6GHqvmb018497 for <[e-mail]>; Fri, 16 Jul 2004 13:52:57 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 16 Jul 2004 13:56:33 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call: CertStore
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

This message initiates working group last call for "Certificate Store 
Access via HTTP"  This document is currently available at 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-07.txt. 
The document was intended for progression as Standards Track, so last call 
will be two weeks.  That is, Last Call for this document closes on or after 
July 30, 2004.

This specification specifies the conventions for using the Hypertext 
Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain 
certificates and certificate revocation lists (CRLs) from PKI repositories.

Thanks,

Tim Polk





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GGGcov092513; Fri, 16 Jul 2004 09:16:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GGGc6X092511; Fri, 16 Jul 2004 09:16:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail19g.dulles19-verio.com (mail19g.dulles19-verio.com [198.170.241.21] (may be forged)) by above.proper.com (8.12.11/8.12.9) with SMTP id i6GGGbd9092431 for <[e-mail]>; Fri, 16 Jul 2004 09:16:38 -0700 (PDT) (envelope-from [e-mail])
Received: from www.geminisecurity.com (161.58.96.110) by mail19g.dulles19-verio.com (RS ver 1.0.94vs) with SMTP id 4-0614554564; Fri, 16 Jul 2004 12:16:10 -0400 (EDT)
Message-ID: <002101c46b50$342174a0$[e-mail]>
From: "Peter Hesse" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Request: Send me signed messages
Date: Fri, 16 Jul 2004 12:16:02 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Loop-Detect: 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

We are looking to get a cache of many "real-world" certificates with which
to do some testing related to certificate path building and validation.
Since most email clients send the signer's path (or some portion thereof)
with signed messages, I'd love to receive signed messages from anyone that
is willing to send one.  I expect the S/MIME and PKIX lists have a high
quantity of individuals with the capability to send S/MIME signed messages.

You have my personal guarantee that your email addresses will not be used or
stored by us; I have no desire to alienate the community!

You can reply to this message (NOT THE LIST) and sign your reply, or send
directly to [e-mail].

I would be willing to share the resultant set of certificates with
researchers interested in similar work.  Please contact me on my normal
address, pmhesse[at]geminisecurity[dot]com if you are interested.

Thanks,

--Peter Hesse



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GFVJrd085862; Fri, 16 Jul 2004 08:31:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GFVJqI085861; Fri, 16 Jul 2004 08:31:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GFVG5T085833 for <[e-mail]>; Fri, 16 Jul 2004 08:31:18 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 7C0001CDAAC; Sat, 17 Jul 2004 03:29:27 +1200 (NZST)
Received: from pgut001 by medusa01 with local (Exim 4.32) id 1BlUgC-00059V-CV; Sat, 17 Jul 2004 03:31:20 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: New I-D on Intl Strings in Certs
In-Reply-To: <[e-mail]>
Message-Id: <E1BlUgC-00059V-CV@medusa01>
Date: Sat, 17 Jul 2004 03:31:20 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna <[e-mail]> writes:

>So please review this document and send comments to the PKIX list.

Here's mine.

>This algorithm SHOULD NOT be used for matching CRL distribution point names
>or cRLIssuer. A binary comparison SHOULD be used for such mapping.

Is there any reason why binary comparison is OK for finding who issued a CRL,
but not for who issued a cert?

>Path validation will fail when a relying party uses binary comparison to
>match X.500 names that differ slightly if the match is performed as part of
>subject-issuer name chaining or permittedSubtrees processing.

This begs the question of "Why the &*^#&$# would any CA in its right mind ever
issue a certificate where the issuer.suject DN gratuitously differs from the
subject.issuer DN by an extra space or something similar?".  You'd have to
deliberately add code to break the DN as it goes from parent to child.  Why
not say:

  Any CA that issues certificates where the issuer.suject DN gratuitously
  differs from the subject.issuer DN should be considered broken, with
  handling of its certs not guaranteed by this specification.

(you can rephrase that as MUST and whatnot if you want).

>More substantial problems can occur if a relying party uses binary comparison
>to determine that an X.500 name does not match excludedSubtrees and the CA
>expected that it would match because of the more lenient processing.

It doesn't matter what algorithm they use, you can always escape
excludedSubtrees by clever encoding of your DNs (see the X.509 style guide for
the details).  The draft should warn (like the RFC currently does) that you
can't rely on excludedSubtrees to exclude certs from non-cooperating cert
issuers (that is, ones that will create DNs with strings encoded so as to
avoid the exclusion).

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GEZwKU075692; Fri, 16 Jul 2004 07:35:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GEZwju075691; Fri, 16 Jul 2004 07:35:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GEZt8p075685 for <[e-mail]>; Fri, 16 Jul 2004 07:35:56 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i6GEZmaK021990; Fri, 16 Jul 2004 10:35:48 -0400
Received: from krdp8.nist.gov (seclab14.ncsl.nist.gov [129.6.52.54]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i6GEZImb003466; Fri, 16 Jul 2004 10:35:18 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 16 Jul 2004 10:38:54 -0400
To: "Michael Myers" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

Why delay to San Diego?

Really, it makes no sense to require a DPV client to be capable of 
asserting a flag that will incur a response it cannot hope to 
process!!!  That is the result if a client that does not implement path 
validation asserts that flag!

I strongly believe that:

(1) some clients will be DPV-only since they will not include an X.509 path 
validation module, and need not implement the flag at all;

(2) some clients will be designed for unsigned DPD only, and will be 
hard-wired to assert the flag; and

(3) some clients will support unsigned DPD as well asat least one of (a) 
signed DPD and (b) DPV, and will need to implement flag and provide 
configuration

Let's forward a spec that reflects this reality.

Tim

At 03:14 PM 7/15/2004 -0700, Michael Myers wrote:
>Russ,
>
>Seems a matter for San Diego at this point.
>
>Mike
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Russ Housley
>Sent: Wednesday, July 14, 2004 2:10 PM
>To: Michael Myers; Tim Polk; [e-mail]
>Subject: RE: Unsigned DPD responses for SCVP15
>
>
>
>Mike:
>
>Recently, I have done a fair amount of work in the wireless space, and I
>am
>convinced that clients on these devices with limited processing
>capabilities will make use of DPV.  So, maybe what we need is a profile
>at
>the end of the document that lists the features that must be implemented
>to
>be considered a DPV client, a DPV server, a DPD client, and a DPD
>server.  This should be pretty easy to put together, although I doubt
>that
>it can be done before the draft deadline for the San Diego meeting.
>
>Russ
>
>At 04:03 PM 7/14/2004, Michael Myers wrote:
> >I'm not sure that can be predicted to such a degree.
> >
> >When Carlisle Adams, Stephen Farrell and I first addressed introduced
> >DPV and DPD to the WG, it was Stephen who was forceful in convincing
> >Carlisle and I that one of the most difficult issues wrt PKI was simply
> >acquiring the data necessary to path validation.  This was due in no
> >small part to the various protocols and schemas associated with that
> >process, as now amply documented in 3379.  Further, a "client" is not
> >just, for example, a web browser.  It could be amalgamation of back
> >office mechanisms, AAA, Radius and what have you.  I suspect there
>might
> >come to exist a non-trivial number of such instances.
> >
> >Also, are you saying that in your view an SCVP client is compliant if
>it
> >fails to allow use of id-stc-build-pkc-path in CertChecks syntax and
> >id-swb-pkc-cert-path and id-swb-pkc-revocation-info in the WantBack
> >syntax?
> >
> >Mike
> >
> >-----Original Message-----
> >From: Russ Housley [mailto:[e-mail]]
> >Sent: Wednesday, July 14, 2004 12:37 PM
> >To: Michael Myers; Tim Polk; [e-mail]
> >Subject: RE: Unsigned DPD responses for SCVP15
> >
> >
> >I do not accept your assumption.  I expect many clients to be DPV-only.
> >
> >Russ
> >
> >At 03:31 PM 7/14/2004, Michael Myers wrote:
> > >True, SCVP clients that assert the OID that drives a server to
>produce
> >a
> > >validity assertion MUST accept and process a signature.  But assuming
> > >that same client is also implemented to assert simply a return of
> >{path,
> > >rev-info}, then it seems reasonable to assume it should also be
>capable
> > >of asserting the flag.
> > >
> > >
> > >Mike



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GEQpVk074515; Fri, 16 Jul 2004 07:26:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GEQpOH074514; Fri, 16 Jul 2004 07:26:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GEQnel074507 for <[e-mail]>; Fri, 16 Jul 2004 07:26:50 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i6GEQAaK019743; Fri, 16 Jul 2004 10:26:10 -0400
Received: from krdp8.nist.gov (seclab14.ncsl.nist.gov [129.6.52.54]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i6GEPimb024098; Fri, 16 Jul 2004 10:25:44 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 16 Jul 2004 10:29:20 -0400
To: "Michael Myers" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

If the client is implemented to permit asserting simply a return of {path,
rev-info}, then it is required to be capable of asserting the flag.

That is different from requiring this for all clients.

Tim

At 12:31 PM 7/14/2004 -0700, Michael Myers wrote:
>True, SCVP clients that assert the OID that drives a server to produce a
>validity assertion MUST accept and process a signature.  But assuming
>that same client is also implemented to assert simply a return of {path,
>rev-info}, then it seems reasonable to assume it should also be capable
>of asserting the flag.
>
>
>Mike
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Wednesday, July 14, 2004 12:14 PM
>To: Michael Myers; Tim Polk; [e-mail]
>Subject: RE: Unsigned DPD responses for SCVP15
>
>
>There is no need for DPV clients to assert the flag!
>
>Russ
>
>At 12:16 PM 7/14/2004, Michael Myers wrote:
> >I would add one other requirement.  Clients MUST be capable of
>asserting
> >the flag.
> >
> >Mike
> >
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]]On Behalf Of Tim Polk
> >Sent: Wednesday, July 14, 2004 6:50 AM
> >To: Russ Housley; [e-mail]
> >Subject: Re: Unsigned DPD responses for SCVP15
> >
> >
> >
> >
> >
> >I also prefer the client-side flag option.  However, I *strongly*
> >believe
> >that the default behavior (i.e., in the absence of the flag) should be
> >"signature is REQUIRED" on the SCVP response.
> >
> >In this way, the default behavior for SCVP always satisfies the
> >requirements specified in RFC 3379.   Where the client has explicitly
> >determined that source authentication is not required, the client may
> >explicitly state this.
> >
> >I believe this option boils down to four fairly simple statements.
> >
> >(1) Where an SCVP request omits the "not going to authenticate" flag,
> >the
> >server is required to sign the response or return an error.
> >
> >(2) Where an SCVP request includes the flag, the server may include or
> >omit
> >the signature on the response.  (So, a server that *always* signs
> >responses
> >doesn't need to process this flag...)
> >
> >(3) An SCVP client MUST NOT assert the "not going to authenticate" flag
> >and
> >request a statement about validity.
> >
> >(4) Where the request did not assert the new flag, the SCVP client MUST
> >process the digital signature on a response.
> >
> >I believe these changes would result in a protocol whose default
> >behavior
> >satisfies all the requirements in 3379, permits the employment of
> >unsigned
> >messages for DPD, and precludes any ambiguity in the implementation of
> >mixed mode servers.
> >
> >Tim Polk
> >
> >
> >
> >
> >At 12:38 PM 7/13/2004 -0400, Russ Housley wrote:
> >
> >
> > >My personal preference Option #2; however, I think that absence of
>this
> > >flag should indicate that the response should be signed.  One needs
>to
> > >make a guess about deployment to select the best semantic for this
> > >situation, and my guess is that server authentication will be
> >important.
> > >
> > >Russ
> > >
> > >
> > >Trevor Freeman wrote:
> > >>I have been asked to add unsigned responses for DPD clients to
>SCVP15.
> > >>There are two models proposed on how we accomplish that both of
>which
> > >>meet the requirements for 3379. I would therefore like some feedback
> >on
> > >>how the group views the two mechanisms
> > >>
> > >>Global Server Policy that it is DPD only
> > >>The first proposal is to make the option controlled by the server as
>a
> > >>global policy. Therefore the server would publish via policy that is
> >only
> > >>supports DPD as such never signs a response. DPV client and DPD
> >clients
> > >>wanting a signed response then know to use another server.
> > >>
> > >>SCVP Request option to not sign response
> > >>The second option is to leave it to the client to signal to the
>server
> >it
> > >>does not need a signature on the response by a new flag in the
>request
> > >>(or its twin the flag indicates it does want a signature on the
> > >>response). This allows clients to be benevolent towards the server
>by
> > >>asking it to skip the signature. Server can still at their
>discretion
> > >>still sign.
> > >>
> > >>Needless to say it is possible to hybridize the two but I am hopeful
> >we
> > >>can try and keep this as simple as possible be picking on of the
>two.
> > >>Trevor
> > >
> > >
> > >
> > >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G1NGaX054199; Thu, 15 Jul 2004 18:23:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6G1NGvp054198; Thu, 15 Jul 2004 18:23:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns01.secom.co.jp (ns01.secom.co.jp [61.114.178.247]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G1NFKB054174 for <[e-mail]>; Thu, 15 Jul 2004 18:23:15 -0700 (PDT) (envelope-from [e-mail])
Received: from mlit02.intra.secom.co.jp ([172.21.1.41]) by ns01.secom.co.jp (8.11.7-20030918/3.7W) with ESMTP id i6G1N7w25782 for <[e-mail]>; Fri, 16 Jul 2004 10:23:07 +0900 (JST)
Received: from sectrl.isl.secom.co.jp (localhost [127.0.0.1]) by mlit02.intra.secom.co.jp (8.11.3/3.7W) with ESMTP id i6G1N7K17763 for <[e-mail]>; Fri, 16 Jul 2004 10:23:07 +0900
Received: from isis.sp.isl.secom.co.jp (isis.isl.secom.co.jp [10.131.16.23]) by sectrl.isl.secom.co.jp (Postfix) with ESMTP id 0ECF41E72E for <[e-mail]>; Fri, 16 Jul 2004 10:23:07 +0900 (JST)
Received: from PC6 (pc6.isl.secom.co.jp [10.131.129.79]) by isis.sp.isl.secom.co.jp (8.9.1+3.1W/3.7W-Isis.1) with SMTP id KAA27013 for <[e-mail]>; Fri, 16 Jul 2004 10:23:06 +0900
Message-ID: <003801c46ad3$71f4f860$4f81830a@PC6>
From: "Kenji URUSHIMA" <[e-mail]>
To: <[e-mail]>
Subject: Announce: Challenge PKI Test Suite 2.0 available
Date: Fri, 16 Jul 2004 10:23:05 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

The 'Challenge PKI Project' will announce 
the release of 'Challenge PKI Test Suite 2.0', an open source
freeware which helps you to test multi-domain
PKI interoperability.

It has following features.

- Multi Domain PKI testing environment using only ONE Linux PC. 
- Open Source Software distributed as BSD lincence. 
- Multiple CA certificate issuance 
- Multiple LDAP repository 
- Test case database for certificate path processing and timestamp testing 
- Easy accessible web browser based interface 
- Flexible certificate and CRL issuance (e.g. any special extensions, 
  distinguish name which contains special characters such like 
  UTF8String of European, Chinese, Korean or Japanese languages) 
- Cooperative test case design environment. 
- Easy to re-build test environment. 
- Cross certification with CA products. 
- OCSP Responder and Japanese GPKI CVS(Certificate Validation Server) 
  Simulator 
- RFC 3161 Timestamp request and response generator. 

* DOWNLOAD

  http://www.jnsa.org/mpki/
    http://www.jnsa.org/mpki/ts/cpkits-2.0.2-21.i386.rpm  RedHat RPM
    http://www.jnsa.org/mpki/ts/cpkits-2.0.2-21.src.rpm   RedHat SRPM
    http://www.jnsa.org/mpki/ts/cpkits-2.0.2-21.tar.gz    Tar Archive
    http://www.jnsa.org/mpki/ts/cpki_testcase_jgpki2_20040709.tar.gz
      Japanese Government PKI Testcase
    Other test cases will be provided near in future.

  Online document can be found at the following URLs.

  Challenge PKI Project
    http://www.jnsa.org/mpki/
  Challenge PKI Test Suite 2.0 Document
    http://www.jnsa.org/mpki/ts/
  Japanese Government PKI Test Case
    http://www.jnsa.org/mpki/ts/testcase_jgpki2/

* SYSTEM REQUIREMENTS

  Intel(R) Pentium(R) compatible processor 300MHz or above 
  RedHat 7.3 or later 
  64MB RAM or above 
  200MB of available hard-disk space 
  NIC 

  We recommend RedHat 7.3 or later for the operating system but
  it's easy to port other operating systems.
  We have already tested on Solaris and FreeBSD.

* CHALLENGE PKI PROJECT

The 'Challenge PKI Project' is established as one of activities
in the NPO Japan Network Security Association (JNSA).
Our goal is ensure PKI interoperability and contribute actively to
development and spread of reliable PKI applications in future 
electronic society.

* CONTACT

  Feel free to mail 'mpki at jnsa.org' 
  if you have any questions, comments or contributions of 
  source code or documents.

Enjoy.

-- Kenji URUSHIMA (Challenge PKI Project, SECOM Co., Ltd.)





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FMEiVp025852; Thu, 15 Jul 2004 15:14:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FMEihx025851; Thu, 15 Jul 2004 15:14:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FMEh7S025836 for <[e-mail]>; Thu, 15 Jul 2004 15:14:43 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6FMEh845542; Thu, 15 Jul 2004 15:14:43 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Thu, 15 Jul 2004 15:14:03 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Seems a matter for San Diego at this point.

Mike

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Russ Housley
Sent: Wednesday, July 14, 2004 2:10 PM
To: Michael Myers; Tim Polk; [e-mail]
Subject: RE: Unsigned DPD responses for SCVP15



Mike:

Recently, I have done a fair amount of work in the wireless space, and I
am
convinced that clients on these devices with limited processing
capabilities will make use of DPV.  So, maybe what we need is a profile
at
the end of the document that lists the features that must be implemented
to
be considered a DPV client, a DPV server, a DPD client, and a DPD
server.  This should be pretty easy to put together, although I doubt
that
it can be done before the draft deadline for the San Diego meeting.

Russ

At 04:03 PM 7/14/2004, Michael Myers wrote:
>I'm not sure that can be predicted to such a degree.
>
>When Carlisle Adams, Stephen Farrell and I first addressed introduced
>DPV and DPD to the WG, it was Stephen who was forceful in convincing
>Carlisle and I that one of the most difficult issues wrt PKI was simply
>acquiring the data necessary to path validation.  This was due in no
>small part to the various protocols and schemas associated with that
>process, as now amply documented in 3379.  Further, a "client" is not
>just, for example, a web browser.  It could be amalgamation of back
>office mechanisms, AAA, Radius and what have you.  I suspect there
might
>come to exist a non-trivial number of such instances.
>
>Also, are you saying that in your view an SCVP client is compliant if
it
>fails to allow use of id-stc-build-pkc-path in CertChecks syntax and
>id-swb-pkc-cert-path and id-swb-pkc-revocation-info in the WantBack
>syntax?
>
>Mike
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Wednesday, July 14, 2004 12:37 PM
>To: Michael Myers; Tim Polk; [e-mail]
>Subject: RE: Unsigned DPD responses for SCVP15
>
>
>I do not accept your assumption.  I expect many clients to be DPV-only.
>
>Russ
>
>At 03:31 PM 7/14/2004, Michael Myers wrote:
> >True, SCVP clients that assert the OID that drives a server to
produce
>a
> >validity assertion MUST accept and process a signature.  But assuming
> >that same client is also implemented to assert simply a return of
>{path,
> >rev-info}, then it seems reasonable to assume it should also be
capable
> >of asserting the flag.
> >
> >
> >Mike




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FFjUjP061664; Thu, 15 Jul 2004 08:45:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FFjU8M061663; Thu, 15 Jul 2004 08:45:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6FFjSSO061645 for <[e-mail]>; Thu, 15 Jul 2004 08:45:29 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 4109 invoked by uid 0); 15 Jul 2004 15:39:57 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.40.47) by woodstock.binhost.com with SMTP; 15 Jul 2004 15:39:57 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Thu, 15 Jul 2004 11:45:40 -0400
To: "Manger, James H" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
In-Reply-To: <[e-mail] l.telstra.com.au>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for the suggestion.  It works for me.

Russ


At 01:22 AM 7/15/2004, Manger, James H wrote:

>How about "Clients that can use SCVP for DPD MUST be capable of asserting 
>the flag".
>
>Mike might be satisfied - the feature will be usable.
>Russ might be satisfied - a DPV-only client can ignore this feature.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FA89vZ097363; Thu, 15 Jul 2004 03:08:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6FA899q097362; Thu, 15 Jul 2004 03:08:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mh.pvt.cz (spider.pvt.cz [194.149.101.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FA87rt097331 for <[e-mail]>; Thu, 15 Jul 2004 03:08:08 -0700 (PDT) (envelope-from [e-mail])
Received: from PHAWEX01.pvt.cz (phaw02.pvt.cz [172.17.21.21]) by mh.pvt.cz (8.11.2/8.11.2) with ESMTP id i6FA7Xh04728; Thu, 15 Jul 2004 12:07:33 +0200
Received: from brnw00.pvt.cz ([172.17.41.10]) by PHAWEX01.pvt.cz with Microsoft SMTPSVC(5.0.2195.5329); Thu, 15 Jul 2004 12:06:47 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-10.txt
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Thu, 15 Jul 2004 12:06:47 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-pi-10.txt
Thread-Index: AcRqUefW0kXKvJdfT2W7YUd15iP4aAAAOg3w
From: "Pinkava Jaroslav" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 15 Jul 2004 10:06:47.0647 (UTC) FILETIME=[708F0EF0:01C46A53]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6FA88rt097354
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The adress http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-10.txt
doesn´t work.
              J. Pinkava

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, July 15, 2004 10:06 AM
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-10.txt



Some information about the major changes done to this draft.

After side discussions initiated by Anders Rundgren and followed by Peter 
Gutmann, I have discussed with my co-editor, the PKIX chairs and the 
security Area Director.

As the result of this, the definition of the PI has been changed to allow to 
use the serialNumber attribute from the subject DN.

In the previous draft, there were 2 options or variants for the PI which was 
defined as:

   PermanentIdentifier ::=     SEQUENCE {
      identifierValue              UTF8String,
      identifierType               OBJECT IDENTIFIER      OPTIONAL
   }


In draft 10, there are now 3 options or variants for the PI which has been 
redefined as:

   PermanentIdentifier ::=     SEQUENCE {
      identifierValue    UTF8String             OPTIONAL,
                      -- if absent, use the serialNumber attribute
                         if there is a single such attribute present
                         in the subject DN
      assigner           OBJECT IDENTIFIER      OPTIONAL
                      -- if absent, the assigner is
                         the certificate issuer
    }

For further details, please take a look at the draft.

(and if you take a close look, you will find a "typo" ASN.1 error,
that will need to be corrected by re-issuing a new draft). :-(

Denis


> 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 Permanent Identifier
> 	Author(s)	: D. Pinkas, T. Gindin
> 	Filename	: draft-ietf-pkix-pi-10.txt
> 	Pages		: 13
> 	Date		: 2004-7-13
> 	
> This document define a new form of name, called permanent 
> identifier, that may be included in the subjectAltName extension 
> of a public key certificate issued to an entity.
> The permanent identifier is an optional feature that may be used 
> by a CA to indicate that the certificate relates to the same 
> entity even if the name or the affiliation of that entity stored 
> in the subject or another name form in the subjectAltName extension 
> has changed.
> The subject name, carried in the subject field, is only unique 
> for each subject entity certified by the one CA as defined by the 
> issuer name field. Also, the new name form can carry a 
> name that is unique for each subject entity certified by a CA.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-10.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [e-mail] with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> 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-pi-10.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-pi-10.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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F85xM3043317; Thu, 15 Jul 2004 01:05:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6F85xOI043316; Thu, 15 Jul 2004 01:05:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F85u6l043224 for <[e-mail]>; Thu, 15 Jul 2004 01:05:57 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA19064 for <[e-mail]>; Thu, 15 Jul 2004 10:16:10 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id KAA29668 for <[e-mail]>; Thu, 15 Jul 2004 10:05:35 +0200
Message-ID: <[e-mail]>
Date: Thu, 15 Jul 2004 10:05:47 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-10.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some information about the major changes done to this draft.

After side discussions initiated by Anders Rundgren and followed by Peter 
Gutmann, I have discussed with my co-editor, the PKIX chairs and the 
security Area Director.

As the result of this, the definition of the PI has been changed to allow to 
use the serialNumber attribute from the subject DN.

In the previous draft, there were 2 options or variants for the PI which was 
defined as:

   PermanentIdentifier ::=     SEQUENCE {
      identifierValue              UTF8String,
      identifierType               OBJECT IDENTIFIER      OPTIONAL
   }


In draft 10, there are now 3 options or variants for the PI which has been 
redefined as:

   PermanentIdentifier ::=     SEQUENCE {
      identifierValue    UTF8String             OPTIONAL,
                      -- if absent, use the serialNumber attribute
                         if there is a single such attribute present
                         in the subject DN
      assigner           OBJECT IDENTIFIER      OPTIONAL
                      -- if absent, the assigner is
                         the certificate issuer
    }

For further details, please take a look at the draft.

(and if you take a close look, you will find a "typo" ASN.1 error,
that will need to be corrected by re-issuing a new draft). :-(

Denis


> 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 Permanent Identifier
> 	Author(s)	: D. Pinkas, T. Gindin
> 	Filename	: draft-ietf-pkix-pi-10.txt
> 	Pages		: 13
> 	Date		: 2004-7-13
> 	
> This document define a new form of name, called permanent 
> identifier, that may be included in the subjectAltName extension 
> of a public key certificate issued to an entity.
> The permanent identifier is an optional feature that may be used 
> by a CA to indicate that the certificate relates to the same 
> entity even if the name or the affiliation of that entity stored 
> in the subject or another name form in the subjectAltName extension 
> has changed.
> The subject name, carried in the subject field, is only unique 
> for each subject entity certified by the one CA as defined by the 
> issuer name field. Also, the new name form can carry a 
> name that is unique for each subject entity certified by a CA.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-10.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [e-mail] with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> 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-pi-10.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-pi-10.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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F5N4Z8063120; Wed, 14 Jul 2004 22:23:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6F5N4AV063118; Wed, 14 Jul 2004 22:23:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.ntcif.telstra.com.au (mailbo.ntcif.telstra.com.au [202.12.233.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F5N3iA062896 for <[e-mail]>; Wed, 14 Jul 2004 22:23:04 -0700 (PDT) (envelope-from [e-mail])
Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailbo.ntcif.telstra.com.au (Postfix) with ESMTP id BCBB212C59 for <[e-mail]>; Thu, 15 Jul 2004 15:22:58 +1000 (EST)
Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 69167FF83 for <[e-mail]>; Thu, 15 Jul 2004 15:22:58 +1000 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 3BB6741E73 for <[e-mail]>; Thu, 15 Jul 2004 15:22:58 +1000 (EST)
content-class: urn:content-classes:message
Subject: RE: Unsigned DPD responses for SCVP15
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Thu, 15 Jul 2004 15:22:52 +1000
Message-ID: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Unsigned DPD responses for SCVP15
Thread-Index: AcRp9TvN4kpe21UvThmTmW3ckYPAxwANeY/A
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6F5N4iA063109
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

How about "Clients that can use SCVP for DPD MUST be capable of asserting the flag".

Mike might be satisfied - the feature will be usable.
Russ might be satisfied - a DPV-only client can ignore this feature.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ELAKAo074609; Wed, 14 Jul 2004 14:10:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6ELAKfY074608; Wed, 14 Jul 2004 14:10:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6ELAJvh074592 for <[e-mail]>; Wed, 14 Jul 2004 14:10:19 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 23638 invoked by uid 0); 14 Jul 2004 21:05:02 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.95.220) by woodstock.binhost.com with SMTP; 14 Jul 2004 21:05:02 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Wed, 14 Jul 2004 17:10:28 -0400
To: "Michael Myers" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike:

Recently, I have done a fair amount of work in the wireless space, and I am 
convinced that clients on these devices with limited processing 
capabilities will make use of DPV.  So, maybe what we need is a profile at 
the end of the document that lists the features that must be implemented to 
be considered a DPV client, a DPV server, a DPD client, and a DPD 
server.  This should be pretty easy to put together, although I doubt that 
it can be done before the draft deadline for the San Diego meeting.

Russ

At 04:03 PM 7/14/2004, Michael Myers wrote:
>I'm not sure that can be predicted to such a degree.
>
>When Carlisle Adams, Stephen Farrell and I first addressed introduced
>DPV and DPD to the WG, it was Stephen who was forceful in convincing
>Carlisle and I that one of the most difficult issues wrt PKI was simply
>acquiring the data necessary to path validation.  This was due in no
>small part to the various protocols and schemas associated with that
>process, as now amply documented in 3379.  Further, a "client" is not
>just, for example, a web browser.  It could be amalgamation of back
>office mechanisms, AAA, Radius and what have you.  I suspect there might
>come to exist a non-trivial number of such instances.
>
>Also, are you saying that in your view an SCVP client is compliant if it
>fails to allow use of id-stc-build-pkc-path in CertChecks syntax and
>id-swb-pkc-cert-path and id-swb-pkc-revocation-info in the WantBack
>syntax?
>
>Mike
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Wednesday, July 14, 2004 12:37 PM
>To: Michael Myers; Tim Polk; [e-mail]
>Subject: RE: Unsigned DPD responses for SCVP15
>
>
>I do not accept your assumption.  I expect many clients to be DPV-only.
>
>Russ
>
>At 03:31 PM 7/14/2004, Michael Myers wrote:
> >True, SCVP clients that assert the OID that drives a server to produce
>a
> >validity assertion MUST accept and process a signature.  But assuming
> >that same client is also implemented to assert simply a return of
>{path,
> >rev-info}, then it seems reasonable to assume it should also be capable
> >of asserting the flag.
> >
> >
> >Mike



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EK4HG8063172; Wed, 14 Jul 2004 13:04:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EK4HS7063171; Wed, 14 Jul 2004 13:04:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EK4G4s063163 for <[e-mail]>; Wed, 14 Jul 2004 13:04:16 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6EK4F821049; Wed, 14 Jul 2004 13:04:15 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Wed, 14 Jul 2004 13:03:33 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm not sure that can be predicted to such a degree.

When Carlisle Adams, Stephen Farrell and I first addressed introduced
DPV and DPD to the WG, it was Stephen who was forceful in convincing
Carlisle and I that one of the most difficult issues wrt PKI was simply
acquiring the data necessary to path validation.  This was due in no
small part to the various protocols and schemas associated with that
process, as now amply documented in 3379.  Further, a "client" is not
just, for example, a web browser.  It could be amalgamation of back
office mechanisms, AAA, Radius and what have you.  I suspect there might
come to exist a non-trivial number of such instances.

Also, are you saying that in your view an SCVP client is compliant if it
fails to allow use of id-stc-build-pkc-path in CertChecks syntax and
id-swb-pkc-cert-path and id-swb-pkc-revocation-info in the WantBack
syntax?

Mike

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Wednesday, July 14, 2004 12:37 PM
To: Michael Myers; Tim Polk; [e-mail]
Subject: RE: Unsigned DPD responses for SCVP15


I do not accept your assumption.  I expect many clients to be DPV-only.

Russ

At 03:31 PM 7/14/2004, Michael Myers wrote:
>True, SCVP clients that assert the OID that drives a server to produce
a
>validity assertion MUST accept and process a signature.  But assuming
>that same client is also implemented to assert simply a return of
{path,
>rev-info}, then it seems reasonable to assume it should also be capable
>of asserting the flag.
>
>
>Mike




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJb1RX058808; Wed, 14 Jul 2004 12:37:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EJb1Hv058807; Wed, 14 Jul 2004 12:37:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6EJb0v9058800 for <[e-mail]>; Wed, 14 Jul 2004 12:37:00 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 28093 invoked by uid 0); 14 Jul 2004 19:31:44 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.10.112) by woodstock.binhost.com with SMTP; 14 Jul 2004 19:31:44 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Wed, 14 Jul 2004 15:37:27 -0400
To: "Michael Myers" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I do not accept your assumption.  I expect many clients to be DPV-only.

Russ

At 03:31 PM 7/14/2004, Michael Myers wrote:
>True, SCVP clients that assert the OID that drives a server to produce a
>validity assertion MUST accept and process a signature.  But assuming
>that same client is also implemented to assert simply a return of {path,
>rev-info}, then it seems reasonable to assume it should also be capable
>of asserting the flag.
>
>
>Mike
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Wednesday, July 14, 2004 12:14 PM
>To: Michael Myers; Tim Polk; [e-mail]
>Subject: RE: Unsigned DPD responses for SCVP15
>
>
>There is no need for DPV clients to assert the flag!
>
>Russ
>
>At 12:16 PM 7/14/2004, Michael Myers wrote:
> >I would add one other requirement.  Clients MUST be capable of
>asserting
> >the flag.
> >
> >Mike
> >
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]]On Behalf Of Tim Polk
> >Sent: Wednesday, July 14, 2004 6:50 AM
> >To: Russ Housley; [e-mail]
> >Subject: Re: Unsigned DPD responses for SCVP15
> >
> >
> >
> >
> >
> >I also prefer the client-side flag option.  However, I *strongly*
> >believe
> >that the default behavior (i.e., in the absence of the flag) should be
> >"signature is REQUIRED" on the SCVP response.
> >
> >In this way, the default behavior for SCVP always satisfies the
> >requirements specified in RFC 3379.   Where the client has explicitly
> >determined that source authentication is not required, the client may
> >explicitly state this.
> >
> >I believe this option boils down to four fairly simple statements.
> >
> >(1) Where an SCVP request omits the "not going to authenticate" flag,
> >the
> >server is required to sign the response or return an error.
> >
> >(2) Where an SCVP request includes the flag, the server may include or
> >omit
> >the signature on the response.  (So, a server that *always* signs
> >responses
> >doesn't need to process this flag...)
> >
> >(3) An SCVP client MUST NOT assert the "not going to authenticate" flag
> >and
> >request a statement about validity.
> >
> >(4) Where the request did not assert the new flag, the SCVP client MUST
> >process the digital signature on a response.
> >
> >I believe these changes would result in a protocol whose default
> >behavior
> >satisfies all the requirements in 3379, permits the employment of
> >unsigned
> >messages for DPD, and precludes any ambiguity in the implementation of
> >mixed mode servers.
> >
> >Tim Polk
> >
> >
> >
> >
> >At 12:38 PM 7/13/2004 -0400, Russ Housley wrote:
> >
> >
> > >My personal preference Option #2; however, I think that absence of
>this
> > >flag should indicate that the response should be signed.  One needs
>to
> > >make a guess about deployment to select the best semantic for this
> > >situation, and my guess is that server authentication will be
> >important.
> > >
> > >Russ
> > >
> > >
> > >Trevor Freeman wrote:
> > >>I have been asked to add unsigned responses for DPD clients to
>SCVP15.
> > >>There are two models proposed on how we accomplish that both of
>which
> > >>meet the requirements for 3379. I would therefore like some feedback
> >on
> > >>how the group views the two mechanisms
> > >>
> > >>Global Server Policy that it is DPD only
> > >>The first proposal is to make the option controlled by the server as
>a
> > >>global policy. Therefore the server would publish via policy that is
> >only
> > >>supports DPD as such never signs a response. DPV client and DPD
> >clients
> > >>wanting a signed response then know to use another server.
> > >>
> > >>SCVP Request option to not sign response
> > >>The second option is to leave it to the client to signal to the
>server
> >it
> > >>does not need a signature on the response by a new flag in the
>request
> > >>(or its twin the flag indicates it does want a signature on the
> > >>response). This allows clients to be benevolent towards the server
>by
> > >>asking it to skip the signature. Server can still at their
>discretion
> > >>still sign.
> > >>
> > >>Needless to say it is possible to hybridize the two but I am hopeful
> >we
> > >>can try and keep this as simple as possible be picking on of the
>two.
> > >>Trevor
> > >
> > >
> > >
> > >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJWZIO058069; Wed, 14 Jul 2004 12:32:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EJWZs8058068; Wed, 14 Jul 2004 12:32:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJWZaE058056 for <[e-mail]>; Wed, 14 Jul 2004 12:32:35 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6EJWX816909; Wed, 14 Jul 2004 12:32:33 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Wed, 14 Jul 2004 12:31:54 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

True, SCVP clients that assert the OID that drives a server to produce a
validity assertion MUST accept and process a signature.  But assuming
that same client is also implemented to assert simply a return of {path,
rev-info}, then it seems reasonable to assume it should also be capable
of asserting the flag.


Mike

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Wednesday, July 14, 2004 12:14 PM
To: Michael Myers; Tim Polk; [e-mail]
Subject: RE: Unsigned DPD responses for SCVP15


There is no need for DPV clients to assert the flag!

Russ

At 12:16 PM 7/14/2004, Michael Myers wrote:
>I would add one other requirement.  Clients MUST be capable of
asserting
>the flag.
>
>Mike
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Tim Polk
>Sent: Wednesday, July 14, 2004 6:50 AM
>To: Russ Housley; [e-mail]
>Subject: Re: Unsigned DPD responses for SCVP15
>
>
>
>
>
>I also prefer the client-side flag option.  However, I *strongly*
>believe
>that the default behavior (i.e., in the absence of the flag) should be
>"signature is REQUIRED" on the SCVP response.
>
>In this way, the default behavior for SCVP always satisfies the
>requirements specified in RFC 3379.   Where the client has explicitly
>determined that source authentication is not required, the client may
>explicitly state this.
>
>I believe this option boils down to four fairly simple statements.
>
>(1) Where an SCVP request omits the "not going to authenticate" flag,
>the
>server is required to sign the response or return an error.
>
>(2) Where an SCVP request includes the flag, the server may include or
>omit
>the signature on the response.  (So, a server that *always* signs
>responses
>doesn't need to process this flag...)
>
>(3) An SCVP client MUST NOT assert the "not going to authenticate" flag
>and
>request a statement about validity.
>
>(4) Where the request did not assert the new flag, the SCVP client MUST
>process the digital signature on a response.
>
>I believe these changes would result in a protocol whose default
>behavior
>satisfies all the requirements in 3379, permits the employment of
>unsigned
>messages for DPD, and precludes any ambiguity in the implementation of
>mixed mode servers.
>
>Tim Polk
>
>
>
>
>At 12:38 PM 7/13/2004 -0400, Russ Housley wrote:
>
>
> >My personal preference Option #2; however, I think that absence of
this
> >flag should indicate that the response should be signed.  One needs
to
> >make a guess about deployment to select the best semantic for this
> >situation, and my guess is that server authentication will be
>important.
> >
> >Russ
> >
> >
> >Trevor Freeman wrote:
> >>I have been asked to add unsigned responses for DPD clients to
SCVP15.
> >>There are two models proposed on how we accomplish that both of
which
> >>meet the requirements for 3379. I would therefore like some feedback
>on
> >>how the group views the two mechanisms
> >>
> >>Global Server Policy that it is DPD only
> >>The first proposal is to make the option controlled by the server as
a
> >>global policy. Therefore the server would publish via policy that is
>only
> >>supports DPD as such never signs a response. DPV client and DPD
>clients
> >>wanting a signed response then know to use another server.
> >>
> >>SCVP Request option to not sign response
> >>The second option is to leave it to the client to signal to the
server
>it
> >>does not need a signature on the response by a new flag in the
request
> >>(or its twin the flag indicates it does want a signature on the
> >>response). This allows clients to be benevolent towards the server
by
> >>asking it to skip the signature. Server can still at their
discretion
> >>still sign.
> >>
> >>Needless to say it is possible to hybridize the two but I am hopeful
>we
> >>can try and keep this as simple as possible be picking on of the
two.
> >>Trevor
> >
> >
> >
> >





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJEroL055077; Wed, 14 Jul 2004 12:14:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EJErqF055076; Wed, 14 Jul 2004 12:14:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imo-m16.mx.aol.com (imo-m16.mx.aol.com [64.12.138.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJEqKp055058 for <[e-mail]>; Wed, 14 Jul 2004 12:14:52 -0700 (PDT) (envelope-from [e-mail])
Received: from [e-mail] by imo-m16.mx.aol.com (mail_out_v37_r2.6.) id 6.129.461bcc8c (15901); Wed, 14 Jul 2004 15:14:37 -0400 (EDT)
Received: from  pc655301.ad.aol.aoltw.net (h-10-169-149-117.nscp.aoltw.net [10.169.149.117]) by air-id09.mx.aol.com (v100.23) with ESMTP id MAILINID94-3e1d40f5861a96; Wed, 14 Jul 2004 15:14:37 -0400
Date: Wed, 14 Jul 2004 12:14:32 -0700
From: "Terry Hayes" <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
To: "Michael Myers" <[e-mail]>, "Tim Polk" <[e-mail]>, "Russ Housley" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-Mailer: AOL Fanfare (20040710Branch.4205.94 Win)
Organization: AOL
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-AOL-IP: 10.169.149.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

The client should not be required to have this capability.  If a client applicatio will never assert the flag because of its operating environment and policy, why should it be required to implement code that can set it?  The need to assert the flag (or not) can be predicted ahead of time in some environments.

Terry


Michael Myers wrote on 7/14/2004, 11:57 AM:
> 
> I thought we were done too until I read more carefully your proposed 
> text.  I do believe the requirement is necessary or I wouldn't have 
> brought it up.  The need to assert the flag cannot be 100% predicted 
> ahead of time.  Given the presumptive definition of the flag, I believe 
> interoperability would benefit.  It doesn't say the flag must be used, 
> but only that the capability we all worked so hard on to define is an 
> assumption rather than a stovepipe. 
> 
> Mike 
> 
> 
> 
> -----Original Message----- 
> From: Tim Polk [mailto:[e-mail]] 
> Sent: Wednesday, July 14, 2004 11:18 AM 
> To: Michael Myers; Russ Housley; [e-mail] 
> Subject: RE: Unsigned DPD responses for SCVP15 
> 
> 
> 
> Mike, 
> 
> Geez... read your last message and thought we were done! 
> 
> I don't believe this requirement is necessary.  An SCVP client that 
> doesn't 
> perform local path validation (i.e., a DPV client *only*) doesn't need 
> to 
> be able to assert this flag.  An SCVP client that is designed to always 
> perform local path validation (i.e., DPD *only*) might be designed so 
> this 
> was configurable, or could be designed to always assert this flag. 
> 
> Let's drop this one and claim victory/bipartisan agreement/etc... 
> 
> Thanks, 
> 
> Tim 
> 
> At 09:16 AM 7/14/2004 -0700, Michael Myers wrote: 
> >I would add one other requirement.  Clients MUST be capable of 
> asserting 
> >the flag. 
> > 
> >Mike 
> > 
> >-----Original Message----- 
> >From: [e-mail] 
> >[mailto:[e-mail]]On Behalf Of Tim Polk 
> >Sent: Wednesday, July 14, 2004 6:50 AM 
> >To: Russ Housley; [e-mail] 
> >Subject: Re: Unsigned DPD responses for SCVP15 
> > 
> > 
> > 
> > 
> > 
> >I also prefer the client-side flag option.  However, I *strongly* 
> >believe 
> >that the default behavior (i.e., in the absence of the flag) should be 
> >"signature is REQUIRED" on the SCVP response. 
> > 
> >In this way, the default behavior for SCVP always satisfies the 
> >requirements specified in RFC 3379.   Where the client has explicitly 
> >determined that source authentication is not required, the client may 
> >explicitly state this. 
> > 
> >I believe this option boils down to four fairly simple statements. 
> > 
> >(1) Where an SCVP request omits the "not going to authenticate" flag, 
> >the 
> >server is required to sign the response or return an error. 
> > 
> >(2) Where an SCVP request includes the flag, the server may include or 
> >omit 
> >the signature on the response.  (So, a server that *always* signs 
> >responses 
> >doesn't need to process this flag...) 
> > 
> >(3) An SCVP client MUST NOT assert the "not going to authenticate" flag 
> >and 
> >request a statement about validity. 
> > 
> >(4) Where the request did not assert the new flag, the SCVP client MUST 
> >process the digital signature on a response. 
> > 
> >I believe these changes would result in a protocol whose default 
> >behavior 
> >satisfies all the requirements in 3379, permits the employment of 
> >unsigned 
> >messages for DPD, and precludes any ambiguity in the implementation of 
> >mixed mode servers. 
> > 
> >Tim Polk 
> > 
> > 
> > 
> > 
> >At 12:38 PM 7/13/2004 -0400, Russ Housley wrote: 
> > 
> > 
> > >My personal preference Option #2; however, I think that absence of 
> this 
> > >flag should indicate that the response should be signed.  One needs 
> to 
> > >make a guess about deployment to select the best semantic for this 
> > >situation, and my guess is that server authentication will be 
> >important. 
> > > 
> > >Russ 
> > > 
> > > 
> > >Trevor Freeman wrote: 
> > >>I have been asked to add unsigned responses for DPD clients to 
> SCVP15. 
> > >>There are two models proposed on how we accomplish that both of 
> which 
> > >>meet the requirements for 3379. I would therefore like some feedback 
> >on 
> > >>how the group views the two mechanisms 
> > >> 
> > >>Global Server Policy that it is DPD only 
> > >>The first proposal is to make the option controlled by the server as 
> a 
> > >>global policy. Therefore the server would publish via policy that is 
> >only 
> > >>supports DPD as such never signs a response. DPV client and DPD 
> >clients 
> > >>wanting a signed response then know to use another server. 
> > >> 
> > >>SCVP Request option to not sign response 
> > >>The second option is to leave it to the client to signal to the 
> server 
> >it 
> > >>does not need a signature on the response by a new flag in the 
> request 
> > >>(or its twin the flag indicates it does want a signature on the 
> > >>response). This allows clients to be benevolent towards the server 
> by 
> > >>asking it to skip the signature. Server can still at their 
> discretion 
> > >>still sign. 
> > >> 
> > >>Needless to say it is possible to hybridize the two but I am hopeful 
> >we 
> > >>can try and keep this as simple as possible be picking on of the 
> two. 
> > >>Trevor 
> > > 
> > > 
> > > 
> > > 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJDQf6054780; Wed, 14 Jul 2004 12:13:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EJDPgQ054778; Wed, 14 Jul 2004 12:13:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6EJDOHf054772 for <[e-mail]>; Wed, 14 Jul 2004 12:13:24 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 21431 invoked by uid 0); 14 Jul 2004 19:08:08 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.10.112) by woodstock.binhost.com with SMTP; 14 Jul 2004 19:08:08 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Wed, 14 Jul 2004 15:13:51 -0400
To: "Michael Myers" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There is no need for DPV clients to assert the flag!

Russ

At 12:16 PM 7/14/2004, Michael Myers wrote:
>I would add one other requirement.  Clients MUST be capable of asserting
>the flag.
>
>Mike
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Tim Polk
>Sent: Wednesday, July 14, 2004 6:50 AM
>To: Russ Housley; [e-mail]
>Subject: Re: Unsigned DPD responses for SCVP15
>
>
>
>
>
>I also prefer the client-side flag option.  However, I *strongly*
>believe
>that the default behavior (i.e., in the absence of the flag) should be
>"signature is REQUIRED" on the SCVP response.
>
>In this way, the default behavior for SCVP always satisfies the
>requirements specified in RFC 3379.   Where the client has explicitly
>determined that source authentication is not required, the client may
>explicitly state this.
>
>I believe this option boils down to four fairly simple statements.
>
>(1) Where an SCVP request omits the "not going to authenticate" flag,
>the
>server is required to sign the response or return an error.
>
>(2) Where an SCVP request includes the flag, the server may include or
>omit
>the signature on the response.  (So, a server that *always* signs
>responses
>doesn't need to process this flag...)
>
>(3) An SCVP client MUST NOT assert the "not going to authenticate" flag
>and
>request a statement about validity.
>
>(4) Where the request did not assert the new flag, the SCVP client MUST
>process the digital signature on a response.
>
>I believe these changes would result in a protocol whose default
>behavior
>satisfies all the requirements in 3379, permits the employment of
>unsigned
>messages for DPD, and precludes any ambiguity in the implementation of
>mixed mode servers.
>
>Tim Polk
>
>
>
>
>At 12:38 PM 7/13/2004 -0400, Russ Housley wrote:
>
>
> >My personal preference Option #2; however, I think that absence of this
> >flag should indicate that the response should be signed.  One needs to
> >make a guess about deployment to select the best semantic for this
> >situation, and my guess is that server authentication will be
>important.
> >
> >Russ
> >
> >
> >Trevor Freeman wrote:
> >>I have been asked to add unsigned responses for DPD clients to SCVP15.
> >>There are two models proposed on how we accomplish that both of which
> >>meet the requirements for 3379. I would therefore like some feedback
>on
> >>how the group views the two mechanisms
> >>
> >>Global Server Policy that it is DPD only
> >>The first proposal is to make the option controlled by the server as a
> >>global policy. Therefore the server would publish via policy that is
>only
> >>supports DPD as such never signs a response. DPV client and DPD
>clients
> >>wanting a signed response then know to use another server.
> >>
> >>SCVP Request option to not sign response
> >>The second option is to leave it to the client to signal to the server
>it
> >>does not need a signature on the response by a new flag in the request
> >>(or its twin the flag indicates it does want a signature on the
> >>response). This allows clients to be benevolent towards the server by
> >>asking it to skip the signature. Server can still at their discretion
> >>still sign.
> >>
> >>Needless to say it is possible to hybridize the two but I am hopeful
>we
> >>can try and keep this as simple as possible be picking on of the two.
> >>Trevor
> >
> >
> >
> >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIw3DD052461; Wed, 14 Jul 2004 11:58:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EIw3fo052460; Wed, 14 Jul 2004 11:58:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIw2FW052454 for <[e-mail]>; Wed, 14 Jul 2004 11:58:02 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6EIw1813055; Wed, 14 Jul 2004 11:58:01 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Tim Polk" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Wed, 14 Jul 2004 11:57:23 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I thought we were done too until I read more carefully your proposed
text.  I do believe the requirement is necessary or I wouldn't have
brought it up.  The need to assert the flag cannot be 100% predicted
ahead of time.  Given the presumptive definition of the flag, I believe
interoperability would benefit.  It doesn't say the flag must be used,
but only that the capability we all worked so hard on to define is an
assumption rather than a stovepipe.

Mike



-----Original Message-----
From: Tim Polk [mailto:[e-mail]]
Sent: Wednesday, July 14, 2004 11:18 AM
To: Michael Myers; Russ Housley; [e-mail]
Subject: RE: Unsigned DPD responses for SCVP15



Mike,

Geez... read your last message and thought we were done!

I don't believe this requirement is necessary.  An SCVP client that
doesn't
perform local path validation (i.e., a DPV client *only*) doesn't need
to
be able to assert this flag.  An SCVP client that is designed to always
perform local path validation (i.e., DPD *only*) might be designed so
this
was configurable, or could be designed to always assert this flag.

Let's drop this one and claim victory/bipartisan agreement/etc...

Thanks,

Tim

At 09:16 AM 7/14/2004 -0700, Michael Myers wrote:
>I would add one other requirement.  Clients MUST be capable of
asserting
>the flag.
>
>Mike
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Tim Polk
>Sent: Wednesday, July 14, 2004 6:50 AM
>To: Russ Housley; [e-mail]
>Subject: Re: Unsigned DPD responses for SCVP15
>
>
>
>
>
>I also prefer the client-side flag option.  However, I *strongly*
>believe
>that the default behavior (i.e., in the absence of the flag) should be
>"signature is REQUIRED" on the SCVP response.
>
>In this way, the default behavior for SCVP always satisfies the
>requirements specified in RFC 3379.   Where the client has explicitly
>determined that source authentication is not required, the client may
>explicitly state this.
>
>I believe this option boils down to four fairly simple statements.
>
>(1) Where an SCVP request omits the "not going to authenticate" flag,
>the
>server is required to sign the response or return an error.
>
>(2) Where an SCVP request includes the flag, the server may include or
>omit
>the signature on the response.  (So, a server that *always* signs
>responses
>doesn't need to process this flag...)
>
>(3) An SCVP client MUST NOT assert the "not going to authenticate" flag
>and
>request a statement about validity.
>
>(4) Where the request did not assert the new flag, the SCVP client MUST
>process the digital signature on a response.
>
>I believe these changes would result in a protocol whose default
>behavior
>satisfies all the requirements in 3379, permits the employment of
>unsigned
>messages for DPD, and precludes any ambiguity in the implementation of
>mixed mode servers.
>
>Tim Polk
>
>
>
>
>At 12:38 PM 7/13/2004 -0400, Russ Housley wrote:
>
>
> >My personal preference Option #2; however, I think that absence of
this
> >flag should indicate that the response should be signed.  One needs
to
> >make a guess about deployment to select the best semantic for this
> >situation, and my guess is that server authentication will be
>important.
> >
> >Russ
> >
> >
> >Trevor Freeman wrote:
> >>I have been asked to add unsigned responses for DPD clients to
SCVP15.
> >>There are two models proposed on how we accomplish that both of
which
> >>meet the requirements for 3379. I would therefore like some feedback
>on
> >>how the group views the two mechanisms
> >>
> >>Global Server Policy that it is DPD only
> >>The first proposal is to make the option controlled by the server as
a
> >>global policy. Therefore the server would publish via policy that is
>only
> >>supports DPD as such never signs a response. DPV client and DPD
>clients
> >>wanting a signed response then know to use another server.
> >>
> >>SCVP Request option to not sign response
> >>The second option is to leave it to the client to signal to the
server
>it
> >>does not need a signature on the response by a new flag in the
request
> >>(or its twin the flag indicates it does want a signature on the
> >>response). This allows clients to be benevolent towards the server
by
> >>asking it to skip the signature. Server can still at their
discretion
> >>still sign.
> >>
> >>Needless to say it is possible to hybridize the two but I am hopeful
>we
> >>can try and keep this as simple as possible be picking on of the
two.
> >>Trevor
> >
> >
> >
> >





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIF2ts045073; Wed, 14 Jul 2004 11:15:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EIF2av045072; Wed, 14 Jul 2004 11:15:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIF0fB045060 for <[e-mail]>; Wed, 14 Jul 2004 11:15:01 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i6EIEIC0015770; Wed, 14 Jul 2004 14:14:18 -0400
Received: from krdp8.nist.gov (seclab14.ncsl.nist.gov [129.6.52.54]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i6EIE6mb027883; Wed, 14 Jul 2004 14:14:06 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 14 Jul 2004 14:17:44 -0400
To: "Michael Myers" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

Geez... read your last message and thought we were done!

I don't believe this requirement is necessary.  An SCVP client that doesn't 
perform local path validation (i.e., a DPV client *only*) doesn't need to 
be able to assert this flag.  An SCVP client that is designed to always 
perform local path validation (i.e., DPD *only*) might be designed so this 
was configurable, or could be designed to always assert this flag.

Let's drop this one and claim victory/bipartisan agreement/etc...

Thanks,

Tim

At 09:16 AM 7/14/2004 -0700, Michael Myers wrote:
>I would add one other requirement.  Clients MUST be capable of asserting
>the flag.
>
>Mike
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Tim Polk
>Sent: Wednesday, July 14, 2004 6:50 AM
>To: Russ Housley; [e-mail]
>Subject: Re: Unsigned DPD responses for SCVP15
>
>
>
>
>
>I also prefer the client-side flag option.  However, I *strongly*
>believe
>that the default behavior (i.e., in the absence of the flag) should be
>"signature is REQUIRED" on the SCVP response.
>
>In this way, the default behavior for SCVP always satisfies the
>requirements specified in RFC 3379.   Where the client has explicitly
>determined that source authentication is not required, the client may
>explicitly state this.
>
>I believe this option boils down to four fairly simple statements.
>
>(1) Where an SCVP request omits the "not going to authenticate" flag,
>the
>server is required to sign the response or return an error.
>
>(2) Where an SCVP request includes the flag, the server may include or
>omit
>the signature on the response.  (So, a server that *always* signs
>responses
>doesn't need to process this flag...)
>
>(3) An SCVP client MUST NOT assert the "not going to authenticate" flag
>and
>request a statement about validity.
>
>(4) Where the request did not assert the new flag, the SCVP client MUST
>process the digital signature on a response.
>
>I believe these changes would result in a protocol whose default
>behavior
>satisfies all the requirements in 3379, permits the employment of
>unsigned
>messages for DPD, and precludes any ambiguity in the implementation of
>mixed mode servers.
>
>Tim Polk
>
>
>
>
>At 12:38 PM 7/13/2004 -0400, Russ Housley wrote:
>
>
> >My personal preference Option #2; however, I think that absence of this
> >flag should indicate that the response should be signed.  One needs to
> >make a guess about deployment to select the best semantic for this
> >situation, and my guess is that server authentication will be
>important.
> >
> >Russ
> >
> >
> >Trevor Freeman wrote:
> >>I have been asked to add unsigned responses for DPD clients to SCVP15.
> >>There are two models proposed on how we accomplish that both of which
> >>meet the requirements for 3379. I would therefore like some feedback
>on
> >>how the group views the two mechanisms
> >>
> >>Global Server Policy that it is DPD only
> >>The first proposal is to make the option controlled by the server as a
> >>global policy. Therefore the server would publish via policy that is
>only
> >>supports DPD as such never signs a response. DPV client and DPD
>clients
> >>wanting a signed response then know to use another server.
> >>
> >>SCVP Request option to not sign response
> >>The second option is to leave it to the client to signal to the server
>it
> >>does not need a signature on the response by a new flag in the request
> >>(or its twin the flag indicates it does want a signature on the
> >>response). This allows clients to be benevolent towards the server by
> >>asking it to skip the signature. Server can still at their discretion
> >>still sign.
> >>
> >>Needless to say it is possible to hybridize the two but I am hopeful
>we
> >>can try and keep this as simple as possible be picking on of the two.
> >>Trevor
> >
> >
> >
> >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EGHdcO024754; Wed, 14 Jul 2004 09:17:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EGHdBa024753; Wed, 14 Jul 2004 09:17:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EGHdwg024747 for <[e-mail]>; Wed, 14 Jul 2004 09:17:39 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6EGHYS64271; Wed, 14 Jul 2004 09:17:34 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Tim Polk" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Wed, 14 Jul 2004 09:16:55 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would add one other requirement.  Clients MUST be capable of asserting
the flag.

Mike

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Tim Polk
Sent: Wednesday, July 14, 2004 6:50 AM
To: Russ Housley; [e-mail]
Subject: Re: Unsigned DPD responses for SCVP15





I also prefer the client-side flag option.  However, I *strongly*
believe
that the default behavior (i.e., in the absence of the flag) should be
"signature is REQUIRED" on the SCVP response.

In this way, the default behavior for SCVP always satisfies the
requirements specified in RFC 3379.   Where the client has explicitly
determined that source authentication is not required, the client may
explicitly state this.

I believe this option boils down to four fairly simple statements.

(1) Where an SCVP request omits the "not going to authenticate" flag,
the
server is required to sign the response or return an error.

(2) Where an SCVP request includes the flag, the server may include or
omit
the signature on the response.  (So, a server that *always* signs
responses
doesn't need to process this flag...)

(3) An SCVP client MUST NOT assert the "not going to authenticate" flag
and
request a statement about validity.

(4) Where the request did not assert the new flag, the SCVP client MUST
process the digital signature on a response.

I believe these changes would result in a protocol whose default
behavior
satisfies all the requirements in 3379, permits the employment of
unsigned
messages for DPD, and precludes any ambiguity in the implementation of
mixed mode servers.

Tim Polk




At 12:38 PM 7/13/2004 -0400, Russ Housley wrote:


>My personal preference Option #2; however, I think that absence of this
>flag should indicate that the response should be signed.  One needs to
>make a guess about deployment to select the best semantic for this
>situation, and my guess is that server authentication will be
important.
>
>Russ
>
>
>Trevor Freeman wrote:
>>I have been asked to add unsigned responses for DPD clients to SCVP15.
>>There are two models proposed on how we accomplish that both of which
>>meet the requirements for 3379. I would therefore like some feedback
on
>>how the group views the two mechanisms
>>
>>Global Server Policy that it is DPD only
>>The first proposal is to make the option controlled by the server as a
>>global policy. Therefore the server would publish via policy that is
only
>>supports DPD as such never signs a response. DPV client and DPD
clients
>>wanting a signed response then know to use another server.
>>
>>SCVP Request option to not sign response
>>The second option is to leave it to the client to signal to the server
it
>>does not need a signature on the response by a new flag in the request
>>(or its twin the flag indicates it does want a signature on the
>>response). This allows clients to be benevolent towards the server by
>>asking it to skip the signature. Server can still at their discretion
>>still sign.
>>
>>Needless to say it is possible to hybridize the two but I am hopeful
we
>>can try and keep this as simple as possible be picking on of the two.
>>Trevor
>
>
>
>





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFaYDu012015; Wed, 14 Jul 2004 08:36:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EFaY1g012014; Wed, 14 Jul 2004 08:36:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFaYRK011995 for <[e-mail]>; Wed, 14 Jul 2004 08:36:34 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6EFaXS56131; Wed, 14 Jul 2004 08:36:33 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Wed, 14 Jul 2004 08:35:54 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes.  I'm all for the flag.  And I said, I can live with the default as
defined.  So I'll just leave it at that.

Mike

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Russ Housley
Sent: Wednesday, July 14, 2004 7:02 AM
To: Michael Myers; [e-mail]
Subject: RE: Unsigned DPD responses for SCVP15



Mike:

Different servers will have different default path discovery policies.

RFC 3379 says:

    For the client to be confident that all of the elements from the
    response originate from the expected DPD server, an authenticated
    response MAY be required.  For example, the server might sign the
    response or data authentication might also be achieved using a
    lower-layer security protocol.

So, all we are discussing is whether the protocol requirement in this
MAY
statement is the default or not.

Russ




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EEMtEQ079486; Wed, 14 Jul 2004 07:22:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EEMtJv079484; Wed, 14 Jul 2004 07:22:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EEMsvK079442 for <[e-mail]>; Wed, 14 Jul 2004 07:22:54 -0700 (PDT) (envelope-from [e-mail])
Content-class: urn:content-classes:message
Subject: RE: Unsigned DPD responses for SCVP15
MIME-Version: 1.0
Date: Wed, 14 Jul 2004 10:23:17 -0400
Content-Type: multipart/signed; boundary="----=_NextPart_000_001E_01C4698C.84789750"; protocol="application/x-pkcs7-signature"; micalg=SHA1
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Unsigned DPD responses for SCVP15
Thread-Index: AcRprPN7f4/5/nAeSx+ugCiwXK6C4gAALrKg
From: "Dave Engberg" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01C4698C.84789750
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


I have a mild preference for defaulting to "unsigned permitted if no request
flag present", but would also be happy with Tim's proposal.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tim Polk
Sent: Wednesday, July 14, 2004 9:50 AM
To: Russ Housley; [e-mail]
Subject: Re: Unsigned DPD responses for SCVP15




I also prefer the client-side flag option.  However, I *strongly* believe
that the default behavior (i.e., in the absence of the flag) should be
"signature is REQUIRED" on the SCVP response.

In this way, the default behavior for SCVP always satisfies the 
requirements specified in RFC 3379.   Where the client has explicitly 
determined that source authentication is not required, the client may
explicitly state this.

I believe this option boils down to four fairly simple statements.

(1) Where an SCVP request omits the "not going to authenticate" flag, the
server is required to sign the response or return an error.

(2) Where an SCVP request includes the flag, the server may include or omit
the signature on the response.  (So, a server that *always* signs responses
doesn't need to process this flag...)

(3) An SCVP client MUST NOT assert the "not going to authenticate" flag and
request a statement about validity.

(4) Where the request did not assert the new flag, the SCVP client MUST
process the digital signature on a response.

I believe these changes would result in a protocol whose default behavior
satisfies all the requirements in 3379, permits the employment of unsigned
messages for DPD, and precludes any ambiguity in the implementation of mixed
mode servers.

Tim Polk



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII1jCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA4wwggL1oAMCAQICARkwDQYJKoZI
hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE
AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDQwNzEyMTMwMjE4WhcNMDUw
NzI2MTMwMjE4WjBnMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRYwFAYD
VQQDEw1EYXZpZCBFbmdiZXJnMSYwJAYJKoZIhvcNAQkBFhdkZW5nYmVyZ0Bjb3Jlc3RyZWV0LmNv
bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJXX+JZ1oaEb2TCawk31rzpOIRTHZyP
UGTUGNyMasqczNZATvXu2RTlon8dwEuO4evr5KE9iDe0jQSkj1g5HBEsFAH+JPU7Y0uYupm/kiyr
6FiyhBCQtWhrcNii0yahcIEbH/fBAf5V10Y2wHKFrPH6uTrj+YGhBpaXxkEZpXCe2QZtkR/kcbKa
QaMCaU27vLAZ4QT6vJTf5oG/SD1KU232kYttiLeRjnePWipH8In7crGPhgJCeQP5UtE9uHDjOStt
eZxXsWAzU7oW9nb9jHL2xOWPQyhBs4JaPvgSdFkenI6L8flsQm72U8lrV/4dqKu330m5pH89XTYl
o2PcqIUCAwEAAaOB2DCB1TAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDov
L2NybC5nZW90cnVzdC5jb20vY3Jscy9jb3Jlc3RyZWV0LmNybDAiBgNVHREEGzAZgRdkZW5nYmVy
Z0Bjb3Jlc3RyZWV0LmNvbTAfBgNVHSMEGDAWgBTY7H+TGMVmA8MQbDwE9neFPv8LtjBABggrBgEF
BQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9nZW90cnVzdC1vY3NwLmNvcmVzdHJlZXQuY29t
LzANBgkqhkiG9w0BAQUFAAOBgQAtAQMtzyIzARw6d/sy1qPn+Mqr7aPEJFofkSW57NE639PcrXmC
E9LzVm5mtmoNkeeyHDOgla79ez8MzndDxhlwQvNdaiu124jWbgEoHC1q2K4McbaJlxjhPbCpFr7Z
CzxQxOmFxXjb16XGotrxX1aj2YWuAAdt9H3x+tHBXCn+WDGCAxowggMWAgEBMFcwUjELMAkGA1UE
BhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkCARkwCQYFKw4DAhoFAKCCAZgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNzE0MTQyMjUxWjAjBgkqhkiG9w0BCQQxFgQUU/b+Nlwz
nU7Hhd/j66+y80HHICIwZgYJKwYBBAGCNxAEMVkwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP
Q29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0
eQIBGTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG
9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgsq
hkiG9w0BCRACCzFZoFcwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEp
MCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCARkwDQYJKoZIhvcNAQEB
BQAEggEAWwncF8UluEtRBqVpquL/50WgRA4ismn2j6w3L0TubHWpWCxwftbQkcram/FkY+FU7x0n
lG0WCeuuQd5EnkeyVce/nXFDVF6E8GOuVwah88LYxZJ0XIukNgBOH8NhFc3WnCMY9B7bCgO8BF3q
YJRmq5tNMXZokDCgr5sqlX3H8CieGhpNnk3lmIuesjJZFz09L6B7Pvr8zhbaXjfC7lgx/YlFafs0
OMBkinMkMof04C1JV6x1lYzDvCxHVuOBRunxCD/end1FaFsURQeNkkZaJANX65MSfQPdtsNvwZkP
rnlmfHu7mEynm2f3GzZpqWvwNx9qeSx8N7tdxl42Pw9+PgAAAAAAAA==

------=_NextPart_000_001E_01C4698C.84789750--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EE1wha072196; Wed, 14 Jul 2004 07:01:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EE1w60072195; Wed, 14 Jul 2004 07:01:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6EE1vBB072178 for <[e-mail]>; Wed, 14 Jul 2004 07:01:58 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 7370 invoked by uid 0); 14 Jul 2004 13:56:40 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.160.169) by woodstock.binhost.com with SMTP; 14 Jul 2004 13:56:40 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Wed, 14 Jul 2004 10:02:01 -0400
To: "Michael Myers" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike:

Different servers will have different default path discovery policies.

RFC 3379 says:

    For the client to be confident that all of the elements from the
    response originate from the expected DPD server, an authenticated
    response MAY be required.  For example, the server might sign the
    response or data authentication might also be achieved using a
    lower-layer security protocol.

So, all we are discussing is whether the protocol requirement in this MAY 
statement is the default or not.

Russ

At 05:47 PM 7/13/2004, Michael Myers wrote:
>Russ,
>
>So what if no optional parameters are present in the request to
>facilitate path navigation?  What if all the defined ASN.1 defaults are
>taken?  What if its a simple enterprise-level issue?  Does it not make
>sense to default to the larger case, and to reserve an upscope in
>security diligence to those environments subject to cross-domain source
>authenticity concerns? Or is the latter the larger case? I argue that,
>in the absence of the flag, should it come to pass in -15, SCVP
>responses containing ONLY {path, rev-info} MAY be signed.
>
>Mike
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Tuesday, July 13, 2004 1:54 PM
>To: Michael Myers; [e-mail]
>Subject: RE: Unsigned DPD responses for SCVP15
>
>
>In DPD, the server is doing more than just returning signed objects.
>The
>server is constructing a certification path too.  In a world with
>cross-certification and bridge CAs, there can be more than one choice
>for
>valid paths.  This is a topic that has received plenty of discussion
>elsewhere, and I hope we do not need to revisit all of the nooks and
>crannies of that topic here.  So, a different collection of signed
>object
>can be returned, each of which is valid, and each of which represents a
>different amount of effort on the part of the client to validate.  Given
>this situation, I believe that the client will want to be able to
>confirm
>the source of the path.
>
>Russ
>
>
>At 01:38 PM 7/13/2004, Michael Myers wrote:
> >Russ,
> >
> >As you know, I disagree on the default.  My point is that DPD as
> >originally conceived and further defined by the requirements
> >RFC is to a first degree simply a proxy for the various
> >protocols and schemas devised over the years to acquire these
> >data.
> >
> >I can live with the default as defined but I think it is useful
> >and necessary to establish why super-signing of previously
> >signed data is a good thing.  Hypothetical replay attacks have
> >been proposed.  OK, fine.  So we have a flag that enables an
> >environment to assert source authenticity so those become
> >reality.
> >
> >But these data, i.e. {path, rev-info}, are not only signed but
> >dated with respect to their reliability.  That was the basis of
> >the original theory behind the notion that these data can be
> >made public without any concern for their source.  I have yet to
> >hear a refutation of those prior assumptions.
> >
> >If source authenticity in important in this instance, does that
> >then mean all extant protocols and schemas are at risk?  If so,
> >why?
> >
> >Mike



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EDlLll068308; Wed, 14 Jul 2004 06:47:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EDlLpR068307; Wed, 14 Jul 2004 06:47:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EDlK2O068283 for <[e-mail]>; Wed, 14 Jul 2004 06:47:21 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i6EDlBaK032002; Wed, 14 Jul 2004 09:47:11 -0400
Received: from krdp8.nist.gov (seclab14.ncsl.nist.gov [129.6.52.54]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i6EDkomb006494; Wed, 14 Jul 2004 09:46:50 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 14 Jul 2004 09:50:28 -0400
To: Russ Housley <[e-mail]>, [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: Unsigned DPD responses for SCVP15
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I also prefer the client-side flag option.  However, I *strongly* believe 
that the default behavior (i.e., in the absence of the flag) should be 
"signature is REQUIRED" on the SCVP response.

In this way, the default behavior for SCVP always satisfies the 
requirements specified in RFC 3379.   Where the client has explicitly 
determined that source authentication is not required, the client may 
explicitly state this.

I believe this option boils down to four fairly simple statements.

(1) Where an SCVP request omits the "not going to authenticate" flag, the 
server is required to sign the response or return an error.

(2) Where an SCVP request includes the flag, the server may include or omit 
the signature on the response.  (So, a server that *always* signs responses 
doesn't need to process this flag...)

(3) An SCVP client MUST NOT assert the "not going to authenticate" flag and 
request a statement about validity.

(4) Where the request did not assert the new flag, the SCVP client MUST 
process the digital signature on a response.

I believe these changes would result in a protocol whose default behavior 
satisfies all the requirements in 3379, permits the employment of unsigned 
messages for DPD, and precludes any ambiguity in the implementation of 
mixed mode servers.

Tim Polk




At 12:38 PM 7/13/2004 -0400, Russ Housley wrote:


>My personal preference Option #2; however, I think that absence of this 
>flag should indicate that the response should be signed.  One needs to 
>make a guess about deployment to select the best semantic for this 
>situation, and my guess is that server authentication will be important.
>
>Russ
>
>
>Trevor Freeman wrote:
>>I have been asked to add unsigned responses for DPD clients to SCVP15. 
>>There are two models proposed on how we accomplish that both of which 
>>meet the requirements for 3379. I would therefore like some feedback on 
>>how the group views the two mechanisms
>>
>>Global Server Policy that it is DPD only
>>The first proposal is to make the option controlled by the server as a 
>>global policy. Therefore the server would publish via policy that is only 
>>supports DPD as such never signs a response. DPV client and DPD clients 
>>wanting a signed response then know to use another server.
>>
>>SCVP Request option to not sign response
>>The second option is to leave it to the client to signal to the server it 
>>does not need a signature on the response by a new flag in the request 
>>(or its twin the flag indicates it does want a signature on the 
>>response). This allows clients to be benevolent towards the server by 
>>asking it to skip the signature. Server can still at their discretion 
>>still sign.
>>
>>Needless to say it is possible to hybridize the two but I am hopeful we 
>>can try and keep this as simple as possible be picking on of the two.
>>Trevor
>
>
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNWYRg092490; Tue, 13 Jul 2004 16:32:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DNWYtT092489; Tue, 13 Jul 2004 16:32:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNWXrR092483 for <[e-mail]>; Tue, 13 Jul 2004 16:32:33 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6DNWWS77552; Tue, 13 Jul 2004 16:32:32 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 16:31:52 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <p06110401bd198e07d7df@[10.84.130.144]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

There exists no SHALL statement in the SCVP I-D that compels an
environment to institute a locally unique and technically enforceable
policy with respect to SCVP.  Nor does there exist guidance on how to
implement such.  I think we are best off with the flag.

Mike




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DMhkDH089216; Tue, 13 Jul 2004 15:43:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DMhkCA089215; Tue, 13 Jul 2004 15:43:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DMhjJO089206 for <[e-mail]>; Tue, 13 Jul 2004 15:43:46 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.84.130.144] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i6DMhX7Z025700; Tue, 13 Jul 2004 18:43:35 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06110401bd198e07d7df@[10.84.130.144]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 13 Jul 2004 09:10:54 -0400
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 6:57 PM -0700 7/12/04, Michael Myers wrote:
>Given the two alternatives of:
>
>1. An approach requiring explicit policies; or
>
>2. Client-side assertion of a new flag as Tim proposed;
>
>I prefer #2 for the following reasons.
>
>The SCVP I-D asserts no requirement that a server MUST have a
>unique policy.  The I-D supports this by making optional all
>such elements beyond the default defined by RFC3280.  An
>explicit OID-based approach forces the issue for servers that
>wish to support unsigned DPD.

I thought that the requirements RFC required a default policy, which 
would be unique, to allow a client to not have to always specify a 
policy. of course, one does not take full advantage of the 
capabilities of SCVP if you do this, i.e., you don't get to use 
application context specific cert validation.

>A non-trivial subset of environments don't even know what an OID
>is (think credit unions), let alone the technical details of
>what must go into a policy as it relates to this context.  The
>contents of such are not well defined.  Absent that, there
>exists no basis to implement correponding enforcement logic that
>is ensured to be interoperable across the Internet.

This paragraph seems very confusing. Of course many users will not 
know what OIDs are, but they also usually don't know many details of 
Internet technology are. what "enforcement logic" are you referring 
to here? Cert evaluation is, in general, a local matter controlled by 
a relying party. the problem of a cert user choosing the right cert 
to provide to a relying party, is outside the scope of SCVP.

>The I-D provides no means for technical implementation and
>enforcement of a policy-based approach; it is non-implementable.
>Further, the I-D provides no means to discriminate between DPD
>and DPV.  Even assuming in the future a consensus on a
>technically enforceable security assertion grammar, the subject
>I-D defines no technical means to even say "DPD".

I have no idea what you are referring to in this paragraph. Please try again.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DLmDZs084762; Tue, 13 Jul 2004 14:48:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DLmDZm084761; Tue, 13 Jul 2004 14:48:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DLmD6F084755 for <[e-mail]>; Tue, 13 Jul 2004 14:48:13 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6DLmGS55347; Tue, 13 Jul 2004 14:48:16 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 14:47:37 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

So what if no optional parameters are present in the request to
facilitate path navigation?  What if all the defined ASN.1 defaults are
taken?  What if its a simple enterprise-level issue?  Does it not make
sense to default to the larger case, and to reserve an upscope in
security diligence to those environments subject to cross-domain source
authenticity concerns? Or is the latter the larger case? I argue that,
in the absence of the flag, should it come to pass in -15, SCVP
responses containing ONLY {path, rev-info} MAY be signed.

Mike

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Tuesday, July 13, 2004 1:54 PM
To: Michael Myers; [e-mail]
Subject: RE: Unsigned DPD responses for SCVP15


In DPD, the server is doing more than just returning signed objects.
The
server is constructing a certification path too.  In a world with
cross-certification and bridge CAs, there can be more than one choice
for
valid paths.  This is a topic that has received plenty of discussion
elsewhere, and I hope we do not need to revisit all of the nooks and
crannies of that topic here.  So, a different collection of signed
object
can be returned, each of which is valid, and each of which represents a
different amount of effort on the part of the client to validate.  Given
this situation, I believe that the client will want to be able to
confirm
the source of the path.

Russ


At 01:38 PM 7/13/2004, Michael Myers wrote:
>Russ,
>
>As you know, I disagree on the default.  My point is that DPD as
>originally conceived and further defined by the requirements
>RFC is to a first degree simply a proxy for the various
>protocols and schemas devised over the years to acquire these
>data.
>
>I can live with the default as defined but I think it is useful
>and necessary to establish why super-signing of previously
>signed data is a good thing.  Hypothetical replay attacks have
>been proposed.  OK, fine.  So we have a flag that enables an
>environment to assert source authenticity so those become
>reality.
>
>But these data, i.e. {path, rev-info}, are not only signed but
>dated with respect to their reliability.  That was the basis of
>the original theory behind the notion that these data can be
>made public without any concern for their source.  I have yet to
>hear a refutation of those prior assumptions.
>
>If source authenticity in important in this instance, does that
>then mean all extant protocols and schemas are at risk?  If so,
>why?
>
>Mike




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKrEK0080526; Tue, 13 Jul 2004 13:53:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DKrEc6080525; Tue, 13 Jul 2004 13:53:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6DKrD8K080519 for <[e-mail]>; Tue, 13 Jul 2004 13:53:14 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 24535 invoked by uid 0); 13 Jul 2004 20:48:11 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.188.72) by woodstock.binhost.com with SMTP; 13 Jul 2004 20:48:11 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Tue, 13 Jul 2004 16:53:30 -0400
To: "Michael Myers" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In DPD, the server is doing more than just returning signed objects.  The 
server is constructing a certification path too.  In a world with 
cross-certification and bridge CAs, there can be more than one choice for 
valid paths.  This is a topic that has received plenty of discussion 
elsewhere, and I hope we do not need to revisit all of the nooks and 
crannies of that topic here.  So, a different collection of signed object 
can be returned, each of which is valid, and each of which represents a 
different amount of effort on the part of the client to validate.  Given 
this situation, I believe that the client will want to be able to confirm 
the source of the path.

Russ


At 01:38 PM 7/13/2004, Michael Myers wrote:
>Russ,
>
>As you know, I disagree on the default.  My point is that DPD as
>originally conceived and further defined by the requirements
>RFC is to a first degree simply a proxy for the various
>protocols and schemas devised over the years to acquire these
>data.
>
>I can live with the default as defined but I think it is useful
>and necessary to establish why super-signing of previously
>signed data is a good thing.  Hypothetical replay attacks have
>been proposed.  OK, fine.  So we have a flag that enables an
>environment to assert source authenticity so those become
>reality.
>
>But these data, i.e. {path, rev-info}, are not only signed but
>dated with respect to their reliability.  That was the basis of
>the original theory behind the notion that these data can be
>made public without any concern for their source.  I have yet to
>hear a refutation of those prior assumptions.
>
>If source authenticity in important in this instance, does that
>then mean all extant protocols and schemas are at risk?  If so,
>why?
>
>Mike
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Russ Housley
>Sent: Tuesday, July 13, 2004 9:39 AM
>To: [e-mail]
>Subject: Re: Unsigned DPD responses for SCVP15
>
>
>
>
>My personal preference Option #2; however, I think that absence
>of this
>flag should indicate that the response should be signed.  One
>needs to make
>a guess about deployment to select the best semantic for this
>situation,
>and my guess is that server authentication will be important.
>
>Russ
>
>
>Trevor Freeman wrote:
> >I have been asked to add unsigned responses for DPD clients to
>SCVP15.
> >There are two models proposed on how we accomplish that both of
>which meet
> >the requirements for 3379. I would therefore like some feedback
>on how the
> >group views the two mechanisms
> >
> >Global Server Policy that it is DPD only
> >The first proposal is to make the option controlled by the
>server as a
> >global policy. Therefore the server would publish via policy
>that is only
> >supports DPD as such never signs a response. DPV client and DPD
>clients
> >wanting a signed response then know to use another server.
> >
> >SCVP Request option to not sign response
> >The second option is to leave it to the client to signal to the
>server it
> >does not need a signature on the response by a new flag in the
>request (or
> >its twin the flag indicates it does want a signature on the
>response).
> >This allows clients to be benevolent towards the server by
>asking it to
> >skip the signature. Server can still at their discretion still
>sign.
> >
> >Needless to say it is possible to hybridize the two but I am
>hopeful we
> >can try and keep this as simple as possible be picking on of
>the two.
> >Trevor



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DK4ket077066; Tue, 13 Jul 2004 13:04:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DK4k96077065; Tue, 13 Jul 2004 13:04:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DK4iTF077054 for <[e-mail]>; Tue, 13 Jul 2004 13:04:45 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10444; Tue, 13 Jul 2004 16:04:46 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pi-10.txt
Date: Tue, 13 Jul 2004 16:04:46 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Permanent Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-10.txt
	Pages		: 13
	Date		: 2004-7-13
	
This document define a new form of name, called permanent 
identifier, that may be included in the subjectAltName extension 
of a public key certificate issued to an entity.
The permanent identifier is an optional feature that may be used 
by a CA to indicate that the certificate relates to the same 
entity even if the name or the affiliation of that entity stored 
in the subject or another name form in the subjectAltName extension 
has changed.
The subject name, carried in the subject field, is only unique 
for each subject entity certified by the one CA as defined by the 
issuer name field. Also, the new name form can carry a 
name that is unique for each subject entity certified by a CA.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-pi-10.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-pi-10.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-pi-10.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DIugRk071723; Tue, 13 Jul 2004 11:56:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DIug8g071722; Tue, 13 Jul 2004 11:56:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DIugTg071716 for <[e-mail]>; Tue, 13 Jul 2004 11:56:42 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6DIuiS20313; Tue, 13 Jul 2004 11:56:44 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 11:56:06 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

There is no requirement that an SCVP server MUST operate under an
explicit and technically enforceable policy document.  There is no SHALL
statement to this effect in the Sections 3, 4 or 5.  A casual parse of
the optional and default elements of SCVP's ASN.1 supports this.

I see that you ultimately restated your original request to the WG.
Thus Russ, Dave, Denis and I are still back to now what is your option
(B).

Mike



-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: Tuesday, July 13, 2004 11:29 AM
To: Michael Myers; [e-mail]
Subject: RE: Unsigned DPD responses for SCVP15


Hi Mike,
Let me restate the question then.
The SCVP server publishes a policy document (see SCVP section 6) which
defines the default server behavior for that instance of server and the
set of validation policies it recognizes. We can add a flag to that
policy to indicate the server will only support DPD and in that mode the
server would not sign SCVP responses. We could also add another flag to
say the server was cached responses only.

The alternative if to have the client use a request flag and the server
can either process the request or return an error. If the objective to
support DPD only servers then having the server publish its DPD only
seems cleaner and simpler from the client perspective rather than have
the DPV client try and get an error back.

There is still the unanswered question of the value of having an SCVP
server support mixed mode operation i.e. it can return either signed or
unsigned responses based on the request flag. With the above server
policy flag we can support always sign or never sign which means I ca
sign all responses or lock a server to DPD only and never sign
responses. If you want to have a low cost to deploy server then I would
have thought you would lock it down to DPD only. Once you take the cost
hit to deploy a  signing SCVP server, beyond the CPU savings for not
dsigning some responses, what is the benefit over always signing policy
if you have a signing server given requests can be anonymous?

Therefore to support unsigned DPD do we

(A) add a flag to the Server policy response (SCVP section 6) to allow
the server to always sign or never sign?
Or
(B) Do we add a flag to the client request to allow the client to
express a preference to sign or not

If we want to support DPD only servers then option A meets that goal. If
we want to support mixed mode operation where a SCVP server can support
both signed and unsigned responses and that that there is tangible
benefits to mixed mode over always signing vs. never signing, then we
need option B.


Trevor

* -----Original Message-----
* From: Michael Myers [mailto:[e-mail]]
* Sent: Tuesday, July 13, 2004 10:26 AM
* To: Trevor Freeman; [e-mail]
* Subject: RE: Unsigned DPD responses for SCVP15
*
* Trevor,
*
* I believe Dave, Denis and I thought we were talking two
* alternative mechanisms to address the unsigned DPD consensus:  a
* mechanism based on explicit policy OR a mechanism based on a new
* request flag, as you had earlier posted.
*
* Your discussion below, i.e. "it seems prudent to have a flag in
* the server policy" is confusing in that context.
*
* Please clarify what you are asking the WG to consider.
*
* Mike




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DIShgK070064; Tue, 13 Jul 2004 11:28:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DISh5g070063; Tue, 13 Jul 2004 11:28:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DISgJM070057 for <[e-mail]>; Tue, 13 Jul 2004 11:28:42 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 13 Jul 2004 11:28:42 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 Jul 2004 11:28:46 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Jul 2004 11:28:47 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Jul 2004 11:28:38 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 11:28:46 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Unsigned DPD responses for SCVP15
Thread-Index: AcRo/nx/AaaoEu2NRzODJlWYHxBSswAA1paQ
From: "Trevor Freeman" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 13 Jul 2004 18:28:38.0978 (UTC) FILETIME=[377C0A20:01C46907]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6DISgJM070058
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Mike,
Let me restate the question then. 
The SCVP server publishes a policy document (see SCVP section 6) which
defines the default server behavior for that instance of server and the
set of validation policies it recognizes. We can add a flag to that
policy to indicate the server will only support DPD and in that mode the
server would not sign SCVP responses. We could also add another flag to
say the server was cached responses only.

The alternative if to have the client use a request flag and the server
can either process the request or return an error. If the objective to
support DPD only servers then having the server publish its DPD only
seems cleaner and simpler from the client perspective rather than have
the DPV client try and get an error back.

There is still the unanswered question of the value of having an SCVP
server support mixed mode operation i.e. it can return either signed or
unsigned responses based on the request flag. With the above server
policy flag we can support always sign or never sign which means I can
sign all responses or lock a server to DPD only and never sign
responses. If you want to have a low cost to deploy server then I would
have thought you would lock it down to DPD only. Once you take the cost
hit to deploy a  signing SCVP server, beyond the CPU savings for not
signing some responses, what is the benefit over always signing policy
if you have a signing server given requests can be anonymous?

Therefore to support unsigned DPD do we 

(A) add a flag to the Server policy response (SCVP section 6) to allow
the server to always sign or never sign?
Or
(B) Do we add a flag to the client request to allow the client to
express a preference to sign or not

If we want to support DPD only servers then option A meets that goal. If
we want to support mixed mode operation where a SCVP server can support
both signed and unsigned responses and that that there is tangible
benefits to mixed mode over always signing vs. never signing, then we
need option B.

 
Trevor

* -----Original Message-----
* From: Michael Myers [mailto:[e-mail]]
* Sent: Tuesday, July 13, 2004 10:26 AM
* To: Trevor Freeman; [e-mail]
* Subject: RE: Unsigned DPD responses for SCVP15
* 
* Trevor,
* 
* I believe Dave, Denis and I thought we were talking two
* alternative mechanisms to address the unsigned DPD consensus:  a
* mechanism based on explicit policy OR a mechanism based on a new
* request flag, as you had earlier posted.
* 
* Your discussion below, i.e. "it seems prudent to have a flag in
* the server policy" is confusing in that context.
* 
* Please clarify what you are asking the WG to consider.
* 
* Mike
* 
* 
* 
* 
* -----Original Message-----
* From: Trevor Freeman [mailto:[e-mail]]
* Sent: Tuesday, July 13, 2004 10:06 AM
* To: Michael Myers; [e-mail]
* Subject: RE: Unsigned DPD responses for SCVP15
* 
* 
* 
* Mike,
* We seem to have merges multiple threads here. The question on
* how SCVP
* supports unsigned DPD reprocess was the topic of this thread.
* 
* Tim proposed a new optional flag in the request. Given some of
* the other
* discussions where in some instances SCVP server would be
* unwilling to do
* anything other than return unsigned responses, it seems prudent
* to have
* a flag in the server policy so DPV clients and DPD clients
* wanting
* signed responses don't waste their time. Given that SCVP
* requests can be
* unauthenticated, what is the benefit of having a SCVP server
* which
* returns both signed and unsigned responses depending on the
* unauthenticated request? That scenario today would have the
* server
* signing all response and the client can choose to ignore the
* signature
* if required. Concerns around server security or sever
* scalability, or
* freshness of SCVP responses are address by having a server only
* do
* unsigned DPD responses. I am simply trying to understand what
* problem we
* seek to address by the mixed mode SCVP server.
* 
* Trevor
* 
* * -----Original Message-----
* * From: Michael Myers [mailto:[e-mail]]
* * Sent: Monday, July 12, 2004 6:58 PM
* * To: Trevor Freeman; [e-mail]
* * Subject: RE: Unsigned DPD responses for SCVP15
* *
* * Given the two alternatives of:
* *
* * 1. An approach requiring explicit policies; or
* *
* * 2. Client-side assertion of a new flag as Tim proposed;
* *
* * I prefer #2 for the following reasons.
* *
* * The SCVP I-D asserts no requirement that a server MUST have a
* * unique policy.  The I-D supports this by making optional all
* * such elements beyond the default defined by RFC3280.  An
* * explicit OID-based approach forces the issue for servers that
* * wish to support unsigned DPD.
* *
* * A non-trivial subset of environments don't even know what an
* OID
* * is (think credit unions), let alone the technical details of
* * what must go into a policy as it relates to this context.  The
* * contents of such are not well defined.  Absent that, there
* * exists no basis to implement correponding enforcement logic
* that
* * is ensured to be interoperable across the Internet.
* *
* * The I-D provides no means for technical implementation and
* * enforcement of a policy-based approach; it is
* non-implementable.
* * Further, the I-D provides no means to discriminate between DPD
* * and DPV.  Even assuming in the future a consensus on a
* * technically enforceable security assertion grammar, the
* subject
* * I-D defines no technical means to even say "DPD".
* *
* * Mike
* *
* *
* 
* 
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DHd41H064580; Tue, 13 Jul 2004 10:39:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DHd4Qf064579; Tue, 13 Jul 2004 10:39:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DHd304064573 for <[e-mail]>; Tue, 13 Jul 2004 10:39:03 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6DHd5S03870; Tue, 13 Jul 2004 10:39:05 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 10:38:27 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

As you know, I disagree on the default.  My point is that DPD as
originally conceived and further defined by the requirements
RFC is to a first degree simply a proxy for the various
protocols and schemas devised over the years to acquire these
data.

I can live with the default as defined but I think it is useful
and necessary to establish why super-signing of previously
signed data is a good thing.  Hypothetical replay attacks have
been proposed.  OK, fine.  So we have a flag that enables an
environment to assert source authenticity so those become
reality.

But these data, i.e. {path, rev-info}, are not only signed but
dated with respect to their reliability.  That was the basis of
the original theory behind the notion that these data can be
made public without any concern for their source.  I have yet to
hear a refutation of those prior assumptions.

If source authenticity in important in this instance, does that
then mean all extant protocols and schemas are at risk?  If so,
why?

Mike

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Russ Housley
Sent: Tuesday, July 13, 2004 9:39 AM
To: [e-mail]
Subject: Re: Unsigned DPD responses for SCVP15




My personal preference Option #2; however, I think that absence
of this
flag should indicate that the response should be signed.  One
needs to make
a guess about deployment to select the best semantic for this
situation,
and my guess is that server authentication will be important.

Russ


Trevor Freeman wrote:
>I have been asked to add unsigned responses for DPD clients to
SCVP15.
>There are two models proposed on how we accomplish that both of
which meet
>the requirements for 3379. I would therefore like some feedback
on how the
>group views the two mechanisms
>
>Global Server Policy that it is DPD only
>The first proposal is to make the option controlled by the
server as a
>global policy. Therefore the server would publish via policy
that is only
>supports DPD as such never signs a response. DPV client and DPD
clients
>wanting a signed response then know to use another server.
>
>SCVP Request option to not sign response
>The second option is to leave it to the client to signal to the
server it
>does not need a signature on the response by a new flag in the
request (or
>its twin the flag indicates it does want a signature on the
response).
>This allows clients to be benevolent towards the server by
asking it to
>skip the signature. Server can still at their discretion still
sign.
>
>Needless to say it is possible to hybridize the two but I am
hopeful we
>can try and keep this as simple as possible be picking on of
the two.
>Trevor







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DHQFtt063885; Tue, 13 Jul 2004 10:26:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DHQFlB063884; Tue, 13 Jul 2004 10:26:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DHQFAe063878 for <[e-mail]>; Tue, 13 Jul 2004 10:26:15 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6DHQHS01160; Tue, 13 Jul 2004 10:26:17 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 10:25:39 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

I believe Dave, Denis and I thought we were talking two
alternative mechanisms to address the unsigned DPD consensus:  a
mechanism based on explicit policy OR a mechanism based on a new
request flag, as you had earlier posted.

Your discussion below, i.e. "it seems prudent to have a flag in
the server policy" is confusing in that context.

Please clarify what you are asking the WG to consider.

Mike




-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: Tuesday, July 13, 2004 10:06 AM
To: Michael Myers; [e-mail]
Subject: RE: Unsigned DPD responses for SCVP15



Mike,
We seem to have merges multiple threads here. The question on
how SCVP
supports unsigned DPD reprocess was the topic of this thread.

Tim proposed a new optional flag in the request. Given some of
the other
discussions where in some instances SCVP server would be
unwilling to do
anything other than return unsigned responses, it seems prudent
to have
a flag in the server policy so DPV clients and DPD clients
wanting
signed responses don't waste their time. Given that SCVP
requests can be
unauthenticated, what is the benefit of having a SCVP server
which
returns both signed and unsigned responses depending on the
unauthenticated request? That scenario today would have the
server
signing all response and the client can choose to ignore the
signature
if required. Concerns around server security or sever
scalability, or
freshness of SCVP responses are address by having a server only
do
unsigned DPD responses. I am simply trying to understand what
problem we
seek to address by the mixed mode SCVP server.

Trevor

* -----Original Message-----
* From: Michael Myers [mailto:[e-mail]]
* Sent: Monday, July 12, 2004 6:58 PM
* To: Trevor Freeman; [e-mail]
* Subject: RE: Unsigned DPD responses for SCVP15
*
* Given the two alternatives of:
*
* 1. An approach requiring explicit policies; or
*
* 2. Client-side assertion of a new flag as Tim proposed;
*
* I prefer #2 for the following reasons.
*
* The SCVP I-D asserts no requirement that a server MUST have a
* unique policy.  The I-D supports this by making optional all
* such elements beyond the default defined by RFC3280.  An
* explicit OID-based approach forces the issue for servers that
* wish to support unsigned DPD.
*
* A non-trivial subset of environments don't even know what an
OID
* is (think credit unions), let alone the technical details of
* what must go into a policy as it relates to this context.  The
* contents of such are not well defined.  Absent that, there
* exists no basis to implement correponding enforcement logic
that
* is ensured to be interoperable across the Internet.
*
* The I-D provides no means for technical implementation and
* enforcement of a policy-based approach; it is
non-implementable.
* Further, the I-D provides no means to discriminate between DPD
* and DPV.  Even assuming in the future a consensus on a
* technically enforceable security assertion grammar, the
subject
* I-D defines no technical means to even say "DPD".
*
* Mike
*
*






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DH5tAn061634; Tue, 13 Jul 2004 10:05:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DH5t0F061633; Tue, 13 Jul 2004 10:05:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DH5s6a061627 for <[e-mail]>; Tue, 13 Jul 2004 10:05:54 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 13 Jul 2004 10:05:54 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 Jul 2004 10:05:58 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Jul 2004 10:06:08 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Jul 2004 10:05:52 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 10:05:58 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Unsigned DPD responses for SCVP15
Thread-Index: AcRofOIU9rHwdocSSeKR44mD8Hy0swAfKMJw
From: "Trevor Freeman" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 13 Jul 2004 17:05:52.0366 (UTC) FILETIME=[A72730E0:01C468FB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6DH5s6a061628
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,
We seem to have merges multiple threads here. The question on how SCVP
supports unsigned DPD reprocess was the topic of this thread.

Tim proposed a new optional flag in the request. Given some of the other
discussions where in some instances SCVP server would be unwilling to do
anything other than return unsigned responses, it seems prudent to have
a flag in the server policy so DPV clients and DPD clients wanting
signed responses don't waste their time. Given that SCVP requests can be
unauthenticated, what is the benefit of having a SCVP server which
returns both signed and unsigned responses depending on the
unauthenticated request? That scenario today would have the server
signing all response and the client can choose to ignore the signature
if required. Concerns around server security or sever scalability, or
freshness of SCVP responses are address by having a server only do
unsigned DPD responses. I am simply trying to understand what problem we
seek to address by the mixed mode SCVP server.

Trevor

* -----Original Message-----
* From: Michael Myers [mailto:[e-mail]]
* Sent: Monday, July 12, 2004 6:58 PM
* To: Trevor Freeman; [e-mail]
* Subject: RE: Unsigned DPD responses for SCVP15
* 
* Given the two alternatives of:
* 
* 1. An approach requiring explicit policies; or
* 
* 2. Client-side assertion of a new flag as Tim proposed;
* 
* I prefer #2 for the following reasons.
* 
* The SCVP I-D asserts no requirement that a server MUST have a
* unique policy.  The I-D supports this by making optional all
* such elements beyond the default defined by RFC3280.  An
* explicit OID-based approach forces the issue for servers that
* wish to support unsigned DPD.
* 
* A non-trivial subset of environments don't even know what an OID
* is (think credit unions), let alone the technical details of
* what must go into a policy as it relates to this context.  The
* contents of such are not well defined.  Absent that, there
* exists no basis to implement correponding enforcement logic that
* is ensured to be interoperable across the Internet.
* 
* The I-D provides no means for technical implementation and
* enforcement of a policy-based approach; it is non-implementable.
* Further, the I-D provides no means to discriminate between DPD
* and DPV.  Even assuming in the future a consensus on a
* technically enforceable security assertion grammar, the subject
* I-D defines no technical means to even say "DPD".
* 
* Mike
* 
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DGd3kp059556; Tue, 13 Jul 2004 09:39:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DGd3lN059555; Tue, 13 Jul 2004 09:39:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6DGd2ar059541 for <[e-mail]>; Tue, 13 Jul 2004 09:39:02 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 30383 invoked by uid 0); 13 Jul 2004 16:34:01 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.184.240) by woodstock.binhost.com with SMTP; 13 Jul 2004 16:34:01 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Tue, 13 Jul 2004 12:38:56 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Unsigned DPD responses for SCVP15
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My personal preference Option #2; however, I think that absence of this 
flag should indicate that the response should be signed.  One needs to make 
a guess about deployment to select the best semantic for this situation, 
and my guess is that server authentication will be important.

Russ


Trevor Freeman wrote:
>I have been asked to add unsigned responses for DPD clients to SCVP15. 
>There are two models proposed on how we accomplish that both of which meet 
>the requirements for 3379. I would therefore like some feedback on how the 
>group views the two mechanisms
>
>Global Server Policy that it is DPD only
>The first proposal is to make the option controlled by the server as a 
>global policy. Therefore the server would publish via policy that is only 
>supports DPD as such never signs a response. DPV client and DPD clients 
>wanting a signed response then know to use another server.
>
>SCVP Request option to not sign response
>The second option is to leave it to the client to signal to the server it 
>does not need a signature on the response by a new flag in the request (or 
>its twin the flag indicates it does want a signature on the response). 
>This allows clients to be benevolent towards the server by asking it to 
>skip the signature. Server can still at their discretion still sign.
>
>Needless to say it is possible to hybridize the two but I am hopeful we 
>can try and keep this as simple as possible be picking on of the two.
>Trevor





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DG7PaK057415; Tue, 13 Jul 2004 09:07:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DG7OUU057414; Tue, 13 Jul 2004 09:07:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DG7ObS057402 for <[e-mail]>; Tue, 13 Jul 2004 09:07:24 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6DG7OS85368 for <[e-mail]>; Tue, 13 Jul 2004 09:07:25 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 09:06:46 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I hate to keep ringing this bell, but there is no technical
means to say "DPD" in SCVP.  So should the flag-based option
come to pass, it will need to be defined in terms of response
content.  That is, language along the lines of "MAY sign
responses containing ONLY {path, rev-info} but MUST sign
validity assertions."  The flag would sharpen the MAY.

Mike




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D6qoTf027318; Mon, 12 Jul 2004 23:52:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D6qoBA027317; Mon, 12 Jul 2004 23:52:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D6qm0M027261 for <[e-mail]>; Mon, 12 Jul 2004 23:52:49 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA47698; Tue, 13 Jul 2004 09:02:59 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id IAA29788; Tue, 13 Jul 2004 08:52:24 +0200
Message-ID: <[e-mail]>
Date: Tue, 13 Jul 2004 08:52:43 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: Unsigned DPD responses for SCVP15
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

Like Mike and David, I also support Option #2.

Denis

> My preference is the same as Mike's (Option #2, server may choose not to 
> sign {path, rev-info} unless client indicates signing is required with a 
> request flag).
> 
> This gives the greatest flexibility to deployers, who can deploy servers 
> that either:
> 
>   (a) always sign everything
> 
>   (b) never sign anything and return errors if requested to
> 
>   (c) sign if client asks for a signature, don't sign if client
>       doesn't ask and response type permits.
> 
> Trevor's Option #1 (Fixed server policy) only permits deployments of (a) 
> and (b).  I believe that (c) is a potentially useful configuration, and 
> I don't think there's a strong reason to absolutely preclude it.
> 
> Thanks
> 
> 
> Trevor Freeman wrote:
> 
>> I have been asked to add unsigned responses for DPD clients to SCVP15. 
>> There are two models proposed on how we accomplish that both of which 
>> meet the requirements for 3379. I would therefore like some feedback 
>> on how the group views the two mechanisms
>>
>>  
>>
>> Global Server Policy that it is DPD only
>>
>> The first proposal is to make the option controlled by the server as a 
>> global policy. Therefore the server would publish via policy that is 
>> only supports DPD as such never signs a response. DPV client and DPD 
>> clients wanting a signed response then know to use another server.
>>
>>  
>>
>> SCVP Request option to not sign response
>>
>> The second option is to leave it to the client to signal to the server 
>> it does not need a signature on the response by a new flag in the 
>> request (or its twin the flag indicates it does want a signature on 
>> the response). This allows clients to be benevolent towards the server 
>> by asking it to skip the signature. Server can still at their 
>> discretion still sign.
>>
>>  
>>
>> Needless to say it is possible to hybridize the two but I am hopeful 
>> we can try and keep this as simple as possible be picking on of the two.
>>
>> Trevor
>>
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D2mhgU091797; Mon, 12 Jul 2004 19:48:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D2mhL2091796; Mon, 12 Jul 2004 19:48:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D2mgNA091777 for <[e-mail]>; Mon, 12 Jul 2004 19:48:43 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (sccrmhc11) with ESMTP id <20040713024843011009odhee>; Tue, 13 Jul 2004 02:48:44 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1BkDM2-0007OC-00 for <[e-mail]>; Mon, 12 Jul 2004 22:49:14 -0400
Message-ID: <[e-mail]>
Date: Mon, 12 Jul 2004 22:49:13 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Unsigned DPD responses for SCVP15
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My preference is the same as Mike's (Option #2, server may choose not to 
sign {path, rev-info} unless client indicates signing is required with a 
request flag).

This gives the greatest flexibility to deployers, who can deploy servers 
that either:

   (a) always sign everything

   (b) never sign anything and return errors if requested to

   (c) sign if client asks for a signature, don't sign if client
       doesn't ask and response type permits.

Trevor's Option #1 (Fixed server policy) only permits deployments of (a) 
and (b).  I believe that (c) is a potentially useful configuration, and 
I don't think there's a strong reason to absolutely preclude it.

Thanks


Trevor Freeman wrote:
> I have been asked to add unsigned responses for DPD clients to SCVP15. 
> There are two models proposed on how we accomplish that both of which 
> meet the requirements for 3379. I would therefore like some feedback on 
> how the group views the two mechanisms
> 
>  
> 
> Global Server Policy that it is DPD only
> 
> The first proposal is to make the option controlled by the server as a 
> global policy. Therefore the server would publish via policy that is 
> only supports DPD as such never signs a response. DPV client and DPD 
> clients wanting a signed response then know to use another server.
> 
>  
> 
> SCVP Request option to not sign response
> 
> The second option is to leave it to the client to signal to the server 
> it does not need a signature on the response by a new flag in the 
> request (or its twin the flag indicates it does want a signature on the 
> response). This allows clients to be benevolent towards the server by 
> asking it to skip the signature. Server can still at their discretion 
> still sign.
> 
>  
> 
> Needless to say it is possible to hybridize the two but I am hopeful we 
> can try and keep this as simple as possible be picking on of the two.
> 
> Trevor
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D1wHa0087977; Mon, 12 Jul 2004 18:58:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D1wHFm087976; Mon, 12 Jul 2004 18:58:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D1wG2K087970 for <[e-mail]>; Mon, 12 Jul 2004 18:58:16 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6D1wLS06790; Mon, 12 Jul 2004 18:58:21 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Mon, 12 Jul 2004 18:57:43 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Given the two alternatives of:

1. An approach requiring explicit policies; or

2. Client-side assertion of a new flag as Tim proposed;

I prefer #2 for the following reasons.

The SCVP I-D asserts no requirement that a server MUST have a
unique policy.  The I-D supports this by making optional all
such elements beyond the default defined by RFC3280.  An
explicit OID-based approach forces the issue for servers that
wish to support unsigned DPD.

A non-trivial subset of environments don't even know what an OID
is (think credit unions), let alone the technical details of
what must go into a policy as it relates to this context.  The
contents of such are not well defined.  Absent that, there
exists no basis to implement correponding enforcement logic that
is ensured to be interoperable across the Internet.

The I-D provides no means for technical implementation and
enforcement of a policy-based approach; it is non-implementable.
Further, the I-D provides no means to discriminate between DPD
and DPV.  Even assuming in the future a consensus on a
technically enforceable security assertion grammar, the subject
I-D defines no technical means to even say "DPD".

Mike





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D1BMdb084286; Mon, 12 Jul 2004 18:11:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D1BMQm084285; Mon, 12 Jul 2004 18:11:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D1BLbL084279 for <[e-mail]>; Mon, 12 Jul 2004 18:11:21 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 12 Jul 2004 18:11:20 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 12 Jul 2004 18:11:27 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 12 Jul 2004 18:11:25 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Jul 2004 18:11:24 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Unsigned DPD responses for SCVP15
Date: Mon, 12 Jul 2004 18:11:13 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Unsigned DPD responses for SCVP15
Thread-Index: AcRodCli/NnxQv4NRbWnACwcClcimQAAWKAQ
From: "Trevor Freeman" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 13 Jul 2004 01:11:24.0247 (UTC) FILETIME=[50B1B670:01C46876]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6D1BLbL084280
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I should have added that we need some rationale as well so I get some
context why. We need to consider this change in light of all SCVP users,
not just the DPD camp.
Trevor

* -----Original Message-----
* From: Michael Myers [mailto:[e-mail]]
* Sent: Monday, July 12, 2004 5:55 PM
* To: Trevor Freeman; [e-mail]
* Subject: RE: Unsigned DPD responses for SCVP15
* 
* Trevor,
* 
* I prefer the client-side flag option, with absence of the flag
* defaulting to no signatures on SCVP responses containing ONLY
* {path, rev-info}.
* 
* Mike
* 
* 
* -----Original Message-----
* From: [e-mail]
* [mailto:[e-mail]]On Behalf Of Trevor Freeman
* Sent: Monday, July 12, 2004 5:10 PM
* To: [e-mail]
* Subject: Unsigned DPD responses for SCVP15
* 
* 
* I have been asked to add unsigned responses for DPD clients to
* SCVP15. There are two models proposed on how we accomplish that
* both of which meet the requirements for 3379. I would therefore
* like some feedback on how the group views the two mechanisms
* 
* Global Server Policy that it is DPD only
* The first proposal is to make the option controlled by the
* server as a global policy. Therefore the server would publish
* via policy that is only supports DPD as such never signs a
* response. DPV client and DPD clients wanting a signed response
* then know to use another server.
* 
* SCVP Request option to not sign response
* The second option is to leave it to the client to signal to the
* server it does not need a signature on the response by a new
* flag in the request (or its twin the flag indicates it does want
* a signature on the response). This allows clients to be
* benevolent towards the server by asking it to skip the
* signature. Server can still at their discretion still sign.
* 
* Needless to say it is possible to hybridize the two but I am
* hopeful we can try and keep this as simple as possible be
* picking on of the two.
* Trevor
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D0u0QC082650; Mon, 12 Jul 2004 17:56:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D0u0k7082649; Mon, 12 Jul 2004 17:56:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D0u0i7082643 for <[e-mail]>; Mon, 12 Jul 2004 17:56:00 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6D0u4S95741; Mon, 12 Jul 2004 17:56:04 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, <[e-mail]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Mon, 12 Jul 2004 17:55:18 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

I prefer the client-side flag option, with absence of the flag
defaulting to no signatures on SCVP responses containing ONLY
{path, rev-info}.

Mike


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Trevor Freeman
Sent: Monday, July 12, 2004 5:10 PM
To: [e-mail]
Subject: Unsigned DPD responses for SCVP15


I have been asked to add unsigned responses for DPD clients to
SCVP15. There are two models proposed on how we accomplish that
both of which meet the requirements for 3379. I would therefore
like some feedback on how the group views the two mechanisms

Global Server Policy that it is DPD only
The first proposal is to make the option controlled by the
server as a global policy. Therefore the server would publish
via policy that is only supports DPD as such never signs a
response. DPV client and DPD clients wanting a signed response
then know to use another server.

SCVP Request option to not sign response
The second option is to leave it to the client to signal to the
server it does not need a signature on the response by a new
flag in the request (or its twin the flag indicates it does want
a signature on the response). This allows clients to be
benevolent towards the server by asking it to skip the
signature. Server can still at their discretion still sign.

Needless to say it is possible to hybridize the two but I am
hopeful we can try and keep this as simple as possible be
picking on of the two.
Trevor




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D09Y8Z079572; Mon, 12 Jul 2004 17:09:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D09Y6H079571; Mon, 12 Jul 2004 17:09:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D09XL7079564 for <[e-mail]>; Mon, 12 Jul 2004 17:09:33 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 12 Jul 2004 17:09:35 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 12 Jul 2004 17:09:39 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 12 Jul 2004 17:09:38 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Jul 2004 17:09:37 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-516d6b34-abf2-4b52-88ea-4aaf7d1b9505"
Subject: Unsigned DPD responses for SCVP15
Date: Mon, 12 Jul 2004 17:09:34 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Unsigned DPD responses for SCVP15
Thread-Index: AcRoba2ZYOoqnYLyTJOjoQpI21+/FQ==
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 13 Jul 2004 00:09:37.0125 (UTC) FILETIME=[AF13C950:01C4686D]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPartTM-000-516d6b34-abf2-4b52-88ea-4aaf7d1b9505
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4686D.AEFCAA7E"

------_=_NextPart_001_01C4686D.AEFCAA7E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have been asked to add unsigned responses for DPD clients to SCVP15.
There are two models proposed on how we accomplish that both of which
meet the requirements for 3379. I would therefore like some feedback on
how the group views the two mechanisms

=20

Global Server Policy that it is DPD only

The first proposal is to make the option controlled by the server as a
global policy. Therefore the server would publish via policy that is
only supports DPD as such never signs a response. DPV client and DPD
clients wanting a signed response then know to use another server.

=20

SCVP Request option to not sign response

The second option is to leave it to the client to signal to the server
it does not need a signature on the response by a new flag in the
request (or its twin the flag indicates it does want a signature on the
response). This allows clients to be benevolent towards the server by
asking it to skip the signature. Server can still at their discretion
still sign.

=20

Needless to say it is possible to hybridize the two but I am hopeful we
can try and keep this as simple as possible be picking on of the two.

Trevor


------_=_NextPart_001_01C4686D.AEFCAA7E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Device Font 10cpi";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Device Font 10cpi";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:0pt 31.3pt 0pt 31.25pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I have been asked to add unsigned responses for DPD clients to =
SCVP15.
There are two models proposed on how we accomplish that both of which =
meet the
requirements for 3379. I would therefore like some feedback on how the =
group
views the two mechanisms</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Global Server Policy that it is DPD only</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The first proposal is to make the option controlled by the =
server as a
global policy. Therefore the server would publish via policy that is =
only
supports DPD as such never signs a response. DPV client and DPD clients =
wanting
a signed response then know to use another server.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>SCVP Request option to not sign response</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The second option is to leave it to the client to signal to the =
server
it does not need a signature on the response by a new flag in the =
request (or
its twin the flag indicates it does want a signature on the response). =
This
allows clients to be benevolent towards the server by asking it to skip =
the
signature. Server can still at their discretion still =
sign.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Needless to say it is possible to hybridize the two but I am =
hopeful we
can try and keep this as simple as possible be picking on of the =
two.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
 10.0pt'>Trevor</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C4686D.AEFCAA7E--

------=_NextPartTM-000-516d6b34-abf2-4b52-88ea-4aaf7d1b9505--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CMNBTf070326; Mon, 12 Jul 2004 15:23:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6CMNBMt070325; Mon, 12 Jul 2004 15:23:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CMNAQo070315 for <[e-mail]>; Mon, 12 Jul 2004 15:23:11 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6CMN9S66204 for <[e-mail]>; Mon, 12 Jul 2004 15:23:09 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: OCSP in IKEv2
Date: Mon, 12 Jul 2004 15:22:32 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Please consider and comment on the following.
Discussions will be held on the IPSEC list.

Michael Myers


-----Original Message-----
From: [e-mail]
Sent: Monday, July 12, 2004 12:36 PM

A New Internet-Draft is available from the on-line
Internet-Drafts directories.


	Title		: OCSP Extensions to IKEv2
	Author(s)	: M. Myers, H. Tschofenig
	Filename	: draft-myers-ipsec-ikev2-oscp-00.txt
	Pages		: 8
	Date		: 2004-7-12

While IKEv2 supports public key based authentication (PKI), the
corresponding use of in-band CRLs is problematic due to
unbounded CRL
size.  The size of an OCSP response is however well-bounded and
small.
This document defines two extensions to IKEv2 which enable the
use of
OCSP for in-band signaling of certificate revocation status.
Two new
content encodings are defined for use in the CERTREQ and CERT
payloads:
OCSP Responder Hash and OCSP Response.  An OCSP Responder Hash
CERTREQ
payload triggers transmission of an OCSP Response CERT payload.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp
-00.txt




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CHTgsT043234; Mon, 12 Jul 2004 10:29:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6CHTgoS043233; Mon, 12 Jul 2004 10:29:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6CHTfVN043227 for <[e-mail]>; Mon, 12 Jul 2004 10:29:41 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 20870 invoked by uid 0); 12 Jul 2004 17:24:53 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.11.103) by woodstock.binhost.com with SMTP; 12 Jul 2004 17:24:53 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Mon, 12 Jul 2004 13:29:58 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: New I-D on Intl Strings in Certs
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Many thanks to Steve and Paul for generating this document.

I would like to see an additional section in this document.  When otherName 
forms are registered, some of these will in include text strings.  However, 
they will probably not make use of GeneralName or Name.  Therefore, I think 
it would be useful to list the ASN.1 types where these rules should be 
applied.  UTF8String is obvious.  What esle?

Russ

At 08:39 AM 7/12/2004, Steve Hanna wrote:

>Among the recent flurry of Internet Draft
>announcements was the one below. This is
>the long-promised document by Paul Hoffman
>and myself on how to handle Unicode and
>other international strings in certificates.
>
>Please review the document, considering
>especially the open issues highlighted
>therein. We will lead a discussion on
>these topics at IETF 60, but it would be
>great to get an email discussion going
>first.
>
>We have coordinated with the ISO, ldapbis,
>and idn folks on this effort. We want to
>make sure all our documents are compatible
>so that you can use the same techniques
>(and the same code) for comparing X.500
>names with all these standards. That's why
>this document is fairly small, pointing
>people to the ldapbis specs for details.
>
>So please review this document and send
>comments to the PKIX list.
>
>Thanks,
>
>Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CCbCpl019194; Mon, 12 Jul 2004 05:37:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6CCbCUj019193; Mon, 12 Jul 2004 05:37:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CCaf8j019157 for <[e-mail]>; Mon, 12 Jul 2004 05:37:12 -0700 (PDT) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6CCYa53025399 for <[e-mail]>; Mon, 12 Jul 2004 06:34:36 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Mon, 12 Jul 2004 08:36:43 -0400 (EDT)
Received: from sun.com (vpn-129-150-64-92.East.Sun.COM [129.150.64.92]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 12 Jul 2004 08:36:43 -0400 (EDT)
Date: Mon, 12 Jul 2004 08:39:25 -0400
From: Steve Hanna <[e-mail]>
Subject: New I-D on Intl Strings in Certs
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Among the recent flurry of Internet Draft
announcements was the one below. This is
the long-promised document by Paul Hoffman
and myself on how to handle Unicode and
other international strings in certificates.

Please review the document, considering
especially the open issues highlighted
therein. We will lead a discussion on
these topics at IETF 60, but it would be
great to get an email discussion going
first.

We have coordinated with the ISO, ldapbis,
and idn folks on this effort. We want to
make sure all our documents are compatible
so that you can use the same techniques
(and the same code) for comparing X.500
names with all these standards. That's why
this document is fairly small, pointing
people to the ldapbis specs for details.

So please review this document and send
comments to the PKIX list.

Thanks,

Steve

-------- Original Message --------
Subject: I-D ACTION:draft-hoffman-pkix-stringmatch-00.txt
Date: Fri, 09 Jul 2004 15:26:26 -0400
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Matching Text Strings in PKIX Certificates
	Author(s)	: P. Hoffman, S. Hanna
	Filename	: draft-hoffman-pkix-stringmatch-00.txt
	Pages		: 0
	Date		: 2004-7-9
	
Strings of text appear in many fields in PKIX certificates. Some
applications need to compare the values in these fields to strings
from other certificates, or to values obtained in other manners.
For many string encodings, this can be done in an octet-by-octet
fashion. Other encodings, however, require preparation before the
strings can be compared. This document describes that preparation
and when it needs to be applied.

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

To remove yourself from the I-D Announcement list, send a message to
[e-mail] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


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-hoffman-pkix-stringmatch-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-hoffman-pkix-stringmatch-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.
		



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69LQI3N009023; Fri, 9 Jul 2004 14:26:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69LQI4A009022; Fri, 9 Jul 2004 14:26:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69LPuqn008991 for <[e-mail]>; Fri, 9 Jul 2004 14:26:18 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc13) with ESMTP id <2004070921255601500i15h2e>; Fri, 9 Jul 2004 21:25:56 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1Bj2st-0003jd-00; Fri, 09 Jul 2004 17:26:19 -0400
Message-ID: <[e-mail]>
Date: Fri, 09 Jul 2004 17:26:18 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP responses containing only {path, rev-info}
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I support this proposal.

I do agree with Mike, and would also prefer to invert #2 (DPD may be 
unsigned unless client explicitly requests a signature), but I would 
ultimately be fine with either form.

Thanks


Michael Myers wrote:
> ...
> The proposed mechanism is as follows.  Assume there exists a new
> SCVP request flag governing the production of DPD signatures.
> Then:
> 
> (1) If the client indicates DPD signatures are not required,
>     the server MAY return an unsigned response, a signed
>     response, or an error.
> 
> (2) If the new request flag is not present, the server MUST
>     return a signed response or an error.
> 
> (3) Unless the client indicates signatures are not required,
>     the client MUST verify the signature on the response.
> 
> I would prefer to invert the sense of #2 since by RFC 3379's
> definition DPD is to a first degree just a proxy for the diverse
> protocols and schemas currently used to access PKI information.
> Where the previously hypothesized replay attacks become reality,
> turn on the flag.  But maybe that is just me.
> 
> I think it is time others were given the opportunity to voice
> their opinions.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69KeVt4005898; Fri, 9 Jul 2004 13:40:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69KeVFU005897; Fri, 9 Jul 2004 13:40:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69KeTkZ005891 for <[e-mail]>; Fri, 9 Jul 2004 13:40:30 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i69KeXS11187 for <[e-mail]>; Fri, 9 Jul 2004 13:40:34 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: SCVP responses containing only {path, rev-info}
Date: Fri, 9 Jul 2004 13:40:01 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Apologies in advance for the awkward subject line but the SCVP
I-D provides no explicit means to say "DPD".  Nonetheless, for
the purposes of this note, interpret "DPD" as a macro for "SCVP
responses containing ONLY {path, rev-info}".

You may recall some time ago discussions on whether or not DPD
should be signed.  It was concluded that because the data
objects contained in such a response are themselves signed, the
security assurances afforded by overlaying an additional
signature were of such a degree that the risks are a matter of
local policy--providing that the document defined a means to
enable activation of DPD signing.

Since the development of that rough consensus, several off-list
discussions have been conducted with a view towards the precise
definition of those means.  The most recently proposed mechanism
appears to enable a consensus that will close this issue.  With
additional apologies in advance to all participants in the
off-list discussions, I believe it is time to bring this issue
to the WG.

The proposed mechanism is as follows.  Assume there exists a new
SCVP request flag governing the production of DPD signatures.
Then:

(1) If the client indicates DPD signatures are not required,
    the server MAY return an unsigned response, a signed
    response, or an error.

(2) If the new request flag is not present, the server MUST
    return a signed response or an error.

(3) Unless the client indicates signatures are not required,
    the client MUST verify the signature on the response.

I would prefer to invert the sense of #2 since by RFC 3379's
definition DPD is to a first degree just a proxy for the diverse
protocols and schemas currently used to access PKI information.
Where the previously hypothesized replay attacks become reality,
turn on the flag.  But maybe that is just me.

I think it is time others were given the opportunity to voice
their opinions.

Thoughts, anyone?

Mike








Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69HLMnO091876; Fri, 9 Jul 2004 10:21:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69HLMoT091875; Fri, 9 Jul 2004 10:21:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69HLKvr091849 for <[e-mail]>; Fri, 9 Jul 2004 10:21:21 -0700 (PDT) (envelope-from [e-mail])
Content-class: urn:content-classes:message
Subject: SCVP Questions
MIME-Version: 1.0
Date: Fri, 9 Jul 2004 13:21:18 -0400
Content-Type: multipart/signed; boundary="----=_NextPart_000_0026_01C465B7.9E1C1E80"; protocol="application/x-pkcs7-signature"; micalg=SHA1
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP Questions
Thread-Index: AcRl2SUA01wYTmC+RFmj9bntVdtD+w==
From: "Seth Hitchings" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0026_01C465B7.9E1C1E80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I have a few questions about the way in which SCVP CVResponses to failed 
requests are constructed. I'm working with draft 14 of the spec.
 
First, assume that a request includes a bad check OID. Section 3.2.2 states that:
  "For each check, the SCVP server MUST perform all of the requested checks, or
   return an error."
In this case, I would expect the server to send back a ResponseStatus (section 4.4) 
of 27, unsupportedChecks. I find the term unsupported somewhat ambiguous, since
there is a difference between unsupported and unrecognized, but that's a
side issue. What I'm uncertain of is why the CertReply has a possible status 
of 1, unrecognizedCheck. If the check is unrecognized, the SCVP server is obliged
to return an error response per section 3.2.2, and therefore shouldn't be returning 
any CertReply.
 
I have the same issue with ReplyStatus 3, unrecognizedWantBack, since section 
3.2.3 states that:
  "For each type of information specified in the request, the server MUST return
   information regarding its finding (in a successful request)."
   
I have the same issue with ReplyStatus 7, unrecognizedExtension. First, I assume
this refers to queryExtensions? Section 3.2.18 states that
  "An SCVP server MUST rejeft the query if it encounters a critical extension
   it does not recognize..."
If the entire query is to be rejected, then why unrecognizedExtension a possible
ReplyStatus?
 
I have the same issue with ReplyStatus 8, unavailableValidityTime. Validity time
applies to all queriedCerts, so why indicate the error on a per ReplyStatus basis?
 
In general, it seems that errors that prevent the query from being processed
should be reported at the ResponseStatus level. In this case, no CertReply
objects would be expected in the response. Only those errors that are specific
to an individual query cert should be reported at the CertReply level.
 

Second, I find the use of ReplyWantBacks and ReplyChecks difficult in failure 
cases. Assume that a request asks for a certification path to be built for a single 
certificate. If no path can be built, the ReplyStatus is 10, certPathConstructFail,
and the ReplyChecks for the certification path building check is 1, "Could
not build a path". If a client sees the ReplyStatus, why would it bother checking
the CertReply? Additionally, the ReplyWantBack is required, but what value can I 
include? I couldn't build a CertPath.
 
The only case that I can see in which including ReplyChecks and ReplyWantBacks
in a CertReply with a non-success status makes sense is when the cert path
is not valid. In that case, the client may still want the cert path back, invalid
or not, especially when using untrusted SCVP.
 

Third, I'm unclear on exactly how keyUsage, extendedKeyUsage and isCA are used.
Must the SCVP server fail a check if the queried cert does not meet the criteria
of any of these parameters? If so, what is the expected ReplyStatus? Is it
validation failure, certPathNotValid? If so, are these parameters taken into
account only when building valid paths, and not when simply building an unvalidated
path?
 

Thanks,
Seth Hitchings

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOgzCCBF8w
ggNHoAMCAQICECAT0p7OwWWiTUxNNKPTlu0wDQYJKoZIhvcNAQEFBQAwTjETMBEGCgmSJomT8ixk
ARkWA2NvbTEaMBgGCgmSJomT8ixkARkWCkNvcmVTdHJlZXQxGzAZBgNVBAMTEkNvcmVTdHJlZXQg
Um9vdCBDQTAeFw0wMzEwMTcxODI2MjRaFw0yMzEwMTcxODM0MzBaME4xEzARBgoJkiaJk/IsZAEZ
FgNjb20xGjAYBgoJkiaJk/IsZAEZFgpDb3JlU3RyZWV0MRswGQYDVQQDExJDb3JlU3RyZWV0IFJv
b3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8uGS+2D6uxSRa9Ldkd4D3HuEo
g8CJIc39jK2AHkULWaPmbYFTyAAyVnOiKtAZFGUyN1uj+XW46JJI1xZDOqlwnww/MQRzd5xq7sJH
y3bx5HjmGrhitZox3mqW8SFAMR7491wuGEmViw5xhv+eQKwa+EBUrOmN4ng0lHNMh9brEEqT9gNb
4EUHCANIHlSZ/gd8GwVStgFVo48ZpS/GSeXpu7lYiaxMIr5EpCbjBalSC6NGjCXy0OxX2sJvrWNn
CXBVluGv9jZLnuuALHEN0gDUI/iih3bcG5mRz//9ntuCLwD81eWDhWCUarjdF+khOMnzukvoTEi8
N7uD6v9PbYZPAgMBAAGjggE3MIIBMzATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAYYw
DwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUp7YMqlf701pkw6/uBoO+KGLHoKswEAYJKwYBBAGC
NxUBBAMCAQAwgcwGA1UdIASBxDCBwTCBvgYHKwYBBAHqRDCBsjBCBggrBgEFBQcCARY2aHR0cDov
L3d3dy5jb3Jlc3RyZWV0LmNvbS9wa2kvcG9saWN5L0NvcmVTdHJlZXRDUFMucGRmMGwGCCsGAQUF
BwICMGAeXgBDAG8AcgBlAFMAdAByAGUAZQB0ACAATAB0AGQALgAgAEMAZQByAHQAaQBmAGkAYwBh
AHQAZQAgAFAAcgBhAGMAdABpAGMAZQBzACAAUwB0AGEAdABlAG0AZQBuAHQwDQYJKoZIhvcNAQEF
BQADggEBAHQ+FzirKSSMFjSLK5W3f0LR/QKVNgNRdiaCOQ+rU+St4qwcJY+x72HGXpBP+6UV4qUN
g9gPPaEP+Reyyj8Qcjkt1QE1QAmvR02nM3NUDpWQEBFpd30r7DhapeLV+T+9llzAAWKami87Ik/f
CL2jGeZfz7lTl2rXN+w2jYdM27PRQ6DAV3ns4osR9HTCX3Vge4b6MBVkLqKQyjMT8uhUIvIisKcU
axzzMWFZXm3q4M55JEdrYC3rCytBAbIYnqyk0LLLi1jRAyVvqmvLaHJ+ydhyR5NyNN5aWSLlX1Uz
iBn4SXlee1uCKzBDK5I30fXYyNI5nZ5aUg4FC+/w21tlpD0wggTKMIIDsqADAgECAhMzAAAAEpOB
cMC8OvwnAAAAAAASMA0GCSqGSIb3DQEBBQUAME4xEzARBgoJkiaJk/IsZAEZFgNjb20xGjAYBgoJ
kiaJk/IsZAEZFgpDb3JlU3RyZWV0MRswGQYDVQQDExJDb3JlU3RyZWV0IFJvb3QgQ0EwHhcNMDMx
MTExMTU1NzE1WhcNMDUxMTExMTYwNzE1WjBWMRMwEQYKCZImiZPyLGQBGRYDY29tMRowGAYKCZIm
iZPyLGQBGRYKQ29yZVN0cmVldDEjMCEGA1UEAxMaQ29yZVN0cmVldCBJbnRlcm1lZGlhdGUgQ0Ew
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDmCHBA7GiJsMJDk5qxBtKhBPYUqpcZR5uQ
fqWtbJ5oC47TCbBc0+mwcUqq24OqVAoP7lpGWa7M/CfTo87xNPzcF6xJlFQqc/BZt3bX4dwnk0n+
Jrakmaqy29eq74aenPzHCTIB9xfOkfI077u2H90F2R7QKecnWa1igUORpIdRXOAWt7cTyvZGSN9H
el5YcCt3y2nFJPnyS8AT1AGSNxB+EG5d9CrYhsDlxrV/joHzGcBMv/F3D0nBOimKACnLVeIq5zza
tlWf1w2nndjKuMuZnC27xj+5t1uTyXZDUIxnPuzt45dSMbT/F60F7P1SfpXLlDNlOyznKqP6AiIc
WWDxAgMBAAGjggGXMIIBkzAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBR2rJTl6xcvTnQ+9No5
RiBDdVvU6jALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAwgcwGA1UdIASBxDCBwTCBvgYH
KwYBBAHqRDCBsjBCBggrBgEFBQcCARY2aHR0cDovL3d3dy5jb3Jlc3RyZWV0LmNvbS9wa2kvcG9s
aWN5L0NvcmVTdHJlZXRDUFMucGRmMGwGCCsGAQUFBwICMGAeXgBDAG8AcgBlAFMAdAByAGUAZQB0
ACAATAB0AGQALgAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAFAAcgBhAGMAdABpAGMAZQBzACAA
UwB0AGEAdABlAG0AZQBuAHQwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU
p7YMqlf701pkw6/uBoO+KGLHoKswNwYIKwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8v
b2NzcC5jb3Jlc3RyZWV0LmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAFwsKvYKAR3/A5BsEUnpaV1D
LDs3tSCtNPnv8Kvwu80HA96/W6RE0fGzEiMdFm8BtmKhshHY3u86INR0VFSdrYlK1TcXumgEJbxv
F49OcsGzJsC9FJFgHgXHr31IwiyYzu3LaDmlCIY3L6LpPqOhZ+gxHDadD/kzZC9pD/cmIX3ANSfI
2nA/1O60dehwkxL0VZDdCWWwzPHmFXWvDTfcdzunwtWZYf/ZGR5uswmg6AOHB12MuT1lvKzck8m9
7xxFVZzn6cRB1dTy+28p/g4lknnb3eqSz4obfm6LCJQpKMjccYNHLog7LC1qop0ZorGrEc1Il3TM
ttInUnZkv+0u3EQwggVOMIIENqADAgECAgc9AAAAAABjMA0GCSqGSIb3DQEBBQUAMFYxEzARBgoJ
kiaJk/IsZAEZFgNjb20xGjAYBgoJkiaJk/IsZAEZFgpDb3JlU3RyZWV0MSMwIQYDVQQDExpDb3Jl
U3RyZWV0IEludGVybWVkaWF0ZSBDQTAeFw0wNDA1MDMxNTE0NTlaFw0wNTA1MDMxNTE0NTlaMGEx
EzARBgoJkiaJk/IsZAEZFgNjb20xGjAYBgoJkiaJk/IsZAEZFgpjb3Jlc3RyZWV0MRQwEgYDVQQL
EwtDUy1FbXBsb3llZTEYMBYGA1UEAxMPSGl0Y2hpbmdzLCBTZXRoMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAyPEMYYuVnz3q084slSSchJCyhDS77kVDcii9QbUawHOe14cFJunwQfGE
cH+l2GusRbkuXCuVu8T9erFM6zQm4+GlmSNg69+Demo+0kRelrIFxmyykd9ZnCYwWiaXKPB9iVU/
zWJmrhVdsAXYj7/fTmCRckk6Qo4KXpI2pvayXlBuAsnU6gi58b4a6xsr9E+IJeLnnWL/QMLcxZj0
hdCIMkJv+yz7HqvJ+/dFkPazCJnNxFWvCimlvy6IhiTz/rQbZtSgFqLQ7jjxD+z35AOQ/bU15URR
iEt2+4Woq1lJQ7CUtxPVC4/cjK63YGuZYuKCDdxTdxS2D1VS7iKWJLm16QIDAQABo4ICFDCCAhAw
HQYDVR0OBBYEFHgGdd7M6vjLnBwUrXcddqaPz/77MB8GA1UdIwQYMBaAFHaslOXrFy9OdD702jlG
IEN1W9TqMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jYS5jb3Jlc3RyZWV0LmNvbTo4MS9DZXJ0
RW5yb2xsL0NvcmVTdHJlZXQlMjBJbnRlcm1lZGlhdGUlMjBDQS5jcmwwNwYIKwYBBQUHAQEEKzAp
MCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5jb3Jlc3RyZWV0LmNvbS8wDAYDVR0TAQH/BAIwADAL
BgNVHQ8EBAMCBLAwPgYJKwYBBAGCNxUHBDEwLwYnKwYBBAGCNxUIgtvBQoOglSiF/ZcDg+LAB4Gh
5nGBdIPUyHuFsf0NAgFkAgEfMDEGA1UdJQQqMCgGCCsGAQUFBwMFBggrBgEFBQcDBwYIKwYBBQUH
AwIGCCsGAQUFBwMEMD8GCSsGAQQBgjcVCgQyMDAwCgYIKwYBBQUHAwUwCgYIKwYBBQUHAwcwCgYI
KwYBBQUHAwIwCgYIKwYBBQUHAwQwJAYDVR0RBB0wG4EZc2hpdGNoaW5nc0Bjb3Jlc3RyZWV0LmNv
bTBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4D
AgcwCgYIKoZIhvcNAwcwDQYJKoZIhvcNAQEFBQADggEBADKe1tyGSGY/hkESTZKdY44FvIkIlpMn
JOtJDXjMutvpSulesWn+3ExTRyXBnJBU+nNsPru5zvHxEpUYMhO6vCYXCMqJb1X5iL/uY7MfvFPF
vIgH2/k9IUmWGxgF+yOfYZ/kI0GMOZ94HM5faZeJpUcwfoa/jtbnTL9bfmXdhIg4mzJhkouAQD5q
M5upWW/ZqcUo1O02pa5LawvcDmwALZYPC31CtR740OzDJ9LQeUV2MJJhiUGQJU7wtygcNAw89lBC
SBethwv+pOwtMAX3FjxbRE1QKQRTNUuZ+Gz+YTD9vprsoZpw/Rv4dME1x9unMWS6jxM4KZKgFy29
f1iWTD0xggM4MIIDNAIBATBhMFYxEzARBgoJkiaJk/IsZAEZFgNjb20xGjAYBgoJkiaJk/IsZAEZ
FgpDb3JlU3RyZWV0MSMwIQYDVQQDExpDb3JlU3RyZWV0IEludGVybWVkaWF0ZSBDQQIHPQAAAAAA
YzAJBgUrDgMCGgUAoIIBrDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wNDA3MDkxNzIxMTdaMCMGCSqGSIb3DQEJBDEWBBSFVkGNj6IOyv//5MEqW8LKTWinyDBnBgkq
hkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH
BgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBwBgkrBgEEAYI3EAQx
YzBhMFYxEzARBgoJkiaJk/IsZAEZFgNjb20xGjAYBgoJkiaJk/IsZAEZFgpDb3JlU3RyZWV0MSMw
IQYDVQQDExpDb3JlU3RyZWV0IEludGVybWVkaWF0ZSBDQQIHPQAAAAAAYzByBgsqhkiG9w0BCRAC
CzFjoGEwVjETMBEGCgmSJomT8ixkARkWA2NvbTEaMBgGCgmSJomT8ixkARkWCkNvcmVTdHJlZXQx
IzAhBgNVBAMTGkNvcmVTdHJlZXQgSW50ZXJtZWRpYXRlIENBAgc9AAAAAABjMA0GCSqGSIb3DQEB
AQUABIIBAFNEGjeIuAyCjCOQGsNvuJJiNnbPun9MQXL/EP2WSVhy31QEG0mXirXQN051Rp8WTc30
rXgVXef172Ya8Eox2ruQqnNpSnLMS7OXBhCAjMScq10pA5dRW5QtPZda69NUNKe6IPTWmfRJIAxc
UFbyszo/ke3mJgh3nKvlVrBu6B/q3m4/BDACXU8NYjNsnirIcPff7J/59jcIgv3JMdC4h22kMplM
WCXPM8hOLKs/qRJQdewqA+FxTaoL9klHLP/4R3YTBhpMWwz4nKBiJbXdJVPajqP2IQKlwGv6Rwt3
FRBhfMCT0St51pvz2tciTL4KTfNTXwt7qTjbPjO1uQwhS0oAAAAAAAA=

------=_NextPart_000_0026_01C465B7.9E1C1E80--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69DYOnx068291; Fri, 9 Jul 2004 06:34:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69DYOmg068290; Fri, 9 Jul 2004 06:34:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from dswu17.btconnect.com (c2bapps9.btconnect.com [193.113.154.18]) by above.proper.com (8.12.11/8.12.9) with SMTP id i69DYMQj068264 for <[e-mail]>; Fri, 9 Jul 2004 06:34:23 -0700 (PDT) (envelope-from [e-mail])
Received: from varws7 (actually host 24.131.136.81.in-addr.arpa) by dswu17 with SMTP-CUST (XT-PP) with ESMTP; Fri, 9 Jul 2004 14:30:43 +0100
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>
Subject: OASIS Digital Signature Services TC announcement
Date: Fri, 9 Jul 2004 14:33:13 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The OASIS Digital Signature Services TC is developing techniques to support
the processing of digital signatures, including defining an interface for
requesting that a web service produce and/or verify a digital signature.

The TC has recently agreed two Committee Draft specifications:
- Digital Signature Service (DSS) Core Protocols, Elements and Bindings,
available at
  http://docs.oasis-open.org/dss/cd/oasis-dss-1[1].0-core-spec-cd.pdf

- XML Timestamping DSS Profile, available at:

http://docs.oasis-open.org/dss/cd/oasis-dss-1[1].0-profiles-timestamping-spe
c-cd.pdf

The DSS schema is available at:
  http://docs.oasis-open.org/dss/cd/oasis-dss-1[1].0-core-schema-cd.xsd.xml

Additional DSS profiles nearing completion for:
 - Asynchronous operation
 - Code signing
 - Entity seal
 - Electronic Post Mark (EPM)
 - German signature law
 - Policy wise operation
 - Web services security
 - XML Advanced Electronic Signature (XAdES)

Comments may be sent via the OASIS DSS web page:
 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss

Once the first set of profiles have been agreed as Committee Drafts, the TC
will be asking for a more formal public review of the full set of
specifications.

Nick Pope & Juan Carlos Cruellas
  Co-Chairs OASIS Digital Signature Services TC






Received: from A-DYZSU9H2YKIS0 ([218.55.41.39]) by above.proper.com (8.12.11/8.12.9) with SMTP id i67BeL1C009959; Wed, 7 Jul 2004 04:40:29 -0700 (PDT) (envelope-from [e-mail])
Received: from  [129.120.78.156] by A-DYZSU9H2YKIS0 id <5722317-52896>; Wed, 07 Jul 2004 14:34:50 +0200
Message-ID: <s$v$5td$[e-mail]>
From: "Admin" <[e-mail]>
To: [e-mail]
Subject: ADV:         Attention All Nonprofit Organizations: Members, Staff and Associates:
Date: Wed, 07 Jul 04 14:34:50 GMT
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: QUALCOMM Windows Eudora Version 5.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="9D05C96_B9.."

This is a multi-part message in MIME format.

--9D05C96_B9..
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Nonprofit Organizations: Members, Staff and Associates:

You Must Respond By 5 P.M. Thursday, July 8, 2004.

Through a special arrangement, Avtech Direct is offering a limited
allotment of BRAND NEW, top of-the-line, name-brand desktop computers
at more than 50% off MSRP to all Nonprofit Members and Staff 
who respond to this message before 5 P.M., Thursday, July 8, 2004.

All desktop are brand-new, packed in their original boxes, and come
with a full manufacturer's warranty plus a 100% satisfaction guarantee.

These professional grade Desktops are fully equipped with 2004
next generation technology, making these the best performing
computers money can buy.

Avtech Direct is offering these feature rich, top performing
Desktop Computers with the latest Intel technology at an amazing price
to all who call:

    1-800-884-9510 by 5 P.M. Thursday, July 8, 2004

The fast and powerful AT-2400 series Desktop features: 

      * Intel 2.0Ghz Processor for amazing speed and performance
      * 128MB DDR RAM,  --- Upgradeable to 1024
      * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB
      * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW 
      * 1.44 Floppy disk drive
      * Next Generation Technology
      * ATI Premium video and sound
      * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0
      * Soft Touch Keyboard and scroll mouse
      * Internet Ready
      * Network Ready
      * 1 Year parts and labor warranty
      * Priority customer service and tech support

MSRP $699 ........................................ Your Cost $297

How to qualify:

  1. You must be a Member, Staff or Associate of a Nonprofit:
  2. All desktop computers will be available on a
     first come first serve basis.
  3. You must call 1-800-884-9510 by 5 P.M. Thursday, July 8, 2004
     and we will hold the desktops you request on will call. 
  4. You are not obligated in any way.
  5. 100% Satisfaction Guaranteed.
   
   
Call Avtech Direct
1-800-884-9510 before 5 P.M. Thursday, July 8, 2004

Visit our website at http://www.avtechdirect-nonprofits.com




AVtech Direct
22647 Ventura Blvd., Suite 374
Woodland Hills, CA 91364.


If you wish to unsubscribe from this list, please go to:
http://www.computeradvice.org/unsubscribe.asp
--9D05C96_B9..--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i631bUgf019932; Fri, 2 Jul 2004 18:37:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i631bU03019931; Fri, 2 Jul 2004 18:37:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i631bS4P019914 for <[e-mail]>; Fri, 2 Jul 2004 18:37:28 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i631bQ1m004699; Fri, 2 Jul 2004 18:37:26 -0700
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <NQPCYHV0>; Fri, 2 Jul 2004 18:37:26 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Cross-certification
Date: Fri, 2 Jul 2004 18:37:25 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> "Alberti Antoine" <[e-mail]> writes:
> 
> >Would there be any document where cross-certification and 
> non-hierarchical
> >infrastructures are defined, please ?
> 
> I believe H.P.Lovecraft has published some works on this.
> 
> Peter.

Stamp on the toes of the CA and you will get some very cross
indeed certification. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Ete8s061371; Fri, 2 Jul 2004 07:55:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62Ete29061370; Fri, 2 Jul 2004 07:55:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from puzzle.pobox.com (puzzle.pobox.com [207.8.214.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62EtdqB061361 for <[e-mail]>; Fri, 2 Jul 2004 07:55:40 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost [127.0.0.1]) by puzzle.pobox.com (Postfix) with ESMTP id 7F6E51393E8; Fri,  2 Jul 2004 10:55:14 -0400 (EDT)
Received: from distopia (c-24-17-200-151.client.comcast.net [24.17.200.151]) by puzzle.pobox.com (Postfix) with ESMTP id 26AD113940C; Fri,  2 Jul 2004 10:55:13 -0400 (EDT)
From: "Laudon Williams" <[e-mail]>
To: "'Wahaj'" <[e-mail]>, <[e-mail]>
Subject: RE: Difference between a p12 and pfx file
Date: Fri, 2 Jul 2004 07:55:26 -0700
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0022_01C46009.F051EE90"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRgKVwzlzqtx4mSTXSrkz1TVn3EVwAGzSnA
In-Reply-To: <004f01c4601e$28659d90$[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01C46009.F051EE90
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0023_01C46009.F051EE90"


------=_NextPart_001_0023_01C46009.F051EE90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

No. They are the same.

 

-Laudon

 

  _____  

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Wahaj
Sent: Friday, July 02, 2004 3:20 AM
To: [e-mail]
Subject: Difference between a p12 and pfx file

 

Hi,

 

Does any one know whether there is a difference in format of a .pfx and .p12
file or they are the same. 

 

Regards,

Wahaj



Ascertia Ltd
Orchard Building
Royal Holloway
Egham, Surrey
United Kingdom
TW20 0EX

t.  [phone]
f.  [phone]

www.ascertia.com


  _____  

                           Applied Trust

  _____  

 



**NOTICE***
This e-mail message is confidential, intended only for the 
named recipient(s) above and may contain information
that is privileged, attorney work product or exempt from
disclosure under applicable law. If you have received this
message in error, or are not the named recipient(s), please
immediately delete this e-mail message from your computer. 

 


------=_NextPart_001_0023_01C46009.F051EE90
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<base href=3D"file:///F:\Data\Ascertia\Documents\General\Company\">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Ascertia LtdOrchard BuildingRoyal HollowayEgham, SurreyUnited
KingdomTW20 0EXt</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Arial Unicode MS";
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>No. They are the =
same.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>-Laudon<o:p></o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Wahaj<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, July 02, =
2004 3:20
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Difference =
between a p12
and pfx file</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Hi,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Does any one know whether there is a difference in format of a =
.pfx and
.p12 file or they are the same. <o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Regards,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Wahaj<o:p></o:p></span></font></p>

</div>

<table class=3DMsoNormalTable border=3D0 cellspacing=3D0 cellpadding=3D0 =
width=3D"100%"
 style=3D'width:100.0%'>
 <tr height=3D139 style=3D'height:104.25pt'>
  <td width=3D"96%" height=3D139 valign=3Dtop =
style=3D'width:96.0%;padding:0in 0in 0in 0in;
  height:104.25pt'>
  <p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
  size=3D1 color=3Dnavy face=3DVerdana><span =
style=3D'font-size:7.5pt;font-family:Verdana;
  color:navy'><br>
  Ascertia Ltd<br>
  <ST1:PLACE><ST1:PLACENAME><ST1:PLACE><ST1:PLACENAME><st1:place =
w:st=3D"on"><st1:PlaceName
   =
w:st=3D"on">Orchard</ST1:PLACENAME></ST1:PLACE></ST1:PLACENAME></st1:Plac=
eName>
   <ST1:PLACETYPE><st1:PlaceType =
w:st=3D"on"><ST1:PLACETYPE>Building</st1:PlaceType></st1:place><br>
  =
<ST1:PLACE><ST1:PLACENAME></ST1:PLACENAME></ST1:PLACE></ST1:PLACETYPE></S=
T1:PLACETYPE>Royal
  <ST1:PLACENAME>Holloway<br>
  Egham, <ST1:PLACE><ST1:PLACE><st1:place =
w:st=3D"on">Surrey</st1:place><br>
  =
<ST1:COUNTRY-REGION><ST1:PLACE></ST1:PLACE></ST1:COUNTRY-REGION></ST1:PLA=
CE><ST1:COUNTRY-REGION><ST1:PLACE><st1:country-region
  w:st=3D"on"><st1:place w:st=3D"on">United =
Kingdom</st1:place></st1:country-region><br>
  </ST1:PLACE></ST1:COUNTRY-REGION></ST1:PLACE>TW20 0EX<br>
  <br>
  t.&nbsp; [phone]<br>
  f.&nbsp; [phone]</span></font><o:p></o:p></p>
  <p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
  size=3D1 color=3Dnavy face=3DVerdana><span =
style=3D'font-size:7.5pt;font-family:Verdana;
  color:navy'><a =
href=3D"http://www.ascertia.com">www.ascertia.com</a></span></font><o:p><=
/o:p></p>
  </td>
 </tr>
 <tr height=3D155 style=3D'height:116.25pt'>
  <td width=3D"96%" height=3D155 style=3D'width:96.0%;padding:0in 0in =
0in 0in;
  height:116.25pt'>
  <div>
  <div class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
  style=3D'font-size:12.0pt'>
  <hr size=3D1 width=3D"100%" noshade color=3D"#8c378b" align=3Dleft>
  </span></font></div>
  </div>
  <p class=3DMsoNormal><font size=3D1 color=3Dnavy face=3DVerdana><span
  =
style=3D'font-size:7.5pt;font-family:Verdana;color:navy'>&nbsp;&nbsp;&nbs=
p; </span></font><img
  border=3D0 width=3D81 height=3D50 id=3D"_x0000_i1026"
  src=3D"cid:[e-mail]20C190"><em><i><font size=3D6 =
color=3Dteal
  face=3D"Times New Roman"><span =
style=3D'font-size:24.0pt;color:teal'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
  &nbsp; Applied Trust</span></font></i></em><o:p></o:p></p>
  <div>
  <div class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
  style=3D'font-size:12.0pt'>
  <hr size=3D1 width=3D"100%" noshade color=3D"#8c378b" align=3Dleft>
  </span></font></div>
  </div>
  <p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
  size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>
  </td>
 </tr>
 <tr height=3D102 style=3D'height:76.5pt'>
  <td width=3D"96%" height=3D102 valign=3Dtop =
style=3D'width:96.0%;padding:0in 0in 0in 0in;
  height:76.5pt'>
  <table class=3DMsoNormalTable border=3D0 cellspacing=3D0 =
cellpadding=3D0 width=3D440
   style=3D'width:330.0pt' height=3D103>
   <tr>
    <td style=3D'padding:0in 0in 0in 0in'>
    <p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:
    auto'><font size=3D1 color=3D"#999999" face=3DVerdana><span =
style=3D'font-size:
    7.5pt;font-family:Verdana;color:#999999'>**NOTICE***<br>
    This e-mail message is confidential, intended only for the <br>
    named recipient(s) above and may contain information<br>
    that is privileged, attorney work product or exempt from<br>
    disclosure under applicable law. If you have received this<br>
    message in error, or are not the named recipient(s), please<br>
    immediately delete this e-mail message from your computer. =
</span></font><o:p></o:p></p>
    </td>
   </tr>
  </table>
  <p class=3DMsoNormal><font size=3D3 face=3D"Arial Unicode MS"><span
  style=3D'font-size:12.0pt;font-family:"Arial Unicode =
MS"'><o:p></o:p></span></font></p>
  </td>
 </tr>
 </ST1:PLACENAME></ST1:PLACE>
</table>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_001_0023_01C46009.F051EE90--

------=_NextPart_000_0022_01C46009.F051EE90
Content-Type: image/gif;
	name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <[e-mail]20C190>

R0lGODlhUQAyAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAAAB
AAEAgAAAAAECAwICRAEAOw==

------=_NextPart_000_0022_01C46009.F051EE90--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62AG38U038541; Fri, 2 Jul 2004 03:16:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i62AG3fC038540; Fri, 2 Jul 2004 03:16:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk (ns3.worldcall.net.pk [203.81.192.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62AG1eB038524 for <[e-mail]>; Fri, 2 Jul 2004 03:16:02 -0700 (PDT) (envelope-from [e-mail])
Received: from identrusva1 ([203.81.199.82]) by ns3.worldcall.net.pk (8.12.11/8.12.11) with SMTP id i62ABYLC028931 for <[e-mail]>; Fri, 2 Jul 2004 16:11:47 +0600 (PKST)
Message-ID: <004f01c4601e$28659d90$[e-mail]>
From: "Wahaj" <[e-mail]>
To: <[e-mail]>
Subject: Difference between a p12 and pfx file
Date: Fri, 2 Jul 2004 15:19:57 +0500
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_004B_01C46048.091A3200"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_004B_01C46048.091A3200
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_004C_01C46048.091A3200"


------=_NextPart_001_004C_01C46048.091A3200
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Ascertia LtdOrchard BuildingRoyal HollowayEgham, SurreyUnited =
KingdomTW20 0EXtHi,

Does any one know whether there is a difference in format of a .pfx and =
.p12 file or they are the same.=20

Regards,
Wahaj

      Ascertia Ltd
      Orchard Building
      Royal Holloway
      Egham, Surrey
      United Kingdom
      TW20 0EX

      t.  [phone]
      f.  [phone]

      www.ascertia.com
    =20

-------------------------------------------------------------------------=
-

                                 Applied Trust


-------------------------------------------------------------------------=
-

      =20
    =20
   **NOTICE***
            This e-mail message is confidential, intended only for the=20
            named recipient(s) above and may contain information
            that is privileged, attorney work product or exempt from
            disclosure under applicable law. If you have received this
            message in error, or are not the named recipient(s), please
            immediately delete this e-mail message from your computer.=20
          =20

    =20

=20

------=_NextPart_001_004C_01C46048.091A3200
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:v =3D "urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>Ascertia LtdOrchard =
BuildingRoyal HollowayEgham, SurreyUnited KingdomTW20 0EXt</TITLE><BASE=20
href=3Dfile://F:\Data\Ascertia\Documents\General\Company\>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20
href=3D"./Ascertia%20Ltd_files/filelist.xml" rel=3DFile-List><LINK=20
href=3D"./Ascertia%20Ltd_files/editdata.mso" =
rel=3DEdit-Time-Data><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><!--[if gte mso 9]><xml>
 <o:DocumentProperties>
  <o:Author>Atiq Ur Rahman</o:Author>
  <o:LastAuthor>Atiq Ur Rahman</o:LastAuthor>
  <o:Revision>2</o:Revision>
  <o:TotalTime>3</o:TotalTime>
  <o:Created>2004-04-14T10:40:00Z</o:Created>
  <o:LastSaved>2004-04-14T10:48:00Z</o:LastSaved>
  <o:Pages>1</o:Pages>
  <o:Words>87</o:Words>
  <o:Characters>497</o:Characters>
  <o:Company>Ascertia Ltd.</o:Company>
  <o:Lines>4</o:Lines>
  <o:Paragraphs>1</o:Paragraphs>
  <o:CharactersWithSpaces>610</o:CharactersWithSpaces>
  <o:Version>9.2720</o:Version>
 </o:DocumentProperties>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:PunctuationKerning/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Arial Unicode MS";
	panose-1:2 11 6 4 2 2 2 2 2 4;
	mso-font-charset:128;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1 -369098753 63 0 4129023 0;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:536871559 0 0 0 415 0;}
@font-face
	{font-family:"\@Arial Unicode MS";
	panose-1:2 11 6 4 2 2 2 2 2 4;
	mso-font-charset:128;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1 -369098753 63 0 4129023 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1032"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1"/>
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: .5in" vLink=3Dpurple =
link=3Dblue=20
bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Does any one know whether there is a difference in format of a .pfx =
and=20
.p12 file or they are the same. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>Wahaj</DIV>
<DIV class=3DSection1>
<TABLE=20
style=3D"WIDTH: 100%; mso-cellspacing: 0in; mso-padding-alt: 0in 0in 0in =
0in"=20
cellSpacing=3D0 cellPadding=3D0 width=3D"100%" border=3D0>
  <TBODY>
  <TR style=3D"HEIGHT: 104.25pt">
    <TD=20
    style=3D"PADDING-RIGHT: 0in; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; =
WIDTH: 96%; PADDING-TOP: 0in; HEIGHT: 104.25pt"=20
    vAlign=3Dtop width=3D"96%">
      <P class=3DMsoNormal=20
      style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: =
auto"><SPAN=20
      style=3D"FONT-SIZE: 7.5pt; COLOR: navy; FONT-FAMILY: =
Verdana"><BR>Ascertia=20
      Ltd<BR><ST1:PLACE><ST1:PLACENAME><ST1:PLACE><ST1:PLACENAME><SPAN=20
      style=3D"mso-no-proof: =
yes">Orchard</SPAN></ST1:PLACENAME></ST1:PLACE></ST1:PLACENAME><SPAN=20
      style=3D"mso-no-proof: yes"> </SPAN><ST1:PLACETYPE><SPAN=20
      style=3D"mso-no-proof: =
yes"><ST1:PLACETYPE>Building</SPAN><BR><ST1:PLACE><ST1:PLACENAME></ST1:PL=
ACETYPE></ST1:PLACETYPE><SPAN=20
      style=3D"mso-no-proof: yes">Royal</ST1:PLACENAME>=20
      <ST1:PLACENAME>Holloway<BR>Egham, =
</SPAN><ST1:PLACE><ST1:PLACE><SPAN=20
      style=3D"mso-no-proof: =
yes">Surrey</SPAN><BR><ST1:COUNTRY-REGION><ST1:PLACE></ST1:PLACE></ST1:PL=
ACE><ST1:COUNTRY-REGION><ST1:PLACE><SPAN=20
      style=3D"mso-no-proof: yes">United=20
      =
Kingdom</SPAN><BR></ST1:PLACE></ST1:COUNTRY-REGION></ST1:PLACE></ST1:COUN=
TRY-REGION><SPAN=20
      style=3D"mso-no-proof: yes">TW20 0EX<BR><BR>t.&nbsp; +44 (0)1784=20
      497321<BR>f.&nbsp; [phone]</SPAN></SPAN><SPAN=20
      style=3D"mso-no-proof: yes"><o:p></o:p></P></SPAN>
      <P class=3DMsoNormal=20
      style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: =
auto"><SPAN=20
      style=3D"FONT-SIZE: 7.5pt; COLOR: navy; FONT-FAMILY: Verdana"><A=20
      href=3D"http://www.ascertia.com"><SPAN=20
      style=3D"mso-no-proof: =
yes">www.ascertia.com</A></SPAN></SPAN><SPAN=20
      style=3D"mso-no-proof: yes"><o:p></o:p></P></SPAN></TD></TR>
  <TR style=3D"HEIGHT: 116.25pt; mso-yfti-irow: 1">
    <TD=20
    style=3D"PADDING-RIGHT: 0in; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; =
WIDTH: 96%; PADDING-TOP: 0in; HEIGHT: 116.25pt"=20
    width=3D"96%">
      <DIV class=3DMsoNormal>
      <HR align=3Dleft width=3D"100%" color=3D#8c378b noShade SIZE=3D1>
      </DIV><SPAN=20
      style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA"></SPAN></SPAN><SPAN=20
      style=3D"mso-no-proof: yes"><SPAN style=3D"mso-no-proof: yes">
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-SIZE: 7.5pt; COLOR: navy; FONT-FAMILY: =
Verdana">&nbsp;&nbsp;&nbsp;=20
      </SPAN></SPAN><SPAN style=3D"mso-no-proof: yes"><!--[if gte vml =
1]><v:shapetype
   id=3D"_x0000_t75" coordsize=3D"21600,21600" o:spt=3D"75" =
o:preferrelative=3D"t"
   path=3D"m@4@5l@4@11@9@11@9@5xe" filled=3D"f" stroked=3D"f">
   <v:stroke joinstyle=3D"miter"/>
   <v:formulas>
    <v:f eqn=3D"if lineDrawn pixelLineWidth 0"/>
    <v:f eqn=3D"sum @0 1 0"/>
    <v:f eqn=3D"sum 0 0 @1"/>
    <v:f eqn=3D"prod @2 1 2"/>
    <v:f eqn=3D"prod @3 21600 pixelWidth"/>
    <v:f eqn=3D"prod @3 21600 pixelHeight"/>
    <v:f eqn=3D"sum @0 0 1"/>
    <v:f eqn=3D"prod @6 1 2"/>
    <v:f eqn=3D"prod @7 21600 pixelWidth"/>
    <v:f eqn=3D"sum @8 21600 0"/>
    <v:f eqn=3D"prod @7 21600 pixelHeight"/>
    <v:f eqn=3D"sum @10 21600 0"/>
   </v:formulas>
   <v:path o:extrusionok=3D"f" gradientshapeok=3D"t" =
o:connecttype=3D"rect"/>
   <o:lock v:ext=3D"edit" aspectratio=3D"t"/>
  </v:shapetype><v:shape id=3D"_x0000_i1026" type=3D"#_x0000_t75" =
alt=3D"" style=3D'width:60.75pt;
   height:37.5pt'/><![endif]--><![if !vml]><IMG height=3D50=20
      src=3D"cid:004a01c4601e$2041b900$[e-mail]" =
width=3D81 border=3D0=20
      v:shapes=3D"_x0000_i1026"><![endif]></SPAN><EM><SPAN=20
      style=3D"FONT-SIZE: 24pt; COLOR: teal"><SPAN=20
      style=3D"mso-no-proof: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      &nbsp; Applied Trust</SPAN></SPAN></EM><SPAN=20
      style=3D"mso-no-proof: yes"><o:p></o:p></P></SPAN>
      <DIV class=3DMsoNormal>
      <HR align=3Dleft width=3D"100%" color=3D#8c378b noShade SIZE=3D1>
      </DIV><SPAN=20
      style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA"></SPAN></SPAN><SPAN=20
      style=3D"mso-no-proof: yes">
      <P class=3DMsoNormal=20
      style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: =
auto"><SPAN=20
      style=3D"mso-no-proof: =
yes">&nbsp;<o:p></o:p></P></SPAN></SPAN></TD></TR><SPAN=20
  style=3D"mso-no-proof: yes">
  <TR style=3D"HEIGHT: 76.5pt; mso-yfti-irow: 2; mso-yfti-lastrow: yes">
    <TD=20
    style=3D"PADDING-RIGHT: 0in; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; =
WIDTH: 96%; PADDING-TOP: 0in; HEIGHT: 76.5pt"=20
    vAlign=3Dtop width=3D"96%">
      <TABLE=20
      style=3D"WIDTH: 330pt; mso-cellspacing: 0in; mso-padding-alt: 0in =
0in 0in 0in"=20
      height=3D103 cellSpacing=3D0 cellPadding=3D0 width=3D440 =
border=3D0>
        <TBODY>
        <TR style=3D"mso-yfti-irow: 0; mso-yfti-lastrow: yes">
          <TD=20
          style=3D"PADDING-RIGHT: 0in; PADDING-LEFT: 0in; =
PADDING-BOTTOM: 0in; PADDING-TOP: 0in">
            <P class=3DMsoNormal=20
            style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: =
auto"><SPAN=20
            style=3D"FONT-SIZE: 7.5pt; COLOR: #999999; FONT-FAMILY: =
Verdana">**NOTICE***<BR>This=20
            e-mail message is confidential, intended only for the =
<BR>named=20
            recipient(s) above and may contain information<BR>that is=20
            privileged, attorney work product or exempt =
from<BR>disclosure under=20
            applicable law. If you have received this<BR>message in =
error, or=20
            are not the named recipient(s), please<BR>immediately delete =
this=20
            e-mail message from your computer. </SPAN></SPAN><SPAN=20
            style=3D"mso-no-proof: =
yes"><o:p></o:p></P></SPAN></TD></TR></TBODY></TABLE>
      <P class=3DMsoNormal><SPAN=20
      style=3D"FONT-FAMILY: 'Arial Unicode =
MS'"><o:p></o:p></SPAN></P></TD></TR></ST1:PLACENAME></ST1:PLACE></ST1:PL=
ACE></TBODY></TABLE>
<P=20
class=3DMsoNormal><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></P></DIV></SPAN></BODY></=
HTML>

------=_NextPart_001_004C_01C46048.091A3200--

------=_NextPart_000_004B_01C46048.091A3200
Content-Type: application/octet-stream;
	name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <004a01c4601e$2041b900$[e-mail]>

R0lGODlhUQAyAHcBMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAEALAAAAAAB
AAEAgAAAAIGBgQICTAEAOw==

------=_NextPart_000_004B_01C46048.091A3200--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i627GDln071390; Fri, 2 Jul 2004 00:16:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i627GDWC071389; Fri, 2 Jul 2004 00:16:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (du-006-030.access.de.clara.net [212.82.229.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i627GBRU071355 for <[e-mail]>; Fri, 2 Jul 2004 00:16:12 -0700 (PDT) (envelope-from [e-mail])
Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 5FDC4B0382 for <[e-mail]>; Fri,  2 Jul 2004 09:14:44 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 02 Jul 2004 09:14:44 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Cross-certification
References: <[e-mail]> <002b01c45f6c$43016c90$0500a8c0@arport> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.84.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jean-Marc Desperrier wrote:
> 
> Anders Rundgren wrote:
> 
>> Although slightly off-topic, may I add that cross-certification is 
>> unlikely to ever be a main-stream activity as neither commercial CAs 
>> or private enterprises having many partners feel any particular need 
>> or interest in these schemes
> 
> There was a presentation by a member of the Asia PKI Forum in the ETSI 
> security plugtests, that showed they were concretely interested in 
> getting this to work to

Watching PPT slides showing that someone is "interested in" something is 
completely different from having it already in production in a reasonable 
big deployment.

=> I don't buy that.

Ciao, Michael.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61Kr045083257; Thu, 1 Jul 2004 13:53:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61Kr0F7083256; Thu, 1 Jul 2004 13:53:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-2-sn3.vrr.skanova.net (av1-2-sn3.vrr.skanova.net [81.228.9.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61Kqx3K083249 for <[e-mail]>; Thu, 1 Jul 2004 13:52:59 -0700 (PDT) (envelope-from [e-mail])
Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 69DD337E83; Thu,  1 Jul 2004 22:52:58 +0200 (CEST)
Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 5B33437E43; Thu,  1 Jul 2004 22:52:58 +0200 (CEST)
Received: from arport (t8o913p66.telia.com [213.64.26.186]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id 285C938011; Thu,  1 Jul 2004 22:52:56 +0200 (CEST)
Message-ID: <00cc01c45fad$0d78fbb0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <002b01c45f6c$43016c90$0500a8c0@arport> <[e-mail]>
Subject: Re: Cross-certification
Date: Thu, 1 Jul 2004 22:50:32 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sure J-M,
But note, I explicitely mentioned private enterprises and
commercial CAs as no likely targets for cross-cert.

Regarding ETSI, PKI-forum etc.

All these places lack an "informaton model", they believe
that security = cryptography and trustworty CAs.  Security
in an organizational environment has other dimensions
that the end-to-end model can't support.  Not a single paper
has been written explaining how archiving, authorization
privacy, etc. is supposed to be handled in a true end-to-end model.
Which is sort of understandable as it is technically infeasible.

It was amusing to read on the S/MIME list, Phill H-B claim
that this (e2e) model have made us stuck for ten years in the
same place.  But as I said, in Scandinavia and in Estonia
we have given up this model and I believe for good.

There is a reason....

Wrong! There are *numerous* reasons.

A simple one is that I used to buy computers from DELL, not 
from Michael Dell.  And DELL knows me as a company account
with Anders Rundgren as contact person.  One of them.

Anders
----- Original Message ----- 
From: "Jean-Marc Desperrier" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, July 01, 2004 19:07
Subject: Re: Cross-certification



Anders Rundgren wrote:

> Although slightly off-topic, may I add that cross-certification is 
> unlikely to ever be a main-stream activity as neither commercial CAs 
> or private enterprises having many partners feel any particular need 
> or interest in these schemes

There was a presentation by a member of the Asia PKI Forum in the ETSI 
security plugtests, that showed they were concretely interested in 
getting this to work to enable inter country level exchange in Asia.
That would cover exchange between China; Hong Kong, Japan, South Korea, 
Singapore, etc...

Also if one is interesting in checking how cross-certification can work 
concretely the best place is certainly to go check all the US Federal 
Bridge Certification Authority  related links.
http://csrc.nist.gov/pki/fbca/welcome.html
 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61H7fCk060725; Thu, 1 Jul 2004 10:07:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61H7fin060724; Thu, 1 Jul 2004 10:07:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61H7eri060717 for <[e-mail]>; Thu, 1 Jul 2004 10:07:40 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft6.fr.colt.net with ESMTP id i61H7dh25235 for <[e-mail]>; Thu, 1 Jul 2004 19:07:39 +0200
Message-ID: <[e-mail]>
Date: Thu, 01 Jul 2004 19:07:38 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226
X-Accept-Language: fr, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Cross-certification
References: <[e-mail]> <002b01c45f6c$43016c90$0500a8c0@arport>
In-Reply-To: <002b01c45f6c$43016c90$0500a8c0@arport>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:

> Although slightly off-topic, may I add that cross-certification is 
> unlikely to ever be a main-stream activity as neither commercial CAs 
> or private enterprises having many partners feel any particular need 
> or interest in these schemes

There was a presentation by a member of the Asia PKI Forum in the ETSI 
security plugtests, that showed they were concretely interested in 
getting this to work to enable inter country level exchange in Asia.
That would cover exchange between China; Hong Kong, Japan, South Korea, 
Singapore, etc...

Also if one is interesting in checking how cross-certification can work 
concretely the best place is certainly to go check all the US Federal 
Bridge Certification Authority  related links.
http://csrc.nist.gov/pki/fbca/welcome.html
 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61GlRcJ059205; Thu, 1 Jul 2004 09:47:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61GlRip059204; Thu, 1 Jul 2004 09:47:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61GlQHN059194 for <[e-mail]>; Thu, 1 Jul 2004 09:47:26 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft5.fr.colt.net with ESMTP id i61GlIV07450 for <[e-mail]>; Thu, 1 Jul 2004 18:47:23 +0200
Message-ID: <[e-mail]>
Date: Thu, 01 Jul 2004 18:47:18 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226
X-Accept-Language: fr, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Cross-certification
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alberti Antoine wrote:

> [...] the second document Craig Borysowich indicated gives an example 
> of an authority that has several public keys. I suppose this is a 
> consequence of a key renewal (is it really the only case ?). But then, 
> the cross-certification is not valid anymore, is it ? I assume 
> certifying means signing a public key, but I may be wrong.

The CA should get a cross-certificate for it's new key to simplify the case.
It's up to proper implementation of path validation to correctly handle 
the fact the CA has several different key/certificate, and to be able 
select the correct path.

But according to RFC2510 (&2.4.1), it is not strictly required to get a 
new cross-certificate.
When getting a certificate for it's new key, the CA should generate a 
"old with new" and a "new with old" certificate, and the path validation 
should be able to switch from one of the key to the other by following 
here what we could call a mono-entity cross-certification.

This said it will change the length of the path, which can break the 
verification depending on the constraints, so it is much better to get 
one cross-certificate per key.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61D9NHE042407; Thu, 1 Jul 2004 06:09:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61D9NIF042406; Thu, 1 Jul 2004 06:09:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av4-1-sn3.vrr.skanova.net (av4-1-sn3.vrr.skanova.net [81.228.9.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61D9M3p042382 for <[e-mail]>; Thu, 1 Jul 2004 06:09:23 -0700 (PDT) (envelope-from [e-mail])
Received: by av4-1-sn3.vrr.skanova.net (Postfix, from userid 502) id D163337EE1; Thu,  1 Jul 2004 15:09:12 +0200 (CEST)
Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av4-1-sn3.vrr.skanova.net (Postfix) with ESMTP id C0AB437E42; Thu,  1 Jul 2004 15:09:12 +0200 (CEST)
Received: from arport (t11o913p71.telia.com [213.64.28.71]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id 0A0813800C; Thu,  1 Jul 2004 15:09:09 +0200 (CEST)
Message-ID: <002b01c45f6c$43016c90$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Alberti Antoine" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Cross-certification
Date: Thu, 1 Jul 2004 15:06:44 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C45F7D.05AB2730"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0028_01C45F7D.05AB2730
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Cross-certificationAntoine,

Although slightly off-topic, may I add that cross-certification is =
unlikely to ever be a main-stream activity as neither commercial CAs or =
private enterprises having many partners feel any particular need or =
interest in these schemes that are based on the same intellectual =
foundation as public LDAP directories.  You may be interested to hear =
that governments in Scandinavia have found a much more useful way to =
communicate and that is using domain-based security.  This reduces the =
number of external CA certificates and keys to an absolute minimum.

Anders Rundgren
  ----- Original Message -----=20
  From: Alberti Antoine=20
  To: [e-mail]=20
  Sent: Thursday, July 01, 2004 11:29
  Subject: RE: Cross-certification


  Thanks for the answers. Wouldn't this issue diserve a little bit of a =
specification ? For instance, I understand cross-certification when an =
authority has several certificate with the same public key and the same =
subjectDN, but the second document Craig Borysowich indicated gives an =
example of an authority that has several public keys. I suppose this is =
a consequence of a key renewal (is it really the only case ?). But then, =
the cross-certification is not valid anymore, is it ? I assume =
certifying means signing a public key, but I may be wrong.
    -----Message d'origine-----
    De : Borysowich, Craig (CSS) [mailto:[e-mail]]
    Envoy=E9 : mercredi 30 juin 2004 20:15
    =C0 : Alberti Antoine
    Objet : RE: Cross-certification


    http://www.au-kbc.org/bpmain1/PKI/cross_certification.pdf

    http://www.geminisecurity.com/docs/ndss050.doc

    These papers may give you some insight...
      -----Original Message-----
      From: Alberti Antoine [mailto:[e-mail]]
      Sent: Wednesday, June 30, 2004 11:16 AM
      To: [e-mail]
      Subject: Cross-certification


      Would there be any document where cross-certification and =
non-hierarchical infrastructures are defined, please ?=20
      Regards.=20

                                                                         =
                                                                     =20

                Antoine Alberti                 Axway.  a Sopra Group =
company  =20
                Tel  : [phone]             XFB R&D=20
                Fax : [phone]              26 Rue des =
Pavillons=20
                email: [e-mail]               92807 Puteaux =
Cedex - France=20




------=_NextPart_000_0028_01C45F7D.05AB2730
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><TITLE>Cross-certification</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Antoine,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Although slightly off-topic, may I add =
that=20
cross-certification is unlikely to ever be a main-stream activity as =
neither=20
commercial CAs or private enterprises having many partners&nbsp;feel any =

particular&nbsp;need or interest in these schemes that are based on the =
same=20
intellectual foundation as public LDAP directories.&nbsp; You may be =
interested=20
to hear that governments in Scandinavia have found a much more useful =
way to=20
communicate and that is using domain-based security.&nbsp; This reduces =
the=20
number of external CA certificates and keys to an absolute =
minimum.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] =
href=3D"mailto:[e-mail]">Alberti=20
  Antoine</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, July 01, 2004 =
11:29</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: =
Cross-certification</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D954191209-01072004>Thanks for the answers. Wouldn't this issue =
diserve a=20
  little bit of a specification ? For instance, I understand =
cross-certification=20
  when an authority has several certificate with the same public key and =
the=20
  same subjectDN, but the second document Craig Borysowich indicated =
gives an=20
  example of an authority that has several public keys.&nbsp;I suppose =
this is a=20
  consequence&nbsp;of a key renewal (is it really the only case =
?).&nbsp;But=20
  then, the cross-certification is not valid anymore, is it ? I assume=20
  certifying means signing a public key, but I may be =
wrong.</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Message d'origine-----<BR><B>De&nbsp;:</B> Borysowich, =
Craig=20
    (CSS) =
[mailto:[e-mail]]<BR><B>Envoy=E9&nbsp;:</B>=20
    mercredi 30 juin 2004 20:15<BR><B>=C0&nbsp;:</B> Alberti=20
    Antoine<BR><B>Objet&nbsp;:</B> RE: =
Cross-certification<BR><BR></FONT></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><A=20
    =
href=3D"http://www.au-kbc.org/bpmain1/PKI/cross_certification.pdf">http:/=
/www.au-kbc.org/bpmain1/PKI/cross_certification.pdf</A></FONT></DIV>
    <DIV><SPAN class=3D967451218-30062004><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D967451218-30062004><FONT face=3DArial =
color=3D#0000ff size=3D2><A=20
    =
href=3D"http://www.geminisecurity.com/docs/ndss050.doc">http://www.gemini=
security.com/docs/ndss050.doc</A></FONT></SPAN></DIV>
    <DIV><SPAN class=3D967451218-30062004><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D967451218-30062004><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>These papers may give you some =
insight...</FONT></SPAN></DIV>
    <BLOCKQUOTE>
      <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
      size=3D2>-----Original Message-----<BR><B>From:</B> Alberti =
Antoine=20
      [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, June 30, =
2004 11:16=20
      AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B>=20
      Cross-certification<BR><BR></FONT></DIV><!-- Converted from =
text/rtf format -->
      <P><FONT face=3DArial size=3D2>Would there be any document where=20
      cross-certification and non-hierarchical infrastructures are =
defined,=20
      please ?</FONT> <BR><FONT face=3DArial size=3D2>Regards.</FONT> =
</P>
      <UL>
        <P><SPAN =
lang=3Den-us><U><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
        <FONT face=3DTahoma=20
        =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
        </FONT></B></U></SPAN></P>
        <P><SPAN =
lang=3Den-us><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
        face=3DTahoma size=3D2>Antoine Alberti=20
        =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B></SPAN><B><SPAN=20
        lang=3Dfr></SPAN><SPAN lang=3Dfr>=20
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
        lang=3Dfr></SPAN><SPAN lang=3Dfr> <FONT face=3D"Arial Black"=20
        color=3D#808080>Axwa</FONT><FONT face=3D"Arial Black"=20
        color=3D#ff0000>y.</FONT></SPAN></B><SPAN lang=3Dfr><FONT =
face=3DTahoma=20
        size=3D2>&nbsp; a Sopra Group company&nbsp;&nbsp; =
</FONT></SPAN><BR><SPAN=20
        lang=3Den-us>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
face=3DTahoma=20
        size=3D2>Tel&nbsp; : [phone] =
37&nbsp;&nbsp;&nbsp;&nbsp;=20
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN=20
        lang=3Den-us><B> <FONT face=3DTahoma color=3D#0000ff =
size=3D2>XF</FONT><FONT=20
        face=3DTahoma color=3D#ff0000 size=3D2>B</FONT><FONT =
face=3DTahoma size=3D2>=20
        R&amp;D</FONT></B></SPAN> <BR><SPAN=20
        lang=3Den-us>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
face=3DTahoma=20
        size=3D2>Fax : [phone] =
25&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 26 Rue des=20
        Pavillons</FONT></SPAN> <BR><SPAN=20
        lang=3Den-us>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
face=3DTahoma=20
        size=3D2>email: [e-mail]</FONT></SPAN><SPAN=20
        lang=3Dfr>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN =
lang=3Den-us> <FONT=20
        face=3DTahoma size=3D2>92807 Puteaux Cedex - =
France</FONT></SPAN><SPAN=20
        lang=3Dfr></SPAN>=20
</P><BR><BR></UL></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0028_01C45F7D.05AB2730--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61C2K8N033317; Thu, 1 Jul 2004 05:02:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i61C2K6T033316; Thu, 1 Jul 2004 05:02:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61C2J0n033271 for <[e-mail]>; Thu, 1 Jul 2004 05:02:20 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 2B6FC1CD962; Fri,  2 Jul 2004 00:01:12 +1200 (NZST)
Received: from pgut001 by medusa01 with local (Exim 4.32) id 1Bg0Gi-0006bO-7C; Fri, 02 Jul 2004 00:02:20 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Cross-certification
In-Reply-To: <[e-mail]>
Message-Id: <E1Bg0Gi-0006bO-7C@medusa01>
Date: Fri, 02 Jul 2004 00:02:20 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Alberti Antoine" <[e-mail]> writes:

>Would there be any document where cross-certification and non-hierarchical
>infrastructures are defined, please ?

I believe H.P.Lovecraft has published some works on this.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i619Tr81000424; Thu, 1 Jul 2004 02:29:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i619Tr2N000423; Thu, 1 Jul 2004 02:29:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i619Tpck000382 for <[e-mail]>; Thu, 1 Jul 2004 02:29:52 -0700 (PDT) (envelope-from [e-mail])
Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id i619TkKp026998 for <[e-mail]>; Thu, 1 Jul 2004 11:29:46 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45F4D.F282F2AA"
Subject: RE: Cross-certification
Date: Thu, 1 Jul 2004 11:29:45 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Cross-certification
Thread-Index: AcRezlHeBZHN+hQLTGyvsYLdkwR4XQAfTEyw
From: "Alberti Antoine" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 01 Jul 2004 09:36:17.0765 (UTC) FILETIME=[DC14B950:01C45F4E]
X-Scanned-By: MIMEDefang 2.38
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C45F4D.F282F2AA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks for the answers. Wouldn't this issue diserve a little bit of a =
specification ? For instance, I understand cross-certification when an =
authority has several certificate with the same public key and the same =
subjectDN, but the second document Craig Borysowich indicated gives an =
example of an authority that has several public keys. I suppose this is =
a consequence of a key renewal (is it really the only case ?). But then, =
the cross-certification is not valid anymore, is it ? I assume =
certifying means signing a public key, but I may be wrong.

-----Message d'origine-----
De : Borysowich, Craig (CSS) [mailto:[e-mail]]
Envoy=E9 : mercredi 30 juin 2004 20:15
=C0 : Alberti Antoine
Objet : RE: Cross-certification


http://www.au-kbc.org/bpmain1/PKI/cross_certification.pdf
=20
http://www.geminisecurity.com/docs/ndss050.doc
=20
These papers may give you some insight...

-----Original Message-----
From: Alberti Antoine [mailto:[e-mail]]
Sent: Wednesday, June 30, 2004 11:16 AM
To: [e-mail]
Subject: Cross-certification



Would there be any document where cross-certification and =
non-hierarchical infrastructures are defined, please ?=20
Regards.=20

	                                                                        =
                                                              =20

	        Antoine Alberti                 Axway.  a Sopra Group company   =

        Tel  : [phone]             XFB R&D=20
        Fax : [phone]              26 Rue des Pavillons=20
        email: [e-mail]               92807 Puteaux Cedex - =
France=20




------_=_NextPart_001_01C45F4D.F282F2AA
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 HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Cross-certification</TITLE>

<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D954191209-01072004>Thanks=20
for the answers. Wouldn't this issue diserve a little bit of a =
specification ?=20
For instance, I understand cross-certification when an authority has =
several=20
certificate with the same public key and the same subjectDN, but the =
second=20
document Craig Borysowich indicated gives an example of an authority =
that has=20
several public keys.&nbsp;I suppose this is a consequence&nbsp;of a key =
renewal=20
(is it really the only case ?).&nbsp;But then, the cross-certification =
is not=20
valid anymore, is it ? I assume certifying means signing a public key, =
but I may=20
be wrong.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Message d'origine-----<BR><B>De&nbsp;:</B> Borysowich, =
Craig (CSS)=20
  [mailto:[e-mail]]<BR><B>Envoy=E9&nbsp;:</B> =
mercredi 30=20
  juin 2004 20:15<BR><B>=C0&nbsp;:</B> Alberti =
Antoine<BR><B>Objet&nbsp;:</B> RE:=20
  Cross-certification<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><A=20
  =
href=3D"http://www.au-kbc.org/bpmain1/PKI/cross_certification.pdf">http:/=
/www.au-kbc.org/bpmain1/PKI/cross_certification.pdf</A></FONT></DIV>
  <DIV><SPAN class=3D967451218-30062004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D967451218-30062004><FONT face=3DArial =
color=3D#0000ff size=3D2><A=20
  =
href=3D"http://www.geminisecurity.com/docs/ndss050.doc">http://www.gemini=
security.com/docs/ndss050.doc</A></FONT></SPAN></DIV>
  <DIV><SPAN class=3D967451218-30062004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D967451218-30062004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>These papers may give you some insight...</FONT></SPAN></DIV>
  <BLOCKQUOTE>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Alberti Antoine=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, June 30, 2004 =
11:16=20
    AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B>=20
    Cross-certification<BR><BR></FONT></DIV><!-- Converted from text/rtf =
format -->
    <P><FONT face=3DArial size=3D2>Would there be any document where=20
    cross-certification and non-hierarchical infrastructures are =
defined, please=20
    ?</FONT> <BR><FONT face=3DArial size=3D2>Regards.</FONT> </P>
    <UL>
      <P><SPAN =
lang=3Den-us><U><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
      face=3DTahoma=20
      =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      </FONT></B></U></SPAN></P>
      <P><SPAN =
lang=3Den-us><B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
      face=3DTahoma size=3D2>Antoine Alberti=20
      =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B></SPAN><B><SPAN=20
      lang=3Dfr></SPAN><SPAN lang=3Dfr>=20
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
      lang=3Dfr></SPAN><SPAN lang=3Dfr> <FONT face=3D"Arial Black"=20
      color=3D#808080>Axwa</FONT><FONT face=3D"Arial Black"=20
      color=3D#ff0000>y.</FONT></SPAN></B><SPAN lang=3Dfr><FONT =
face=3DTahoma=20
      size=3D2>&nbsp; a Sopra Group company&nbsp;&nbsp; =
</FONT></SPAN><BR><SPAN=20
      lang=3Den-us>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
face=3DTahoma=20
      size=3D2>Tel&nbsp; : [phone]&nbsp;&nbsp;&nbsp;&nbsp;=20
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN=20
      lang=3Den-us><B> <FONT face=3DTahoma color=3D#0000ff =
size=3D2>XF</FONT><FONT=20
      face=3DTahoma color=3D#ff0000 size=3D2>B</FONT><FONT face=3DTahoma =
size=3D2>=20
      R&amp;D</FONT></B></SPAN> <BR><SPAN=20
      lang=3Den-us>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
face=3DTahoma=20
      size=3D2>Fax : [phone]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 26 Rue des=20
      Pavillons</FONT></SPAN> <BR><SPAN=20
      lang=3Den-us>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
face=3DTahoma=20
      size=3D2>email: [e-mail]</FONT></SPAN><SPAN=20
      lang=3Dfr>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN =
lang=3Den-us> <FONT=20
      face=3DTahoma size=3D2>92807 Puteaux Cedex - =
France</FONT></SPAN><SPAN=20
      lang=3Dfr></SPAN> =
</P><BR><BR></UL></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C45F4D.F282F2AA--