Subject: RE: SCVP-15

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 30 Jul 2004 22:37:42 -0700

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: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Michael Myers
* Sent: Thursday, July 22, 2004 11:43 AM
* To: [email-masked]
* 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.
*

---

From: "Michael Myers" <[email-masked]>
Date: Sat, 31 Jul 2004 08:07:31 -0700

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Trevor Freeman
Sent: Friday, July 30, 2004 10:38 PM
To: Michael Myers; [email-masked]
Subject: RE: SCVP-15

Hi Mike,

Do you agree?
Trevor

From: "Michael Myers" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, <[email-masked]>
Subject: RE: SCVP-15
Date: Sat, 31 Jul 2004 08:07:31 -0700
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Trevor Freeman
Sent: Friday, July 30, 2004 10:38 PM
To: Michael Myers; [email-masked]
Subject: RE: SCVP-15

Hi Mike,

Do you agree?
Trevor

Content-class: urn:content-classes:message
Subject: RE: Comments on draft-ietf-pkix-scvp-15.txt
Date: Sat, 31 Jul 2004 01:14:39 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

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

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* 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
* 
* 

Content-class: urn:content-classes:message
Subject: RE: SCVP-15
Date: Fri, 30 Jul 2004 22:37:42 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Mike,

Do you agree?
Trevor

Date: Fri, 30 Jul 2004 22:22:48 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, [email-masked]
Subject: multi-domain PKI unofficial BoF
Cc: [email-masked]
Sender: [email-masked]

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: +81 422 91 8498 (ext.3635); Mitaka
Tel: +81 3 5775 8661 (ext.3485); Harajuku
Fax: +81 422 45 0536
e-mail: [email-masked]

Date: Fri, 30 Jul 2004 07:09:52 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: David Chadwick CHADWICK <[email-masked]>
Subject: 8th IFIP TC-6 TC-11 Conference on Communications and Multimedia Security
Sender: [email-masked]

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: [email-masked]

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

Best wishes,

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

Date: Thu, 29 Jul 2004 16:15:14 -0400
From: Steve Hanna <[email-masked]>
Subject: Re: New I-D on Intl Strings in Certs
To: Russ Housley <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

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

--------------ms050700070501020205040605--

Date: Thu, 29 Jul 2004 16:15:05 -0400
From: Steve Hanna <[email-masked]>
Subject: Re: New I-D on Intl Strings in Certs
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], Steve Hanna <[email-masked]>
Sender: [email-masked]

--------------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 [email-masked]. Anyway, on to business.
Let me respond to your comments.

Peter Gutmann wrote:
> Steve Hanna <[email-masked]> 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

--------------ms000908030802010008090303--

Date: Thu, 29 Jul 2004 09:05:43 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Comments on SCVP15
Sender: [email-masked]

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Time-Stamp Protocol (TCP-based protocol)
Date: Thu, 29 Jul 2004 15:36:32 +1200
Sender: [email-masked]

mario ivkovic <[email-masked]> 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.

Date: Wed, 28 Jul 2004 19:09:47 +0200
From: Denis Pinkas <[email-masked]>
To: pkix <[email-masked]>
Subject: Comments on draft-ietf-pkix-scvp-15.txt
Sender: [email-masked]

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

Date: Wed, 28 Jul 2004 14:33:02 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: PKIX WG Agenda for 60th IETF (second try!)
Cc: [email-masked]
Sender: [email-masked]

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 

Date: Wed, 28 Jul 2004 12:46:10 +0200
From: mario ivkovic <[email-masked]>
To: [email-masked]
Subject: Time-Stamp Protocol (TCP-based protocol)
Sender: [email-masked]

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: +43 316 873 5528
Fax: +43 316 873 5520
http://jce.iaik.tugraz.at

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Re: pkix-pi-10.txt - Usage Models
Date: Tue, 27 Jul 2004 17:43:17 +0200
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Date: Tue, 27 Jul 2004 09:58:45 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
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.

Date: Mon, 26 Jul 2004 12:09:51 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: PKIX WG Agenda for 60th IETF (second try!)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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 <[email-masked]>, Tim Polk <[email-masked]>

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.)

Date: Mon, 26 Jul 2004 17:44:48 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: "Jaleel P.A" <[email-masked]>
Cc: [email-masked]
Subject: Re: how to add 'ValidFrom' parameter in conf file ?
Sender: [email-masked]

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.

Date: Mon, 26 Jul 2004 09:54:31 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: PKIX WG Agenda for 60th IETF
Cc: [email-masked], [email-masked]
Sender: [email-masked]

PKIX WG (pkix-wg)

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

CHAIR: Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>

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.)

From: "Jaleel P.A" <[email-masked]>
To: <[email-masked]>
Subject: RE: how to add 'ValidFrom' parameter in conf file ?
Date: Mon, 26 Jul 2004 15:19:42 +0530
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Jaleel P.A
Sent: Monday, July 26, 2004 10:30 AM
To: [email-masked]
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 

Date: Mon, 26 Jul 2004 12:42:53 +0200 (CEST)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

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 <[email-masked]> on Mon, 26 Jul 2004 11:27:46 +0200, Denis Pinkas <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Mon, 26 Jul 2004 11:27:46 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Manger, James H" <[email-masked]>
CC: [email-masked]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Sender: [email-masked]

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:[email-masked]]
> Sent: Thursday, 22 July 2004 5:58 AM
> To: Denis Pinkas
> Cc: Russ Housley; Manger, James H; [email-masked]
> 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
> 
> 
> 
> 

From: "Jaleel P.A" <[email-masked]>
To: <[email-masked]>
Subject: how to add 'ValidFrom' parameter in conf file ?
Date: Mon, 26 Jul 2004 10:29:42 +0530
Sender: [email-masked]

Hi

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

Thanks 
Jaleel 

Date: Fri, 23 Jul 2004 10:38:45 +0200
From: Massimiliano Pala <[email-masked]>
Organization: Politecnico di Torino
To: [email-masked]
Subject: Re: Request: Send me signed messages
Sender: [email-masked]

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]      [email-masked]
                                                    Tel.:   +39 (0)11  564 7081
http://security.polito.it                       Fax:    +39   178  270 2077
                                                    Mobile: +39 (0)347 7222 365

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

--------------ms070000030901080401020603--

Date: Fri, 23 Jul 2004 10:27:32 +0200
From: Olivier Dubuisson <[email-masked]>
Organization: France Telecom R&D
To: [email-masked]
Subject: Re: PI: 10: Split Identity++
Sender: [email-masked]

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: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/

content-class: urn:content-classes:message
Subject: RE: PI: 10: Split Identity++
Date: Fri, 23 Jul 2004 11:29:49 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
> Sent:	Friday, 23 July 2004 5:59 AM
> To:	[email-masked]
> 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.

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Re: pkix-pi-10 - Split Identity++
Date: Thu, 22 Jul 2004 21:58:59 +0200
Sender: [email-masked]

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.

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: Re: SCVP-15
Date: Thu, 22 Jul 2004 11:42:54 -0700
Importance: Normal
Sender: [email-masked]

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.

Date: Thu, 22 Jul 2004 08:08:12 -0400
To: "David P. Kemp" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
Cc: [email-masked]
Sender: [email-masked]

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.

From: "Faisal Maqsood" <[email-masked]>
To: <[email-masked]>
Subject: SCVP Structure Suggestions
Date: Thu, 22 Jul 2004 18:54:47 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

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

Date: Thu, 22 Jul 2004 08:50:56 -0400
From: "David P. Kemp" <[email-masked]>
To: "Fisher, James L." <[email-masked]>
CC: [email-masked]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Date: Thu, 22 Jul 2004 07:18:22 -0400
From: "Fisher, James L." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Date: Thu, 22 Jul 2004 10:40:00 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, 22 July 2004 5:58 AM
To: Denis Pinkas
Cc: Russ Housley; Manger, James H; [email-masked]
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

Date: Wed, 21 Jul 2004 15:57:54 -0400
From: "David P. Kemp" <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: Russ Housley <[email-masked]>, "Manger, James H" <[email-masked]>, [email-masked]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Sender: [email-masked]

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

Date: Wed, 21 Jul 2004 18:40:40 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Alberti Antoine <[email-masked]>
CC: Russ Housley <[email-masked]>, "Manger, James H" <[email-masked]>, [email-masked]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Sender: [email-masked]

> 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 : [email-masked]
>>[mailto:[email-masked]]De la part de Denis Pinkas
>>Envoyé : mercredi 21 juillet 2004 18:01
>>À : Russ Housley
>>Cc : Manger, James H; [email-masked]
>>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:         [email-masked] 
>>>>
>>>>[mailto:[email-masked]]
>>>>
>>>>>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:[email-masked]]
>>>>>      Sent:   Thursday, 15 July 2004 6:06 PM
>>>>>      Cc:     [email-masked]
>>>>>
>>>>
>>>>                ... the definition of the PI has been 
>>>
>>changed to allow 
>>
>>>>to use the serialNumber attribute from the subject DN.
>>>
>>>
>>>
>>
>>
> 

content-class: urn:content-classes:message
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Date: Wed, 21 Jul 2004 18:20:06 +0200
From: "Alberti Antoine" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: "Manger, James H" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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 : [email-masked]
> [mailto:[email-masked]]De la part de Denis Pinkas
> Envoyé : mercredi 21 juillet 2004 18:01
> À : Russ Housley
> Cc : Manger, James H; [email-masked]
> 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:         [email-masked] 
> >> [mailto:[email-masked]]
> >> > 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:[email-masked]]
> >> >       Sent:   Thursday, 15 July 2004 6:06 PM
> >> >       Cc:     [email-masked]
> >> >
> >>                 ... the definition of the PI has been 
> changed to allow 
> >> to use the serialNumber attribute from the subject DN.
> > 
> > 
> > 
> 
> 
> 

Date: Wed, 21 Jul 2004 12:14:07 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Cc: "Manger, James H" <[email-masked]>, [email-masked]
Sender: [email-masked]

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:         [email-masked] [mailto:[email-masked]]
>>> > 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:[email-masked]]
>>> >       Sent:   Thursday, 15 July 2004 6:06 PM
>>> >       Cc:     [email-masked]
>>> >
>>>                 ... the definition of the PI has been changed to allow 
>>> to use the serialNumber attribute from the subject DN.
>>
>
>

Date: Wed, 21 Jul 2004 18:00:35 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: "Manger, James H" <[email-masked]>, [email-masked]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber  attribute
Sender: [email-masked]

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:         [email-masked] 
>> [mailto:[email-masked]]
>> > 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:[email-masked]]
>> >       Sent:   Thursday, 15 July 2004 6:06 PM
>> >       Cc:     [email-masked]
>> >
>>                 ... the definition of the PI has been changed to allow 
>> to use the serialNumber attribute from the subject DN.
> 
> 
> 

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: "Manger, James H" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
Date: Wed, 21 Jul 2004 17:23:14 +0200
Sender: [email-masked]

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" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>; <[email-masked]>
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:[email-masked]]
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.

Date: Wed, 21 Jul 2004 11:02:43 -0400
To: "Manger, James H" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
Sender: [email-masked]

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:         [email-masked] [mailto:[email-masked]]
> > 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:[email-masked]]
> >       Sent:   Thursday, 15 July 2004 6:06 PM
> >       Cc:     [email-masked]
> >
>                 ... the definition of the PI has been changed to allow to 
> use the serialNumber attribute from the subject DN.

Date: Wed, 21 Jul 2004 15:54:27 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Manger, James H" <[email-masked]>
CC: [email-masked]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
Sender: [email-masked]

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:[email-masked]]
> 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.
> 

From: "Admin" <[email-masked]>
To: [email-masked]
Subject: Staff Bulletin
Date: Wed, 21 Jul 04 14:26:00 GMT

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

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
From: "Manger, James H" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
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.

Date: Tue, 20 Jul 2004 19:00:55 -0500
To: "Ietf-pkix" <[email-masked]>
From: "Wpolk" <[email-masked]>
Subject: Re:
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-15.txt
Date: Tue, 20 Jul 2004 16:21:07 -0400
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sim-03.txt
Date: Tue, 20 Jul 2004 16:20:41 -0400
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 20 Jul 2004 09:43:08 -0700
From: Ed Gerck <[email-masked]>
To: Joseph Doekbrijder <[email-masked]>
CC: Christine Karman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Request: Send me signed messages
Sender: [email-masked]

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

Date: Tue, 20 Jul 2004 09:32:24 -0700
From: Ed Gerck <[email-masked]>
To: Al Arsenault <[email-masked]>
CC: Christine Karman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Request: Send me signed messages
Sender: [email-masked]

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).

Date: Tue, 20 Jul 2004 09:39:36 -0600
To: "Ietf-pkix" <[email-masked]>
From: "Anders.rundgren" <[email-masked]>
Subject: Re:
Sender: [email-masked]

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

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

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

Date: Tue, 20 Jul 2004 16:02:33 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-10.txt
Sender: [email-masked]

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

Date: Tue, 20 Jul 2004 16:00:49 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Manger, James H" <[email-masked]>
CC: [email-masked]
Subject: Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
Sender: [email-masked]

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: 	[email-masked] [mailto:[email-masked]] 
>>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:[email-masked]] 
>>	Sent:	Thursday, 15 July 2004 6:06 PM
>>	Cc:	[email-masked]
>>
> 
> 		... the definition of the PI has been changed to allow to use the serialNumber attribute from the subject DN.
> 
> 

Content-class: urn:content-classes:message
Subject: RE: Request: Send me signed messages
Date: Tue, 20 Jul 2004 09:35:31 -0400
From: "Fisher, James L." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Joseph Doekbrijder
Sent: Tuesday, July 20, 2004 5:49 AM
To: Ed Gerck
Cc: Christine Karman; [email-masked]; [email-masked]
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"

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

From: "Al Arsenault" <[email-masked]>
To: "Ed Gerck" <[email-masked]>, "Christine Karman" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Request: Send me signed messages
Date: Tue, 20 Jul 2004 07:22:31 -0400
Importance: Normal
Sender: [email-masked]

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ed Gerck
> Sent: Monday, July 19, 2004 8:26 PM
> To: Christine Karman
> Cc: [email-masked]; [email-masked]
> 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

Date: Tue, 20 Jul 2004 11:48:58 +0200
From: Joseph Doekbrijder <[email-masked]>
Organization: SwissSign AG
To: Ed Gerck <[email-masked]>
CC: Christine Karman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Request: Send me signed messages
Sender: [email-masked]

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: +41 43 344 88 11 / Mobile: +41 79 211 24 46
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

--------------ms080600090600050304000002--

Date: Tue, 20 Jul 2004 16:43:53 +0900
From: Hisanori Mishima <[email-masked]>
Organization: Systems Development Lab., Hitachi, Ltd., Japan
To: [email-masked]
Subject: Asia PKI Interoperability Guideline v1.0
Sender: [email-masked]

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

[email-masked]

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

Tel:+81-44-549-1266
Fax:+81-44-549-1382

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

Date: Mon, 19 Jul 2004 17:26:02 -0700
From: Ed Gerck <[email-masked]>
To: Christine Karman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Request: Send me signed messages
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: RE: PI: 10: single serialNumber attribute
Date: Tue, 20 Jul 2004 10:05:59 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
> 	Sent:	Monday, 19 July 2004 7:52 PM
> 	To:	Manger, James H; [email-masked]
> 
> 	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.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ldap-ac-schema-01.txt
Date: Mon, 19 Jul 2004 15:58:59 -0400
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Reply-To: <[email-masked]>
From: "Scott Harris" <[email-masked]>
To: "'Joseph Doekbrijder'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Request: Send me signed messages
Date: Mon, 19 Jul 2004 10:47:40 -0500
Organization: XRamp Technologies, Inc.
Sender: [email-masked]

Date: Mon, 19 Jul 2004 15:19:57 +0200
To: [email-masked], [email-masked]
From: Christine Karman <[email-masked]>
Subject: Re: Request: Send me signed messages
Sender: [email-masked]

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"

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

Date: Mon, 19 Jul 2004 08:13:28 -0500
From: "Timothy J. Miller" <[email-masked]>
To: Christine Karman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Request: Send me signed messages
Sender: [email-masked]

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

Date: Mon, 19 Jul 2004 12:51:33 +0200
To: [email-masked], [email-masked]
From: Christine Karman <[email-masked]>
Subject: Re: Request: Send me signed messages
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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"

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

From: "Anders Rundgren" <[email-masked]>
To: "Manger, James H" <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-pkix-pi-10.txt - single serialNumber attribute
Date: Mon, 19 Jul 2004 11:52:12 +0200
Sender: [email-masked]

>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

Date: Mon, 19 Jul 2004 11:20:07 +0200
From: Joseph Doekbrijder <[email-masked]>
Organization: SwissSign AG
To: Stephen Kent <[email-masked]>
CC: Ed Gerck <[email-masked]>, [email-masked]
Subject: Re: Request: Send me signed messages
Sender: [email-masked]

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: +41 43 344 88 11 / Mobile: +41 79 211 24 46
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

--------------ms080902030006090102000008--

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
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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: 	[email-masked] [mailto:[email-masked]] 
> 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:[email-masked]] 
> 	Sent:	Thursday, 15 July 2004 6:06 PM
> 	Cc:	[email-masked]
> 
		... the definition of the PI has been changed to allow to use the serialNumber attribute from the subject DN.

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: "David Kemp" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-10.txt
Date: Sun, 18 Jul 2004 10:42:35 +0200
Sender: [email-masked]

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.

From: "Michael Myers" <[email-masked]>
To: "Tim Polk" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Fri, 16 Jul 2004 16:11:28 -0700
Importance: Normal
Sender: [email-masked]

Tim,

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

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Tim Polk
Sent: Friday, July 16, 2004 7:39 AM
To: Michael Myers; Russ Housley; [email-masked]
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: [email-masked]
>[mailto:[email-masked]]On Behalf Of Russ Housley
>Sent: Wednesday, July 14, 2004 2:10 PM
>To: Michael Myers; Tim Polk; [email-masked]
>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:[email-masked]]
> >Sent: Wednesday, July 14, 2004 12:37 PM
> >To: Michael Myers; Tim Polk; [email-masked]
> >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

Date: Fri, 16 Jul 2004 17:03:11 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Request: Send me signed messages
Cc: [email-masked]
Sender: [email-masked]

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

Steve

Date: Fri, 16 Jul 2004 12:43:14 -0700
From: Ed Gerck <[email-masked]>
To: Peter Hesse <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Request: Send me signed messages
Sender: [email-masked]

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

From: "Peter Hesse" <[email-masked]>
To: "'Ed Gerck'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Request: Send me signed messages
Date: Fri, 16 Jul 2004 15:22:12 -0400
Sender: [email-masked]

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                    [email-masked]     |
| Phone: (703)934-2031         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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ed Gerck
> Sent: Friday, July 16, 2004 2:53 PM
> To: Peter Hesse
> Cc: [email-masked]; [email-masked]
> 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 [email-masked].
> > 
> > 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.
> 

Date: Fri, 16 Jul 2004 11:53:12 -0700
From: Ed Gerck <[email-masked]>
To: Peter Hesse <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Request: Send me signed messages
Sender: [email-masked]

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 [email-masked].
> 
> 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.

Date: Fri, 16 Jul 2004 14:05:06 -0400
To: [email-masked], [email-masked]
From: Tim Polk <[email-masked]>
Subject: forwarding
Cc: Stephen Kent <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Fri, 16 Jul 2004 13:56:33 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: WG Last Call: CertStore
Sender: [email-masked]

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

From: "Peter Hesse" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Request: Send me signed messages
Date: Fri, 16 Jul 2004 12:16:02 -0400
Sender: [email-masked]

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 [email-masked].

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: New I-D on Intl Strings in Certs
Date: Sat, 17 Jul 2004 03:31:20 +1200
Sender: [email-masked]

Steve Hanna <[email-masked]> 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.

Date: Fri, 16 Jul 2004 10:38:54 -0400
To: "Michael Myers" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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: [email-masked]
>[mailto:[email-masked]]On Behalf Of Russ Housley
>Sent: Wednesday, July 14, 2004 2:10 PM
>To: Michael Myers; Tim Polk; [email-masked]
>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:[email-masked]]
> >Sent: Wednesday, July 14, 2004 12:37 PM
> >To: Michael Myers; Tim Polk; [email-masked]
> >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

Date: Fri, 16 Jul 2004 10:29:20 -0400
To: "Michael Myers" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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:[email-masked]]
>Sent: Wednesday, July 14, 2004 12:14 PM
>To: Michael Myers; Tim Polk; [email-masked]
>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: [email-masked]
> >[mailto:[email-masked]]On Behalf Of Tim Polk
> >Sent: Wednesday, July 14, 2004 6:50 AM
> >To: Russ Housley; [email-masked]
> >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
> > >
> > >
> > >
> > >

From: "Kenji URUSHIMA" <[email-masked]>
To: <[email-masked]>
Subject: Announce: Challenge PKI Test Suite 2.0 available
Date: Fri, 16 Jul 2004 10:23:05 +0900
Sender: [email-masked]

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.)

From: "Michael Myers" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Thu, 15 Jul 2004 15:14:03 -0700
Importance: Normal
Sender: [email-masked]

Russ,

Seems a matter for San Diego at this point.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
Sent: Wednesday, July 14, 2004 2:10 PM
To: Michael Myers; Tim Polk; [email-masked]
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:[email-masked]]
>Sent: Wednesday, July 14, 2004 12:37 PM
>To: Michael Myers; Tim Polk; [email-masked]
>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

Date: Thu, 15 Jul 2004 11:45:40 -0400
To: "Manger, James H" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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.

Subject: RE: I-D ACTION:draft-ietf-pkix-pi-10.txt
content-class: urn:content-classes:message
Date: Thu, 15 Jul 2004 12:06:47 +0200
From: "Pinkava Jaroslav" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Thursday, July 15, 2004 10:06 AM
Cc: [email-masked]
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 
> [email-masked] 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:
> 	[email-masked].
> 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.

Date: Thu, 15 Jul 2004 10:05:47 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-10.txt
Sender: [email-masked]

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 
> [email-masked] 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:
> 	[email-masked].
> 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.

content-class: urn:content-classes:message
Subject: RE: Unsigned DPD responses for SCVP15
Date: Thu, 15 Jul 2004 15:22:52 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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.

Date: Wed, 14 Jul 2004 17:10:28 -0400
To: "Michael Myers" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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:[email-masked]]
>Sent: Wednesday, July 14, 2004 12:37 PM
>To: Michael Myers; Tim Polk; [email-masked]
>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

From: "Michael Myers" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Wed, 14 Jul 2004 13:03:33 -0700
Importance: Normal
Sender: [email-masked]

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:[email-masked]]
Sent: Wednesday, July 14, 2004 12:37 PM
To: Michael Myers; Tim Polk; [email-masked]
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

Date: Wed, 14 Jul 2004 15:37:27 -0400
To: "Michael Myers" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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:[email-masked]]
>Sent: Wednesday, July 14, 2004 12:14 PM
>To: Michael Myers; Tim Polk; [email-masked]
>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: [email-masked]
> >[mailto:[email-masked]]On Behalf Of Tim Polk
> >Sent: Wednesday, July 14, 2004 6:50 AM
> >To: Russ Housley; [email-masked]
> >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
> > >
> > >
> > >
> > >

From: "Michael Myers" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Wed, 14 Jul 2004 12:31:54 -0700
Importance: Normal
Sender: [email-masked]

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:[email-masked]]
Sent: Wednesday, July 14, 2004 12:14 PM
To: Michael Myers; Tim Polk; [email-masked]
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: [email-masked]
>[mailto:[email-masked]]On Behalf Of Tim Polk
>Sent: Wednesday, July 14, 2004 6:50 AM
>To: Russ Housley; [email-masked]
>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

Date: Wed, 14 Jul 2004 12:14:32 -0700
From: "Terry Hayes" <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
To: "Michael Myers" <[email-masked]>, "Tim Polk" <[email-masked]>, "Russ Housley" <[email-masked]>, [email-masked]
Organization: AOL
Sender: [email-masked]

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:[email-masked]] 
> Sent: Wednesday, July 14, 2004 11:18 AM 
> To: Michael Myers; Russ Housley; [email-masked] 
> 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: [email-masked] 
> >[mailto:[email-masked]]On Behalf Of Tim Polk 
> >Sent: Wednesday, July 14, 2004 6:50 AM 
> >To: Russ Housley; [email-masked] 
> >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 
> > > 
> > > 
> > > 
> > > 

Date: Wed, 14 Jul 2004 15:13:51 -0400
To: "Michael Myers" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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: [email-masked]
>[mailto:[email-masked]]On Behalf Of Tim Polk
>Sent: Wednesday, July 14, 2004 6:50 AM
>To: Russ Housley; [email-masked]
>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
> >
> >
> >
> >

From: "Michael Myers" <[email-masked]>
To: "Tim Polk" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Wed, 14 Jul 2004 11:57:23 -0700
Importance: Normal
Sender: [email-masked]

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:[email-masked]]
Sent: Wednesday, July 14, 2004 11:18 AM
To: Michael Myers; Russ Housley; [email-masked]
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: [email-masked]
>[mailto:[email-masked]]On Behalf Of Tim Polk
>Sent: Wednesday, July 14, 2004 6:50 AM
>To: Russ Housley; [email-masked]
>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

Date: Wed, 14 Jul 2004 14:17:44 -0400
To: "Michael Myers" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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: [email-masked]
>[mailto:[email-masked]]On Behalf Of Tim Polk
>Sent: Wednesday, July 14, 2004 6:50 AM
>To: Russ Housley; [email-masked]
>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
> >
> >
> >
> >

From: "Michael Myers" <[email-masked]>
To: "Tim Polk" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Wed, 14 Jul 2004 09:16:55 -0700
Importance: Normal
Sender: [email-masked]

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

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Tim Polk
Sent: Wednesday, July 14, 2004 6:50 AM
To: Russ Housley; [email-masked]
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
>
>
>
>

From: "Michael Myers" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Wed, 14 Jul 2004 08:35:54 -0700
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
Sent: Wednesday, July 14, 2004 7:02 AM
To: Michael Myers; [email-masked]
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

Content-class: urn:content-classes:message
Subject: RE: Unsigned DPD responses for SCVP15
Date: Wed, 14 Jul 2004 10:23:17 -0400
From: "Dave Engberg" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Tim Polk
Sent: Wednesday, July 14, 2004 9:50 AM
To: Russ Housley; [email-masked]
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"

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

Date: Wed, 14 Jul 2004 10:02:01 -0400
To: "Michael Myers" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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:[email-masked]]
>Sent: Tuesday, July 13, 2004 1:54 PM
>To: Michael Myers; [email-masked]
>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

Date: Wed, 14 Jul 2004 09:50:28 -0400
To: Russ Housley <[email-masked]>, [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 16:31:52 -0700
Importance: Normal
Sender: [email-masked]

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

Date: Tue, 13 Jul 2004 09:10:54 -0400
To: "Michael Myers" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Cc: <[email-masked]>
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 14:47:37 -0700
Importance: Normal
Sender: [email-masked]

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:[email-masked]]
Sent: Tuesday, July 13, 2004 1:54 PM
To: Michael Myers; [email-masked]
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

Date: Tue, 13 Jul 2004 16:53:30 -0400
To: "Michael Myers" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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: [email-masked]
>[mailto:[email-masked]]On Behalf Of Russ Housley
>Sent: Tuesday, July 13, 2004 9:39 AM
>To: [email-masked]
>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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-pi-10.txt
Date: Tue, 13 Jul 2004 16:04:46 -0400
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Michael Myers" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 11:56:06 -0700
Importance: Normal
Sender: [email-masked]

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:[email-masked]]
Sent: Tuesday, July 13, 2004 11:29 AM
To: Michael Myers; [email-masked]
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:[email-masked]]
* Sent: Tuesday, July 13, 2004 10:26 AM
* To: Trevor Freeman; [email-masked]
* 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

Content-class: urn:content-classes:message
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 11:28:46 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
* Sent: Tuesday, July 13, 2004 10:26 AM
* To: Trevor Freeman; [email-masked]
* 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:[email-masked]]
* Sent: Tuesday, July 13, 2004 10:06 AM
* To: Michael Myers; [email-masked]
* 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:[email-masked]]
* * Sent: Monday, July 12, 2004 6:58 PM
* * To: Trevor Freeman; [email-masked]
* * 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
* *
* *
* 
* 
* 

From: "Michael Myers" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 10:38:27 -0700
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
Sent: Tuesday, July 13, 2004 9:39 AM
To: [email-masked]
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

From: "Michael Myers" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 10:25:39 -0700
Importance: Normal
Sender: [email-masked]

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:[email-masked]]
Sent: Tuesday, July 13, 2004 10:06 AM
To: Michael Myers; [email-masked]
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:[email-masked]]
* Sent: Monday, July 12, 2004 6:58 PM
* To: Trevor Freeman; [email-masked]
* 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
*
*

Content-class: urn:content-classes:message
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 10:05:58 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
* Sent: Monday, July 12, 2004 6:58 PM
* To: Trevor Freeman; [email-masked]
* 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
* 
* 

Date: Tue, 13 Jul 2004 12:38:56 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Tue, 13 Jul 2004 09:06:46 -0700
Importance: Normal
Sender: [email-masked]

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

Date: Tue, 13 Jul 2004 08:52:43 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: [email-masked]
Subject: Re: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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

Date: Mon, 12 Jul 2004 22:49:13 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: [email-masked]
Subject: Re: Unsigned DPD responses for SCVP15
Sender: [email-masked]

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
> 

From: "Michael Myers" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Mon, 12 Jul 2004 18:57:43 -0700
Importance: Normal
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: Unsigned DPD responses for SCVP15
Date: Mon, 12 Jul 2004 18:11:13 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
* Sent: Monday, July 12, 2004 5:55 PM
* To: Trevor Freeman; [email-masked]
* 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: [email-masked]
* [mailto:[email-masked]]On Behalf Of Trevor Freeman
* Sent: Monday, July 12, 2004 5:10 PM
* To: [email-masked]
* 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
* 

From: "Michael Myers" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, <[email-masked]>
Subject: RE: Unsigned DPD responses for SCVP15
Date: Mon, 12 Jul 2004 17:55:18 -0700
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Trevor Freeman
Sent: Monday, July 12, 2004 5:10 PM
To: [email-masked]
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

Content-class: urn:content-classes:message
Subject: Unsigned DPD responses for SCVP15
Date: Mon, 12 Jul 2004 17:09:34 -0700
From: "Trevor Freeman" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: OCSP in IKEv2
Date: Mon, 12 Jul 2004 15:22:32 -0700
Importance: Normal
Sender: [email-masked]

All,

Please consider and comment on the following.
Discussions will be held on the IPSEC list.

Michael Myers

-----Original Message-----
From: [email-masked]
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

Date: Mon, 12 Jul 2004 13:29:58 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: New I-D on Intl Strings in Certs
Sender: [email-masked]

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

Date: Mon, 12 Jul 2004 08:39:25 -0400
From: Steve Hanna <[email-masked]>
Subject: New I-D on Intl Strings in Certs
To: [email-masked]
Sender: [email-masked]

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: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

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
[email-masked] 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:
	[email-masked].
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.

Date: Fri, 09 Jul 2004 17:26:18 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: SCVP responses containing only {path, rev-info}
Sender: [email-masked]

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.

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: SCVP responses containing only {path, rev-info}
Date: Fri, 9 Jul 2004 13:40:01 -0700
Importance: Normal
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: SCVP Questions
Date: Fri, 9 Jul 2004 13:21:18 -0400
From: "Seth Hitchings" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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"

------=_NextPart_000_0026_01C465B7.9E1C1E80--

From: "Nick Pope" <[email-masked]>
To: <[email-masked]>
Subject: OASIS Digital Signature Services TC announcement
Date: Fri, 9 Jul 2004 14:33:13 +0100
Importance: Normal
Sender: [email-masked]

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

From: "Admin" <[email-masked]>
To: [email-masked]
Subject: ADV:         Attention All Nonprofit Organizations: Members, Staff and Associates:
Date: Wed, 07 Jul 04 14:34:50 GMT

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

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Cross-certification
Date: Fri, 2 Jul 2004 18:37:25 -0700 
Sender: [email-masked]

> "Alberti Antoine" <[email-masked]> 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. 

From: "Laudon Williams" <[email-masked]>
To: "'Wahaj'" <[email-masked]>, <[email-masked]>
Subject: RE: Difference between a p12 and pfx file
Date: Fri, 2 Jul 2004 07:55:26 -0700
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Wahaj
Sent: Friday, July 02, 2004 3:20 AM
To: [email-masked]
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.  +44 (0)1784 497321
f.  +44 (0)1784 497301

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'> =
[email-masked]
[mailto:[email-masked]] <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> [email-masked]<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; +44 (0)1784 497321<br>
  f.&nbsp; +44 (0)1784 497301</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:[email-masked]"><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: <[email-masked]>

R0lGODlhUQAyAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAAAB
AAEAgAAAAAECAwICRAEAOw==

------=_NextPart_000_0022_01C46009.F051EE90--

From: "Wahaj" <[email-masked]>
To: <[email-masked]>
Subject: Difference between a p12 and pfx file
Date: Fri, 2 Jul 2004 15:19:57 +0500
Sender: [email-masked]

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.  +44 (0)1784 497321
      f.  +44 (0)1784 497301

      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; +44 (0)1784 497301</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:[email-masked]" =
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: <[email-masked]>

R0lGODlhUQAyAHcBMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAEALAAAAAAB
AAEAgAAAAIGBgQICTAEAOw==

------=_NextPart_000_004B_01C46048.091A3200--

Date: Fri, 02 Jul 2004 09:14:44 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Subject: Re: Cross-certification
Sender: [email-masked]

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.

From: "Anders Rundgren" <[email-masked]>
To: "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Subject: Re: Cross-certification
Date: Thu, 1 Jul 2004 22:50:32 +0200
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>
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

Date: Thu, 01 Jul 2004 19:07:38 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Cross-certification
Sender: [email-masked]

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

Date: Thu, 01 Jul 2004 18:47:18 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Cross-certification
Sender: [email-masked]

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.

From: "Anders Rundgren" <[email-masked]>
To: "Alberti Antoine" <[email-masked]>, <[email-masked]>
Subject: Re: Cross-certification
Date: Thu, 1 Jul 2004 15:06:44 +0200
Sender: [email-masked]

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: [email-masked]=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:[email-masked]]
    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:[email-masked]]
      Sent: Wednesday, June 30, 2004 11:16 AM
      To: [email-masked]
      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  : +33 (0)1 47 17 24 37             XFB R&D=20
                Fax : +33 (0)1 47 17 24 25              26 Rue des =
Pavillons=20
                email: [email-masked]               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=[email-masked] =
href=3D"mailto:[email-masked]">Alberti=20
  Antoine</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</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:[email-masked]]<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:[email-masked]]<BR><B>Sent:</B> Wednesday, June 30, =
2004 11:16=20
      AM<BR><B>To:</B> [email-masked]<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; : +33 (0)1 47 17 24 =
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 : +33 (0)1 47 17 24 =
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: [email-masked]</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--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Cross-certification
Date: Fri, 02 Jul 2004 00:02:20 +1200
Sender: [email-masked]

"Alberti Antoine" <[email-masked]> 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.

content-class: urn:content-classes:message
Subject: RE: Cross-certification
Date: Thu, 1 Jul 2004 11:29:45 +0200
From: "Alberti Antoine" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
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:[email-masked]]
Sent: Wednesday, June 30, 2004 11:16 AM
To: [email-masked]
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  : +33 (0)1 47 17 24 37             XFB R&D=20
        Fax : +33 (0)1 47 17 24 25              26 Rue des Pavillons=20
        email: [email-masked]               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:[email-masked]]<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:[email-masked]]<BR><B>Sent:</B> Wednesday, June 30, 2004 =
11:16=20
    AM<BR><B>To:</B> [email-masked]<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; : +33 (0)1 47 17 24 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 : +33 (0)1 47 17 24 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: [email-masked]</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--