ETSI Draft CA Policy Requirements - Comments Requested

["Nick Pope" <[e-mail]>]

Request for comments on draft ETSI standard:
"POLICY REQUIREMENTS FOR CERTIFICATION AUTHORITIES ISSUING PUBLIC KEY
CERTIFICATES"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
standard, which is based on TS 101 456 - Policy requirements for CAs issuing
qualified certificates, but specifies policy requirements for CAs supporting
the broad range of applications of public key certificates.    This includes
certificates used to support electronic signatures, digital signatures,
encryption, key exchange and key agreement mechanisms

COMMENTS ARE REQUESTED BY 14TH SEPTEMBER.  Details of how to obtain a copy
of this document and submit comments are given towards the end of this
message.

The specification presents sets of requirements for different quality
levels, including a “Normalised” level which is similar to that offered by
qualified certificates (as defined in the Electronic Signatures Directive)
conforming to on TS 101 456.

COMMENTS ARE SOUGHT PARTICULARLY ON THE FOLLOWING POINTS:

- A number of requirements have been selected for splitting into
alternatives, according to the different quality levels. Others are the same
for all levels. Selection criteria have been either critical effects of the
sensitivity of the service with regard to cost or/and security. Comments are
asked for about the selection of split requirements.

- Each quality level should represent a consistent set of requirements.
Consistency is related to threats and risks involved with the environment of
the service. Comments based on different business scenarios would help in
order to address wide segments of practical applications with the
requirements.

- Another aspect to consider is the relevance of the selected levels: are
they optimal from a market point of view or other level(s) may be more
useful?

This draft specification is being made publicly available for review and
comment by any company or organisation with interest in this area.  A copy
can be obtained through the ETSI El Sign web site (see below).

BACKGROUND

The development of this standard policy document is one of the tasks the
ETSI Electronic Signature and Infrastructure Working Group is progressing
within the European Electronic Signature Standardisation Initiative (EESSI).
The ETSI El Sign Web-site (see below) provides further information about the
ETSI activities and the EESSI program.

REQUESTED ACTION.

Please send your comments and suggestions not later than 14th September to
the ETSI El Sign e-mail list [e-mail], with copy to the editor
on [e-mail].   Please put "NonQCP" at the front of the Subject field
of all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(STF178Task2Draft.pdf) see:

http://www.etsi.org/sec/el-sign.htm

The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Nick Pope, Security & Standards
Editor - Policy Requirements for CAs issuing public key certificates
[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]





Request for comments on draft ETSI standard:
"POLICY REQUIREMENTS FOR CERTIFICATION AUTHORITIES ISSUING PUBLIC KEY
CERTIFICATES"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
standard, which is based on TS 101 456 - Policy requirements for CAs issuing
qualified certificates, but specifies policy requirements for CAs supporting
the broad range of applications of public key certificates.    This includes
certificates used to support electronic signatures, digital signatures,
encryption, key exchange and key agreement mechanisms

COMMENTS ARE REQUESTED BY 14TH SEPTEMBER.  Details of how to obtain a copy
of this document and submit comments are given towards the end of this
message.

The specification presents sets of requirements for different quality
levels, including a “Normalised” level which is similar to that offered by
qualified certificates (as defined in the Electronic Signatures Directive)
conforming to on TS 101 456.

COMMENTS ARE SOUGHT PARTICULARLY ON THE FOLLOWING POINTS:

- A number of requirements have been selected for splitting into
alternatives, according to the different quality levels. Others are the same
for all levels. Selection criteria have been either critical effects of the
sensitivity of the service with regard to cost or/and security. Comments are
asked for about the selection of split requirements.

- Each quality level should represent a consistent set of requirements.
Consistency is related to threats and risks involved with the environment of
the service. Comments based on different business scenarios would help in
order to address wide segments of practical applications with the
requirements.

- Another aspect to consider is the relevance of the selected levels: are
they optimal from a market point of view or other level(s) may be more
useful?

This draft specification is being made publicly available for review and
comment by any company or organisation with interest in this area.  A copy
can be obtained through the ETSI El Sign web site (see below).

BACKGROUND

The development of this standard policy document is one of the tasks the
ETSI Electronic Signature and Infrastructure Working Group is progressing
within the European Electronic Signature Standardisation Initiative (EESSI).
The ETSI El Sign Web-site (see below) provides further information about the
ETSI activities and the EESSI program.

REQUESTED ACTION.

Please send your comments and suggestions not later than 14th September to
the ETSI El Sign e-mail list [e-mail], with copy to the editor
on [e-mail].   Please put "NonQCP" at the front of the Subject field
of all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(STF178Task2Draft.pdf) see:

http://www.etsi.org/sec/el-sign.htm

The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Nick Pope, Security & Standards
Editor - Policy Requirements for CAs issuing public key certificates
[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6UGxFh07215 for ietf-pkix-bks; Mon, 30 Jul 2001 09:59:15 -0700 (PDT)
Received: from btclick.com (mta01.btfusion.com [62.172.195.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UGxDs07211 for <[e-mail]>; Mon, 30 Jul 2001 09:59:14 -0700 (PDT)
Received: from npwork2 ([213.123.188.84]) by btclick.com (Netscape Messaging Server 4.05) with SMTP id GHAPUL05.O6K for <[e-mail]>; Mon, 30 Jul 2001 17:59:09 +0100 
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>
Subject: ETSI Draft CA Policy Requirements - Comments Requested
Date: Mon, 30 Jul 2001 18:04:02 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Request for comments on draft ETSI standard:
"POLICY REQUIREMENTS FOR CERTIFICATION AUTHORITIES ISSUING PUBLIC KEY
CERTIFICATES"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
standard, which is based on TS 101 456 - Policy requirements for CAs issuing
qualified certificates, but specifies policy requirements for CAs supporting
the broad range of applications of public key certificates.    This includes
certificates used to support electronic signatures, digital signatures,
encryption, key exchange and key agreement mechanisms

COMMENTS ARE REQUESTED BY 14TH SEPTEMBER.  Details of how to obtain a copy
of this document and submit comments are given towards the end of this
message.

The specification presents sets of requirements for different quality
levels, including a “Normalised” level which is similar to that offered by
qualified certificates (as defined in the Electronic Signatures Directive)
conforming to on TS 101 456.

COMMENTS ARE SOUGHT PARTICULARLY ON THE FOLLOWING POINTS:

- A number of requirements have been selected for splitting into
alternatives, according to the different quality levels. Others are the same
for all levels. Selection criteria have been either critical effects of the
sensitivity of the service with regard to cost or/and security. Comments are
asked for about the selection of split requirements.

- Each quality level should represent a consistent set of requirements.
Consistency is related to threats and risks involved with the environment of
the service. Comments based on different business scenarios would help in
order to address wide segments of practical applications with the
requirements.

- Another aspect to consider is the relevance of the selected levels: are
they optimal from a market point of view or other level(s) may be more
useful?

This draft specification is being made publicly available for review and
comment by any company or organisation with interest in this area.  A copy
can be obtained through the ETSI El Sign web site (see below).

BACKGROUND

The development of this standard policy document is one of the tasks the
ETSI Electronic Signature and Infrastructure Working Group is progressing
within the European Electronic Signature Standardisation Initiative (EESSI).
The ETSI El Sign Web-site (see below) provides further information about the
ETSI activities and the EESSI program.

REQUESTED ACTION.

Please send your comments and suggestions not later than 14th September to
the ETSI El Sign e-mail list [e-mail], with copy to the editor
on [e-mail].   Please put "NonQCP" at the front of the Subject field
of all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(STF178Task2Draft.pdf) see:

http://www.etsi.org/sec/el-sign.htm

The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Nick Pope, Security & Standards
Editor - Policy Requirements for CAs issuing public key certificates
[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]





Request for comments on draft ETSI standard:
"POLICY REQUIREMENTS FOR CERTIFICATION AUTHORITIES ISSUING PUBLIC KEY
CERTIFICATES"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
standard, which is based on TS 101 456 - Policy requirements for CAs issuing
qualified certificates, but specifies policy requirements for CAs supporting
the broad range of applications of public key certificates.    This includes
certificates used to support electronic signatures, digital signatures,
encryption, key exchange and key agreement mechanisms

COMMENTS ARE REQUESTED BY 14TH SEPTEMBER.  Details of how to obtain a copy
of this document and submit comments are given towards the end of this
message.

The specification presents sets of requirements for different quality
levels, including a “Normalised” level which is similar to that offered by
qualified certificates (as defined in the Electronic Signatures Directive)
conforming to on TS 101 456.

COMMENTS ARE SOUGHT PARTICULARLY ON THE FOLLOWING POINTS:

- A number of requirements have been selected for splitting into
alternatives, according to the different quality levels. Others are the same
for all levels. Selection criteria have been either critical effects of the
sensitivity of the service with regard to cost or/and security. Comments are
asked for about the selection of split requirements.

- Each quality level should represent a consistent set of requirements.
Consistency is related to threats and risks involved with the environment of
the service. Comments based on different business scenarios would help in
order to address wide segments of practical applications with the
requirements.

- Another aspect to consider is the relevance of the selected levels: are
they optimal from a market point of view or other level(s) may be more
useful?

This draft specification is being made publicly available for review and
comment by any company or organisation with interest in this area.  A copy
can be obtained through the ETSI El Sign web site (see below).

BACKGROUND

The development of this standard policy document is one of the tasks the
ETSI Electronic Signature and Infrastructure Working Group is progressing
within the European Electronic Signature Standardisation Initiative (EESSI).
The ETSI El Sign Web-site (see below) provides further information about the
ETSI activities and the EESSI program.

REQUESTED ACTION.

Please send your comments and suggestions not later than 14th September to
the ETSI El Sign e-mail list [e-mail], with copy to the editor
on [e-mail].   Please put "NonQCP" at the front of the Subject field
of all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(STF178Task2Draft.pdf) see:

http://www.etsi.org/sec/el-sign.htm

The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Nick Pope, Security & Standards
Editor - Policy Requirements for CAs issuing public key certificates
[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6RBNoF13120 for ietf-pkix-bks; Fri, 27 Jul 2001 04:23:50 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RBNns13115 for <[e-mail]>; Fri, 27 Jul 2001 04:23:49 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07700; Fri, 27 Jul 2001 07:22:50 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-00.txt
Date: Fri, 27 Jul 2001 07:22:49 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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 Logotypes in 
                          X.509 certificates
	Author(s)	: S. Santesson
	Filename	: draft-ietf-pkix-logotypes-00.txt
	Pages		: 
	Date		: 26-Jul-01
	
This document contains an initial outline of a standard for inclusion
of logotypes in certificates. The draft includes background
discussions around different aspects of problems and solutions,
forming a starting point for the creation of a complete standard.

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6QEfa215559 for ietf-pkix-bks; Thu, 26 Jul 2001 07:41:36 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QEfXs15555 for <[e-mail]>; Thu, 26 Jul 2001 07:41:34 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA21795 for <[e-mail]>; Thu, 26 Jul 2001 16:41:34 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 26 Jul 2001 16:41:34 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA29175 for <[e-mail]>; Thu, 26 Jul 2001 16:41:32 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA16600 for [e-mail]; Thu, 26 Jul 2001 16:41:32 +0200 (MET DST)
Date: Thu, 26 Jul 2001 16:41:32 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: DPD DPV comparison
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I would like to try a comparison of the various
attempts to make so-called DPV/DPD protocol(s).

- DPV and DPD from Denis Pinkas

  It adds a lot of details about what should be requested and returned. The
  text references a lot of data structures from an ETSI text about electronic
  signature formats. The referenced text has been presented as an informational
  text to the S/MIME group, and does not have received much discussion in the
  S/MIME group. 
  
  The formats contain some ASN1 errors and unmotivated spec, e.g. why 
  default tags EXPLICIT. 

  DPV/DPD uses CMS to secure req/resp data units.

- DVP and DVD strawman from Steve Kent (IETF 50 slides)

  somewhat a pity that this didn't make into a draft.

  It shows *TWO* protocols. 

  An approach of just specifying syntactical elements.
  Although the names of elements in the protocol units seem to
  be self explaining, this may leads obviously to a false discussions
  about elemnts in the syntx and not about the service that carry. 
  
  It uses its own format to secure responses for integrity, similar to
  X.509 certificates. 

- DVP and DVP requirements from Denis Pinkas (50 IETF)

  Approach to define goals is good. There are some minimal goals defined,
  it isn't clear whether there is an agreement on that. not much
  discussion on the PKIX list so far.  
  
- OCSP-v2
  
  OCSP in general is a very general protocol with several layers in the
  requests and responses. The ability of adding almost everything in a three
  layer protocol unit structure by using different oids etc may be tempting
  to use it as a framework for many things.
  
  But: It required changements in the basic definitions of return values to fit
  for DPV and DPD (as far as I remember). 

  OCSP-v2 uses its own format to secure responses for integrity, similar to
  X.509 certificates.   

- SCVP

  This has made several ways: The format of messages has changed several times,
  (remember binary, XML, X509 SIGNED like, PKCS7 ...)

  The mixture of DPV and DPD features seems to complicate the request structures.
 
  SCVP provides a 'service description', this seems to be a good feature,
  in fact this allowed to be implementable in different formats. 
  One might conclude that the most important point in SCVP is the
  the attempt to make a service definition.

  SCVP specifies *TWO* protocols but in a very hidden way.  

  SCVP now uses CMS to secure data units. 

  It includes a small reminder of how a signeddata is filled with 
  unmotivated profiling (e.g., why just one signature or else.)

  Still letf-overs from previous versions and other probably unnecessary text
  (e.g., decription of 'Extension', Signeddata)

- DVCS
  
  This is RFC 3029: I pretend that it handles essential requirements of DPV.
  In mail from 19 january 1999 denis pinkas discussed some requirements for
  signature and certificate validation, it seems that the initial editor
  responded in favour in the sense that they are supported. 
  
  DVCS is pretty simply regarding the possibilities for asking for different
  ways to respond. The only parameter to control the amount of work to be 
  done is the 'policy'. This seems to be sufficient since the number of
  different behaviours seems very limited anyway. 

  The basic approach is that the question to the DVCS server is held as
  simple as possible, basically: Tell what You think about this certificate++
  under the policy xx. (++ means adding some additional hints about chains or else)

  DVCS make no provision for any DPD processing.

  DVCS responses can be validated using DVCS (long term validity).

  DVCS allows several types of relaying the request.

  DVCS used CMS to secure requests and responses.

  DVCS provides for incomplete answers and allows for multiple
  answers to be send asynchronously. 

--- Some observations/conclusions

- It seems to me that the actual debate stated when the first scvp
  definition came out. The document proposed *one* combined
  protocol for DPV and DPD (it doesn't use this terminology).

- There were two earlier protocols that address part of the problem:
  OCSP : *can* be interpreted as some part of DPV processing.
  DVCS: The protocol contained from the very beginning a specification
  for validation of public key certificates. 

- DDV and DPD requirements had been discussed in a very controversal way.
  There are *still*/*more and more* indications that these are *TWO*
  protocols:

  - OCSP-v2 specifies TWO protocols. 
  - The DPV/DPD draft from D.Pinkas specifies two protocols
  - strawman from Steve kent defines two different request/response pairs
  - Some people are saying that features of DPD requirements/protocols
    are either not well understood or not complete (This is my interpretation
    of messages positively filtered by my brain.)
  - some people have asked since years that OCSP is not sufficient, a
    positive assertion protocol was necessary. DCS (nows DVCS was an answer to DPV 
    already years ago). I can claim that RFC 3029 implements the essential
    requirements of DPV, i.e., let DPD *to be done* 

- Most protocols seems to concentrate on validation of certificates of certificates
  used for signatures. 
       
- All protocols use HTTP or HTTPS as underlying transport. It seems that this
  feature can easily folded out. 

  Several protocols use CMS as a container for requests and responses. OCSP-v2 and
  Steve kent's stawaman protocol are exceptions. 
  
  It seems that HTTP, HTTPS and CMS seems to be an appropriate method to transport
  whatever request/response format we need. 

  Requests and responses in an CMS envelope have different OID types.

  Concerning DPV, the protocols that use CMS have slight differences in the
  request and response format. 

- Most response formats are close, it shouldn't be very difficult to
  get a common format. 

- The requests are a little bit more difficult to handle. It is not clear whether
  the flexibility that is provided by some protocols is actually necessary
  to make a DPV. Prtocols Allow for different degrees to provide
  the end certificates, intermediate certs, hints, trust anchors, crls or else.

- A CMS secured response using SignedData has the obvious advantage that it
  can be validated like any other signed document in CMS format, both immediately
  and on long term.  
  
- Requests (and responses) for DPD seem to be still controversal, concerning
  the formats and the security requirements. It could be argued that DPD should
  be simply impemented as some kind of LDAP search and not as yest another 
  layer.  

---

The n-th proposal on how to continue:

  divide and conquer :
  - separate requirements for DPV and DPD.  

    DPV:
    - transport and how to secure it (e.g. HTTP and HTTPS)
	Very little is said about how to find 
        and to authenticate them (before sending a request).
 
    - how to secure a basic data unit (request and response).
        The CMS or ESS profiles seems to need some work if this
        would be the common format.
        reuse of answers in other elements, e.g., use in attributes
        of other signeddata. 
        how to validate the response *now* and mayebe longterm.

    - provide a service definition 
        use some SCVP stuff, transform requirements into services

    - define/take a request/response format.
        - decide on the degree of flexilibity in requests
        - define a structure for the output. 
          - how to include safe time together with the data
          - how to reference parts of other evidences. 

    DPD: I leave this to someone else. 

The ultimate proposal: Just give up and let the W3C do the work. 

I hope that this contribution helps a little bit.

Of course, I can be considered simply as suffering from psychological projection.

And, the comparison is far away from being complete. I am not really motivated to
resume all the different contributions to the issue during the last 4
years, i.e. discussions about OCSP, D(V)CS, SCVP, DPV/DPD etc.


Peter Sylvester
  
  







  
  


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6PDxWt14797 for ietf-pkix-bks; Wed, 25 Jul 2001 06:59:32 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6PDxVs14793 for <[e-mail]>; Wed, 25 Jul 2001 06:59:31 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <PDHZSHRK>; Wed, 25 Jul 2001 09:59:44 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "ietf-pkix@imc. org (E-mail)" <[e-mail]>
Subject: v1.9.2 Certificate Management Library Now Available
Date: Wed, 25 Jul 2001 09:59:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

All,

Getronics Government Solutions has delivered the Version 1.9.2 Certificate
Management Library (CML) for MS Windows, Solaris 2.7 and Linux.  The v1.9.2
CML is freely available to everyone from the Getronics CML web page
<http://www.getronicsgov.com/hot/cml_home.htm>.  The v1.9.2 release fixes
bugs present in the v1.9.1 CML release.  The v1.9.2 CML requires the latest
Enhanced SNACC ASN.1 software release (v1.3 R6 or later) that can be
downloaded from <http://www.getronicsgov.com/hot/snacc_home.htm>.

The v1.9.2 CML is described in the v1.9 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path processing rules and SDN.706.  It meets the majority of
the IETF PKIX RFC 2459 Certificate/CRL Profile requirements.  The CML uses
path building software based on the v2.0 CPDL from CygnaCom Solutions, an
Entrust Technologies company, to provide robust certification path building
capabilities such as using cross certificates. 

The CML has been used to validate X.509 Certificates and Certificate
Revocation Lists (CRL) signed using the Digital Signature Algorithm (DSA)
and RSA.  Further enhancements, ports and testing of the CML are still in
process.  Further releases of the CML will be provided as 
significant capabilities are added. 

The following enhancements are included in the v1.9.2 CML release 
(compared with the v1.9.1 release):

 1. Fixed memory allocation bug in CM_certPolicies.c 
 
 2. Fixed a duplicate session problem in CMU_AddASession() (CM_Mgr.c)
     and in SRLi_AddASession() (SRL_Mgr.c).

 3. Corrected logic on freeing objects, when a free callback function
     was passed in.

 4. Corrected argument to function call CMU_genname2str, when the 
     Distribution Point name refers to a full name. 

 5. Corrected function SRLi_GetAllCertificatesByType() in SRL_ReqOps.c
     which was incorrectly filtering expired certificates.

 6. Removed cpdlib.cpp and cpdlib.c from the CPDL project. The CML 
     instantiating of a CWinApp will crash other MFC applications.

 7. Fixed a compile error in CM_Sigcheck.c when NORSA was defined.

 8. Correct function CMU_genname2str() to copy the DN string when 
     the type is CM_X500_NAME.

 9. Fixed bug in CM_ValidateSignature(), incorrectly referencing 
     the Key Usage Field.


The following v1.9.2 CML files are available from the Getronics CML web
page:
1) Windows_CMLLibv1.9.2.ZIP: MS Windows Dynamically Linked Libraries (DLL) 
2) Windows_CM_Toolv1.9.2.ZIP: CM_Tool executable
3) Solaris_CMLLibv1.9.2.tar.Z: Sun Solaris Libraries 
4) Solaris_CM_Toolv1.9.2.tar.z: CM_Tool for Solaris
5) Linux_CMLLibv1.9.2.tar.Z: Linux Libraries
6) Linux_CM_Toolv1.9.2.tar.z: CM_Tool for Linux
7) CML_sourcev1.9.2.tar.Z: Source, including Windows project files 
8) CMAPI_data.tar.Z: Test Certs and CRLs used to test CML

The v1.9 CML API document (CMv1.9api.doc, CMv1.9api.pdf), v1.9 SRL API 
document (SRLv1.9api.doc, SRLv1.9api.pdf), and v1.9 CML readme file are
also available from the Getronics CML web page.

All source code for the CML is being provided at no cost and with no
financial limitations regarding its use and distribution. Organizations 
can use the CML without paying any royalties or licensing fees.  The CML 
was originally developed by the U.S. Government.  Getronics is enhancing 
and supporting the CML under contract to the U.S. Government.  The U.S.
Government is furnishing the CML software at no cost to the vendor 
Subject to the conditions of the CML Public License provided with the CML 
software.  

The v1.9.2 CML uses the Getronics v1.3 R6 (or later release) Enhanced 
SNACC ASN.1 Library to encode/decode objects.  Getronics has 
successfully tested the v1.9.2 CML with the SNACC and CTIL DLLs delivered
in conjunction with the v1.10 SFL.  Source code for the Getronics-developed
CTILs is available from <http://www.getronicsgov.com/hot/sfl_home.htm>.  
The actual crypto libraries are not provided with the CML or SFL.  They 
must be independently obtained from the appropriate source.  

The CML can be used in conjunction with the v2.0 CPDL to successfully meet
all of the requirements of the Bridge Certification Authority
Demonstration effort which includes cross-certified Entrust, Spyrus and
Motorola v3 certificate domains.  The CML_source.tar.Z file includes the
CPDL
source code and public license.
<http://www.cygnacom.com/products/index.htm>
provides more information regarding the CPDL.

The National Institute of Standards and Technology (NIST) is providing a
standard test suite of X.509 certificate paths
<http://csrc.nist.gov/pki/testing/x509paths.html> that can be used for
testing applications against RFC 2459.  The CML was used to successfully 
process the NIST test data.

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml> and a CML mail list which is used to:
distribute 
information regarding CML releases; discuss CML-related issues; and allow
CML 
users to provide feedback, comments, bug reports, etc.  Subscription
information 
for the imc-cml mailing list is at the IMC web site listed above.  

All comments regarding the CML source code and documents are welcome. 
This CML release announcement was sent to several mail lists, but please 
send all messages regarding the CML to the imc-cml mail list ONLY.  Please
do 
not send messages regarding the CML to any of the IETF mail lists.  We will
respond to all messages sent to the imc-cml mail list.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6OJagJ04747 for ietf-pkix-bks; Tue, 24 Jul 2001 12:36:42 -0700 (PDT)
Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OJafG04742 for <[e-mail]>; Tue, 24 Jul 2001 12:36:41 -0700 (PDT)
Received: from [199.174.219.68] (user-33qtn4l.dialup.mindspring.com [199.174.220.149]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id MAA17406; Tue, 24 Jul 2001 12:35:54 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05100310b78375a5b448@[199.174.219.68]>
Date: Tue, 24 Jul 2001 12:21:04 -0700
To: OSI Directory List <[e-mail]>, "X.509":;
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: Defect resolution for X.509
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hello

New defects, DR 280-282, to X.509/9594-8 has been posted in pdf on 
the server at

 
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_280.pdf

 
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_281.pdf

 
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_282.pdf

The proposed resolutions for these defects have been incorporated 
into a Draft Technical Corrigenda and submitted to ISO/IEC SC6 for 
ballot.

The following URL points to Draft Technical Corrigenda 3 for the 
fourth edition (2000) of X.509/9594-8

 
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/8-DTC3%284th%29.doc

 
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/8-DTC3%284th%29.pdf


The ballot period for a DTC ballot is normally three months. National 
Bodies and Liaison Organizations may submit comments on these DTCs. 
Note that comments cannot come directly from individuals but must 
come as contributions from the organizations themselves.

Unfortunately the ballot will close after our meeting the week of 24 
September. Early ballot comments would allow us to resolve any issues 
with the DTC while we are in the meeting.

    hoyt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6OGqRH00816 for ietf-pkix-bks; Tue, 24 Jul 2001 09:52:27 -0700 (PDT)
Received: from btclick.com (mta02.btfusion.com [62.172.195.247]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OGqFG00802 for <[e-mail]>; Tue, 24 Jul 2001 09:52:25 -0700 (PDT)
Received: from npwork2 ([213.123.188.4]) by btclick.com (Netscape Messaging Server 4.05) with SMTP id GGZLIY03.71J for <[e-mail]>; Tue, 24 Jul 2001 17:52:10 +0100 
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>
Subject: Draft ETSI TS "XML Advanced Electronic Signatures"
Date: Tue, 24 Jul 2001 17:58:00 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Request for comments on draft ETSI standard:
"XML Advanced Electronic Signatures (XAdES)"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
standard which specifies the XML format for Advanced Electronic Signatures
satisfying the requeriments defined in the European Directive
for Electronic Signatures, and with long term validity.

This draft specification is being made publicly available for review and
comment by any company or organisation with interest in this area.  A copy
can be obtained through the ETSI El Sign web site (see below).

Comments are requested by 14th September.

Background

The development of this standard

"XML Advanced Electronic Signatures"

is one of the tasks the ETSI Electronic Signature and Infrastructure Working
Group is progressing within the European Electronic Signature
Standardisation
Initiative (EESSI). The ETSI El Sign Web-site (see below) provides further
information about the ETSI activities and the EESSI program.

REQUESTED ACTION

Please send your comments and suggestions not later than 14 September to the
ETSI El Sign e-mail list [e-mail], with copy to the editor on
[e-mail] .   Please put "ETSI-XAdES" at the front of the Subject
field of all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(STF178Task3Draft.pdf) see:

http://www.etsi.org/sec/el-sign.htm


The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Juan  Carlos Cruellas (Universitat Politecnica de Catalunya)
Editor - XML Advanced Electronic Signatures (XAdES)
[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]



Received: by above.proper.com (8.11.3/8.11.3) id f6OAYE817011 for ietf-pkix-bks; Tue, 24 Jul 2001 03:34:14 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OAYDG17007 for <[e-mail]>; Tue, 24 Jul 2001 03:34:13 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06614; Tue, 24 Jul 2001 06:33:16 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-new-rfc2527-00.txt
Date: Tue, 24 Jul 2001 06:33:15 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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 Certificate 
                          Policy and Certification Practices Framework
	Author(s)	: S. Chokhani et al.
	Filename	: draft-ietf-pkix-ipki-new-rfc2527-00.txt
	Pages		: 54
	Date		: 23-Jul-01
	
This document presents a framework to assist the writers of 
certificate policies or certification practice statements for 
participants within public key infrastructures, such as 
certification authorities, policy authorities, and communities of 
interest that wish to rely on certificates.  In particular, the 
framework provides a comprehensive list of topics that potentially 
(at the writer's discretion) need to be covered in a certificate 
policy or a certification practice statement.  This document is 
being submitted to the RFC Editor with a request for publication as 
an Informational RFC.

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f6OAYA717005 for ietf-pkix-bks; Tue, 24 Jul 2001 03:34:10 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OAY8G17001 for <[e-mail]>; Tue, 24 Jul 2001 03:34:08 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06602; Tue, 24 Jul 2001 06:33:11 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-trans-00.txt
Date: Tue, 24 Jul 2001 06:33:10 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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		: CMC Transport
	Author(s)	: M. Myers et al.
	Filename	: draft-ietf-pkix-cmc-trans-00.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document defines a number of transport mechanisms that are used
to move [CMC] messages.  The transport mechanisms described in this
document are: HTTP, file, mail and TCP.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-trans-00.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f6OAY3716995 for ietf-pkix-bks; Tue, 24 Jul 2001 03:34:03 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OAY2G16991 for <[e-mail]>; Tue, 24 Jul 2001 03:34:02 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06589; Tue, 24 Jul 2001 06:33:04 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-archive-00.txt
Date: Tue, 24 Jul 2001 06:33:04 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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		: CMC Extensions: Server Side Key Generation and Key 
                          Archival
	Author(s)	: J. Schaad
	Filename	: draft-ietf-pkix-cmc-archive-00.txt
	Pages		: 17
	Date		: 23-Jul-01
	
This document defines a set of extensions to [CMC] that address the
desire for having two additional services:  Server generation of
keys, and server-side archival and subsequent recovery of key
material by the server.  These services are provided by the
definition of additional control statements within the CMC
architecture.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-archive-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6OAXwB16988 for ietf-pkix-bks; Tue, 24 Jul 2001 03:33:58 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OAXvG16984 for <[e-mail]>; Tue, 24 Jul 2001 03:33:57 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06577; Tue, 24 Jul 2001 06:32:59 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-compl-00.txt
Date: Tue, 24 Jul 2001 06:32:59 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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		: CMC Compliance Document
	Author(s)	: M. Myers et al.
	Filename	: draft-ietf-pkix-cmc-compl-00.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document provides a set of compliance statements about the CMC
enrollment protocol.  The documents [CMC-STRUCT] and [CMC-TRANS]
provide the definitions of the structure and transport protocols
defined for CMC.  This document provides the information needed to
make a compliant version of CMC.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-compl-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6O7hlk02915 for ietf-pkix-bks; Tue, 24 Jul 2001 00:43:47 -0700 (PDT)
Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6O7hjG02911 for <[e-mail]>; Tue, 24 Jul 2001 00:43:45 -0700 (PDT)
Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id IAA129974 for <[e-mail]>; Tue, 24 Jul 2001 08:24:57 +0100
Received: from d15ml008.nl.ibm.com (d15ml008.nl.ibm.com [9.132.41.68]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6O7hcd38284 for <[e-mail]>; Tue, 24 Jul 2001 08:43:39 +0100
MIME-Version: 1.0
X-MIMETrack: S/MIME Sign by Notes Client on Rob G Weemhoff/Netherlands/IBM(Release 5.0.7 |March 21, 2001) at 23-07-2001 16:29:00, Serialize by Notes Client on Rob G Weemhoff/Netherlands/IBM(Release 5.0.7 |March 21, 2001) at 23-07-2001 16:29:00, Serialize complete at 23-07-2001 16:29:00, S/MIME Sign failed at 23-07-2001 16:29:00: The cryptographic key was not found, Serialize by Router on D15ML008/15/M/IBM(Release 5.0.6 |December 14, 2000) at 24/07/2001 09:43:38, Serialize complete at 24/07/2001 09:43:38
To: [e-mail]
Subject: draft-ietf-pkix-new-part1-08.txt
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
From: "Rob G Weemhoff" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 24 Jul 2001 09:43:36 +0200
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi,

I wonder why this document refers to X.509 (1997) in stead of X.509 
(03/00)


----
Regards,
Ing. Rob G. WEEMHOFF 
Senior Consulting IT-Architect 
IBM Security and Privacy Services (EMEA)
Tel:        [phone] 
Mobile: [phone]

E-mail: [e-mail] 
Fax: [phone]
Computerweg 8
3821 AB  Amersfoort
The Netherlands




Received: by above.proper.com (8.11.3/8.11.3) id f6KEQeB29986 for ietf-pkix-bks; Fri, 20 Jul 2001 07:26:40 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KEQcq29982 for <[e-mail]>; Fri, 20 Jul 2001 07:26:38 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17963; Fri, 20 Jul 2001 10:25:20 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, IANA <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: An Internet Attribute Certificate Profile for Authorization to Proposed Standard
Date: Fri, 20 Jul 2001 10:25:20 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

The IESG has approved An Internet Attribute Certificate Profile for
Authorization <draft-ietf-pkix-ac509prof-09.txt> as a Proposed
Standard.  This document is the product of the Public-Key
Infrastructure (X.509) Working Group.  The IESG contact persons are
Jeffrey Schiller and Marcus Leech.


Technical Summary
 
This document provides a profile for X.509 Attribute Certificates.
Traditionally when we think of X.509 Certificates we envision a
certificate that associate a public key with a name. However attribute
certificates associate a name, not with a public key, but with a set of
attributes.  Attributes might be used for authorization and generic
business purposes.  Whereas a binding between a key and a name (which is
provided for in a "normal" certificate) may last for a long time,
attributes may be associated with a name for a short (or long) time. A
person may also have several different attribute certificates, each for
an appropriate process or situation.

Working Group Summary

The working group came to consensus on this document.

Protocol Quality

These documents were reviewed by Jeffrey I. Schiller for the IESG.


Received: by above.proper.com (8.11.3/8.11.3) id f6K9cNv19153 for ietf-pkix-bks; Fri, 20 Jul 2001 02:38:23 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K9cLq19149 for <[e-mail]>; Fri, 20 Jul 2001 02:38:22 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06486; Fri, 20 Jul 2001 05:37:24 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-06.txt
Date: Fri, 20 Jul 2001 05:37:23 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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, P. Hoffman, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-scvp-06.txt
	Pages		: 
	Date		: 19-Jul-01
	
The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about the
certificate, such as whether or not the certificate is valid, a chain
to a trusted root, and so on. SCVP has many purposes, including
simplifying client implementations and allowing companies to centralize
their trust and policy managment.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-06.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f6JB75T07277 for ietf-pkix-bks; Thu, 19 Jul 2001 04:07:05 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JB74q07273 for <[e-mail]>; Thu, 19 Jul 2001 04:07:04 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28475; Thu, 19 Jul 2001 07:06:08 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc2797-bis-01.txt
Date: Thu, 19 Jul 2001 07:06:08 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

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

	Title		: Certificate Management Messages over CMS
	Author(s)	: M. Myers, X. Liu, J. Schaad, J. Weinstein
	Filename	: draft-ietf-pkix-rfc2797-bis-01.txt
	Pages		: 
	Date		: 18-Jul-01
	
This document defines a Certificate Management protocol using CMS
(CMC).  This protocol addresses two immediate needs within the
Internet PKI community:
1. The need for an interface to public key certification products
and    services based on [CMS] and [PKCS10], and
2. The need in [SMIMEV3] for a certificate enrollment protocol for
DSA-signed certificates with Diffie-Hellman public keys.

   A small number of additional services are defined to supplement the
   core certificate request service.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc2797-bis-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6HKxrN13915 for ietf-pkix-bks; Tue, 17 Jul 2001 13:59:53 -0700 (PDT)
Received: from btclick.com (mta01.btfusion.com [62.172.195.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HKxkq13909 for <[e-mail]>; Tue, 17 Jul 2001 13:59:46 -0700 (PDT)
Received: from NPVAIOLAPTOP ([213.121.96.167]) by btclick.com (Netscape Messaging Server 4.05) with ESMTP id GGMYBI01.D04; Tue, 17 Jul 2001 21:59:42 +0100 
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>
Subject: ETSI Draft Time-stamping Policy - comments requested
Date: Tue, 17 Jul 2001 21:56:04 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Request for comments on draft ETSI standard:
"POLICY REQUIREMENTS FOR TIME-STAMPING AUTHORITIES"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
standard which specifies policy requirements on the operation and management
practices of Time-Stamping Authorities such that subscribers and relying
parties may have confidence in the operation of its time-stamp services.

This draft specification is being made publicly available for review and
comment by any company or organisation with interest in this area.  A copy
can be obtained through the ETSI El Sign web site (see below).

Comments are requested by 7th September.

Background

The development of this standard policy document is one of the tasks the
ETSI Electronic Signature and Infrastructure Working Group is progressing
within the European Electronic Signature Standardisation Initiative (EESSI).
The ETSI El Sign Web-site (see below) provides further information about the
ETSI activities and the EESSI program.

Requested action.

Please send your comments and suggestions not later than 15 September to the
ETSI El Sign e-mail list [e-mail], with copy to the editor on
[e-mail].   Please put "TSA-Pol" at the front of the Subject field
of
all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(STF178Task1Draft.pdf) see:

http://www.etsi.org/sec/el-sign.htm

The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Nick Pope, Security & Standards
Editor - Policy Requirements for Time-stamping Authorities
[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6GLQQ927094 for ietf-pkix-bks; Mon, 16 Jul 2001 14:26:26 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6GLQOq27090 for <[e-mail]>; Mon, 16 Jul 2001 14:26:24 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Jul 2001 21:24:51 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA05201 for <[e-mail]>; Mon, 16 Jul 2001 17:26:26 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TR73P>; Mon, 16 Jul 2001 17:26:22 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TR73K; Mon, 16 Jul 2001 17:26:17 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 16 Jul 2001 14:59:27 -0400
Subject: RE: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new-part1-08.txt)
In-Reply-To: <20010712222808.RHVV3707.mtiwmhc24.worldnet.att.net@webmail .worldnet.att.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Todd:

In my mind, such a protocol, if needed at all, would not be part of the 
certificate and CRL profile.

Russ


At 10:28 PM 7/12/2001 +0000, [e-mail] wrote:

>Graham -
>To the last comment you made - We need to build "the OID
>discovery and authentication protocol".
>
>This will allow policy and policy-centric events to be
>included dynamically and authenticated inline. This in my
>mind is a key missing piece of Son Of...
>
>T.
>
>--
>Regards,
>Todd
> >
> > Todd,
> >
> > Yes I agree in a totally closed environment, between mutually agreeing
> > parties there is no need to register OIDs.  But why avoid the registration,
> > it only has to be done once to establish an arc, it does not need doing for
> > each OID which is allocated in a closed environment.
> >
> > I cannot see how an application can be coded to handle OID collisions for a
> > lower cost than the effort involved in the registration.
> >
> > Lastly how does an application handle two extensions in a certificate with
> > the same identifier (OID) but having separate meanings when there is no way
> > of telling them apart.
> >
> > Graham Bland
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > Sent: 11 July 2001 15:20
> > > To: Housley, Russ
> > > Cc: [e-mail]
> > > Subject: Re: New draft of son-of-2459 (Was: I-D
> > > ACTION:draft-ietf-pkix-new-part1-08.txt)
> > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Todd
> > > > Todd:
> > > >
> > > > No.
> > >
> > > Yes!
> > >
> > > >
> > > > The process of obtaining an OID must ensure that the same
> > > OID is not used
> > > > for two different extensions.  If this where to happen,
> > > then a replying
> > > > party could not know which syntax or semantics to apply to
> > > the extension in
> > > > a particular certificate.
> > >
> > > And this could easily be done by an agreement by two
> > > individuals or the code
> > > they are running at either end of the transaction. Or more importantly
> > > by the apps being run at both ends.
> > >
> > > >
> > > > I never said that the registration process had to lead to
> > > publication of
> > > > the OID, the associated syntax, or the associated
> > > semantics.  I did say,
> > > > and remain adamant, that OID use collisions must be avoided.
> > >
> > > No again - what needs to happen is that the App must be coded
> > > to deal with
> > > OID collisions not the protocol.
> > > But that's the whole point. The registration process is
> > > only necessary if the Use Model requires an external
> > > "lookup step"... What if the OID itself carries
> > > privacy protected information? As a CERT extension
> > > this is actually a real potential and mandating that it be
> > > a public process has some strange implications for limiting
> > > the scope of "Son Of..."
> > >
> > > Look - If the app that is using the cert has
> > > the OID constructs it uses hard coded into it then... no
> > > public registration
> > > is needed.
> > >
> > >
> > > >
> > > > Russ
> > > >
> > > > At 11:29 PM 7/10/2001 +0000, [e-mail] wrote:
> > > > >Russ I am aware of OID registration, I have several PEN
> > > > >OIDs myself.
> > > > >
> > > > >The point is that if
> > > > >
> > > > >1)  this is an OID that is only used within a closed
> > > > >environment there is no need to keep anyone else from
> > > > >using it.
> > > > >
> > > > >2)  If you are referring to a process for propagating an
> > > > >OID so that both users could have the same definition on
> > > > >the OID they are using, then that is a good idea but
> > > > >that is not per se "registration".
> > > > >
> > > > >So I disagree with your commentary and pushback. What I
> > > > >feel you are referring to is an arbitrary need
> > > > >to "register all OIDs" as in with the IANA rather than a
> > > > >method of OID content negotiation and IMHO I will
> > > > >continue to disagree with your commentary.
> > > > >
> > > > >--
> > > > >Regards,
> > > > >Todd
> > > > > >
> > > > > > Todd:
> > > > > >
> > > > > > The point is that a unique OID must be used.
> > > > >
> > > > >Not true. If I have an OID and it is a private
> > > > >system I can do whatever I want with that OID.
> > > > >I do not need IANA or anyone else besides my
> > > > >private use partners to tell me what the OID means.
> > > > >
> > > > > > Registration is the process
> > > > > > used to obtain the unique OID, even if the resulting
> > > OID is not published
> > > > > > in any public manner.
> > > > > >
> > > > > > Russ
> > > > > >
> > > > > >
> > > > > > At 03:16 PM 7/10/2001 +0000, [e-mail] wrote:
> > > > > >
> > > > > > >Two points - the first is the pushback on the
> > > > > > >work "methods". I believe that the term "features" is
> > > > > > >better here, and to the second question... if the
> > > > > > >methods are private why is there any need to register
> > > > > > >them. The only need I can see in issuing a publicly
> > > > > > >available OID is if there are publicly linked
> > > > > > >participants of unknow origins and as such would need
> > > > > > >some way of registering these "OID's" locally.
> > > > > > >
> > > > > > >T.
> > > > > > >--
> > > > > > >Regards,
> > > > > > >Todd
> > > > > > > >
> > > > > > > > "4.2  Certificate Extensions
> > > > > > > >
> > > > > > > >    The extensions defined for X.509 v3 certificates
> > > provide methods for
> > > > > > > >    associating additional attributes with users or
> > > public keys and for
> > > > > > > >    managing the certification hierarchy.  The X.509
> > > v3 certificate
> > > > > > > >    format also allows communities to define private
> > > extensions to carry
> > > > > > > >    information unique to those communities."
> > > > > > > >
> > > > > > > > Then there is a section Private Internet Extesions
> > > where two specific
> > > > > > > > extension are specified.  I assume that this is the
> > > same as the private
> > > > > > > > extensions mentioned above.
> > > > > > > >
> > > > > > > > Question: How are arbitrary private extensions
> > > supposed to be added?
> > > > > > > > You must register/define an OID?
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > Anders R
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > >
> > _______________________________________________________________________
> >
> > This message is confidential and is intended for the addressee only;
> > unless clearly stated that this disclaimer should not apply, this
> > e-mail is not intended to create legally binding commitments on
> > behalf of any company in the British Interactive Broadcasting
> > Holdings Limited group,  nor do its contents reflect the corporate
> > views or policies of any such company. Any unauthorised disclosure,
> > use or dissemination, either whole or partial, is prohibited. If you
> > are not the intended recipient of the message, please notify the
> > sender immediately.
> > _______________________________________________________________________


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6GH0Tv20944 for ietf-pkix-bks; Mon, 16 Jul 2001 10:00:29 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GH0Qq20940 for <[e-mail]>; Mon, 16 Jul 2001 10:00:27 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA22760; Mon, 16 Jul 2001 19:00:21 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 16 Jul 2001 19:00:21 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA17342; Mon, 16 Jul 2001 19:00:20 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA12822; Mon, 16 Jul 2001 19:00:20 +0200 (MET DST)
Date: Mon, 16 Jul 2001 19:00:20 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: New draft of son-of-2459
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

ooups, that was not intende for the list, no harm was intended
in case that someone could misinterprete this. 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6GGCwP19902 for ietf-pkix-bks; Mon, 16 Jul 2001 09:12:58 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GGCtq19898 for <[e-mail]>; Mon, 16 Jul 2001 09:12:55 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA22330; Mon, 16 Jul 2001 18:12:37 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 16 Jul 2001 18:12:37 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA16981; Mon, 16 Jul 2001 18:12:35 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA12808; Mon, 16 Jul 2001 18:12:35 +0200 (MET DST)
Date: Mon, 16 Jul 2001 18:12:35 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: New draft of son-of-2459
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

It sounds that there is a misunderstanding about 
what can  'OID negociation protocol'. There is nothing
in a OID to negotiate. An OID is just "a sequence of number which are
organised in a hierachical way." One might think about 'negociation of
some features and using OIDs to name them", but this is not a
PKIX work item as far as I know. 

-- 

OTOH,  I may have a need for such a mechanism, in order to get the 
"Simple Protocol" working.

It consists of exchanging a SP-request and retrieving and SP-response. 
The actual encoding can be in several forms, in BER/DER, XML, lisp-style, 
rfc2822 style.

In ASN1 the specification of both SP-request an SP-response is

  SEQUENCE of Extensions

the other encodings are TBD.

The detection of the encoding uses the following heuristics on the first character:

ASN1  : "0"   "c'est nul"
XML   : "<"   inferiour
LISP  : '('   always some additional remark
RFC   : 'A-Z' blabla, in the beginning there was the word.

can this protocol use an OID negociation protocol in order to 
specify the 'semantics' of the Extensions.

Ooups, wrong date. /6° ON A FRENCH KEYBOARD


> 
> Steve -
> you are wrong. An OID negotiation protocol would allow the use of the certs
> and their extensions without the third party lookup process, and it for a
> number of more autonomic uses of PKI it does make sense.
> 
> OIDs can be infinitely more useful than they have been to date, but not
> without some better negotiations processes. Here is the obvious place to
> start that.
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6GE5UZ12956 for ietf-pkix-bks; Mon, 16 Jul 2001 07:05:30 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GE5Sq12951 for <[e-mail]>; Mon, 16 Jul 2001 07:05:28 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22016; Mon, 16 Jul 2001 10:07:14 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010403b778a54ffc6d@[128.33.84.34]>
In-Reply-To: <006901c10b48$936dc500$020aff0c@tsg1>
References:  <[e-mail].n et> <p05010401b772240e7d74@[128.33.84.34]> <006901c10b48$936dc500$020aff0c@tsg1>
Date: Mon, 16 Jul 2001 10:08:06 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: New draft of son-of-2459
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 8:02 PM -0700 7/12/01, todd glassey wrote:
>Steve -
>you are wrong. An OID negotiation protocol would allow the use of the certs
>and their extensions without the third party lookup process, and it for a
>number of more autonomic uses of PKI it does make sense.
>
>OIDs can be infinitely more useful than they have been to date, but not
>without some better negotiations processes. Here is the obvious place to
>start that.
>
>Todd

Rodd,

What I said was that we are not going to consider changing the OID 
model based on your suggestions.  Relative to that comment, I am 
right :-).

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6FNkMm02908 for ietf-pkix-bks; Sun, 15 Jul 2001 16:46:22 -0700 (PDT)
Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6FNkLq02904 for <[e-mail]>; Sun, 15 Jul 2001 16:46:21 -0700 (PDT)
Received: from [63.29.42.249] (1Cust249.tnt2.ashland.or.da.uu.net [63.29.42.249]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id QAA16896; Sun, 15 Jul 2001 16:45:26 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <a05100301b777d47f6308@[209.179.157.38]>
Date: Sun, 15 Jul 2001 16:25:13 -0700
To: "X.509":;, IETF LDAP <[e-mail]>
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: announcement of X.500 meeting 24-28 September in Flagstaff Arizona
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

There will be a meeting on X500 in Flagstaff Arizona the week of 24 September.

Details on the agenda and the venue can be found in both word and pdf at

   ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/announcement.doc

   ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/announcement.pdf


        hoyt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6E4HmA19369 for ietf-pkix-bks; Fri, 13 Jul 2001 21:17:48 -0700 (PDT)
Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6E4Hjq19359 for <[e-mail]>; Fri, 13 Jul 2001 21:17:45 -0700 (PDT)
Received: from sweepau.baltimore.com.au (sweepau.jp.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA05650 for <[e-mail]>; Sat, 14 Jul 2001 14:28:57 +1000
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Sat, 14 Jul 2001 14:18:18 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <3L00TZ5S>; Sat, 14 Jul 2001 14:15:21 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Denis Pinkas <[e-mail]>, pkix <[e-mail]>
Subject: RE: DPV and DPD
Date: Sat, 14 Jul 2001 14:15:21 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis,

<<To sweeten up your vacations>> I've given the document a very quick read
through. Just the DPV part of it to start with.
And of course I'm avoiding any comments about the motivations and politics
matters, at that stage.

P1. [3]. "A trust ancor is defined.. " The sentence is unclear. Cannot even
think of suggesting something else.
P3. [5]. Validation time is missing in the Request data list (though present
in DPVRequest).
P3 or 4. [5] is followed by [5.2]. Where is [5.1]?

ValPolicyRef. Suggest making valPolicyHash optional. ( Yes, I know where it
comes from and I remember the discussion on ETSI list. Never liked it. )

P7. [5.2.2] DPVResponse. pathReferences must be explicitely tagged. Both
tbsResponse and pathReferences are SEQUENCE. Think about what happens if
optionalSignature is not there.

DPVResponse. The signature is marked as optional, but it contradicts to the
statement futher down in the same paragraph: "The response must be integrity
protected...". Suggest changing to "The *valid* response must be integrity
protected...".

TBSResponse. Why is the certs field tagged?

DPVResponseData. You have two optional OCTET STRING elements one following
another. Tagging is necessary.

RevokedInfo. Why bother adding revokedCert in there? It is the same as the
certProcessed. 

P9. Last sentence before [6]. requestExtensions. Must be responseExtensions.


Regards
Michael

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Friday, 13 July 2001 1:52
> To: pkix
> Subject: DPV and DPD
> 
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. A URL for this Internet-Draft is:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-00.txt
> 
> In the advertisement, the abstract has been cut down. The 
> full abstract 
> is the following:
> 
> This document specifies two protocols. The first one, called 
> Delegated 
> Path Validation (DPV) can be used to fully delegate a path validation 
> processing to an DPV server, according to a set of rules called a 
> validation policy. 
> 
> The second one, called Delegated Path Discovery (DPD) can be used to 
> obtain from a DPD server all the information needed (e.g. leaf 
> certificates, CA certificates, full CRLs, delta-CRLs, OCSP responses) 
> to locally validate a certificate according to a set of rules called 
> a path validation criteria. This provides a single protocol 
> to collect 
> at one time all data elements that normally require different 
> protocols.
> 
> It also defines an optional protocol allowing to define the set of 
> rules to validate a certificate or to build a path for a certificate.
> 
> 
> Since I am going on vacations on Friday July 13 th and will be back
> the week prior to the next IETF meeting in London (that I 
> will attend) 
> this does not give me much time to discuss it. A few hints:
> 
> At the last meeting, OCSPv2 was discussed quite heavily. I 
> still find that
> the approach of trying to extend OCSPv1 to support both DPV 
> and DPD is not
> the right approach. I also believe that the services, as 
> being described, 
> do not fullfill some objectives.
> 
> Instead of trying to make corrections that would have been 
> quite major, 
> I have written a new draft. It takes some inputs from the 
> work that has been
> done in the S/MIME WG and re-uses some of the ASN1 structures 
> that have been
> defined in a document that should be published soon (?) (i.e. 
> when the TSP 
> document is published). The document is currently referenced 
> as "Electronic 
> Signature Formats for long term electronic signature" and is 
> available at:
> http://www.imc.org/draft-ietf-smime-esformats.
> 
> I have prepared some slides to present the document at the 
> London meeting.
> 
> Denis
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6DHK2229503 for ietf-pkix-bks; Fri, 13 Jul 2001 10:20:02 -0700 (PDT)
Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6DHK1q29499 for <[e-mail]>; Fri, 13 Jul 2001 10:20:01 -0700 (PDT)
Received: from webmail.worldnet.att.net ([204.127.135.60]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Fri, 13 Jul 2001 17:19:53 +0000
Received: from [161.215.27.111] by webmail.worldnet.att.net; Fri, 13 Jul 2001 17:19:52 +0000
From: [e-mail]
To: "Graham Bland" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new -part1-08.txt)
Date: Fri, 13 Jul 2001 17:19:52 +0000
X-Mailer: AT&T Message Center Version 1 (May  2 2001)
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

yes, I can - but it wont happen until tonight so lets 
take the rest of this offline until I can explain what I
am trying to accomplish - no point in wasting the groups
cycles without the whole picture there.


--
Regards,
Todd
> Todd,
> 
> Can you give us some examples of what you are trying to achieve with this
> and how you see OID negotiation working.
> 
> I think this may help us all understand better where you are coming from.
> 
> Graham Bland
> 
> ----- Original Message -----
> From: <[e-mail]>
> To: "Bland, Graham" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Thursday, July 12, 2001 11:28 PM
> Subject: RE: New draft of son-of-2459 (Was: I-D
> ACTION:draft-ietf-pkix-new -part1-08.txt)
> 
> 
> >
> >
> > > ----------
> > > From: [e-mail][SMTP:[e-mail]]
> > > Sent: Thursday, July 12, 2001 11:28:07 PM
> > > To: Bland, Graham
> > > Cc: [e-mail]
> > > Subject: RE: New draft of son-of-2459 (Was: I-D
> ACTION:draft-ietf-pkix-new -part1-08.txt)
> > > Auto forwarded by a Rule
> > >
> > Graham -
> > To the last comment you made - We need to build "the OID
> > discovery and authentication protocol".
> >
> > This will allow policy and policy-centric events to be
> > included dynamically and authenticated inline. This in my
> > mind is a key missing piece of Son Of...
> >
> > T.
> >
> > --
> > Regards,
> > Todd
> > >
> > > Todd,
> > >
> > > Yes I agree in a totally closed environment, between mutually agreeing
> > > parties there is no need to register OIDs.  But why avoid the
> registration,
> > > it only has to be done once to establish an arc, it does not need doing
> for
> > > each OID which is allocated in a closed environment.
> > >
> > > I cannot see how an application can be coded to handle OID collisions
> for a
> > > lower cost than the effort involved in the registration.
> > >
> > > Lastly how does an application handle two extensions in a certificate
> with
> > > the same identifier (OID) but having separate meanings when there is no
> way
> > > of telling them apart.
> > >
> > > Graham Bland
> > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]]
> > > > Sent: 11 July 2001 15:20
> > > > To: Housley, Russ
> > > > Cc: [e-mail]
> > > > Subject: Re: New draft of son-of-2459 (Was: I-D
> > > > ACTION:draft-ietf-pkix-new-part1-08.txt)
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Todd
> > > > > Todd:
> > > > >
> > > > > No.
> > > >
> > > > Yes!
> > > >
> > > > >
> > > > > The process of obtaining an OID must ensure that the same
> > > > OID is not used
> > > > > for two different extensions.  If this where to happen,
> > > > then a replying
> > > > > party could not know which syntax or semantics to apply to
> > > > the extension in
> > > > > a particular certificate.
> > > >
> > > > And this could easily be done by an agreement by two
> > > > individuals or the code
> > > > they are running at either end of the transaction. Or more importantly
> > > > by the apps being run at both ends.
> > > >
> > > > >
> > > > > I never said that the registration process had to lead to
> > > > publication of
> > > > > the OID, the associated syntax, or the associated
> > > > semantics.  I did say,
> > > > > and remain adamant, that OID use collisions must be avoided.
> > > >
> > > > No again - what needs to happen is that the App must be coded
> > > > to deal with
> > > > OID collisions not the protocol.
> > > > But that's the whole point. The registration process is
> > > > only necessary if the Use Model requires an external
> > > > "lookup step"... What if the OID itself carries
> > > > privacy protected information? As a CERT extension
> > > > this is actually a real potential and mandating that it be
> > > > a public process has some strange implications for limiting
> > > > the scope of "Son Of..."
> > > >
> > > > Look - If the app that is using the cert has
> > > > the OID constructs it uses hard coded into it then... no
> > > > public registration
> > > > is needed.
> > > >
> > > >
> > > > >
> > > > > Russ
> > > > >
> > > > > At 11:29 PM 7/10/2001 +0000, [e-mail] wrote:
> > > > > >Russ I am aware of OID registration, I have several PEN
> > > > > >OIDs myself.
> > > > > >
> > > > > >The point is that if
> > > > > >
> > > > > >1)  this is an OID that is only used within a closed
> > > > > >environment there is no need to keep anyone else from
> > > > > >using it.
> > > > > >
> > > > > >2)  If you are referring to a process for propagating an
> > > > > >OID so that both users could have the same definition on
> > > > > >the OID they are using, then that is a good idea but
> > > > > >that is not per se "registration".
> > > > > >
> > > > > >So I disagree with your commentary and pushback. What I
> > > > > >feel you are referring to is an arbitrary need
> > > > > >to "register all OIDs" as in with the IANA rather than a
> > > > > >method of OID content negotiation and IMHO I will
> > > > > >continue to disagree with your commentary.
> > > > > >
> > > > > >--
> > > > > >Regards,
> > > > > >Todd
> > > > > > >
> > > > > > > Todd:
> > > > > > >
> > > > > > > The point is that a unique OID must be used.
> > > > > >
> > > > > >Not true. If I have an OID and it is a private
> > > > > >system I can do whatever I want with that OID.
> > > > > >I do not need IANA or anyone else besides my
> > > > > >private use partners to tell me what the OID means.
> > > > > >
> > > > > > > Registration is the process
> > > > > > > used to obtain the unique OID, even if the resulting
> > > > OID is not published
> > > > > > > in any public manner.
> > > > > > >
> > > > > > > Russ
> > > > > > >
> > > > > > >
> > > > > > > At 03:16 PM 7/10/2001 +0000, [e-mail] wrote:
> > > > > > >
> > > > > > > >Two points - the first is the pushback on the
> > > > > > > >work "methods". I believe that the term "features" is
> > > > > > > >better here, and to the second question... if the
> > > > > > > >methods are private why is there any need to register
> > > > > > > >them. The only need I can see in issuing a publicly
> > > > > > > >available OID is if there are publicly linked
> > > > > > > >participants of unknow origins and as such would need
> > > > > > > >some way of registering these "OID's" locally.
> > > > > > > >
> > > > > > > >T.
> > > > > > > >--
> > > > > > > >Regards,
> > > > > > > >Todd
> > > > > > > > >
> > > > > > > > > "4.2  Certificate Extensions
> > > > > > > > >
> > > > > > > > >    The extensions defined for X.509 v3 certificates
> > > > provide methods for
> > > > > > > > >    associating additional attributes with users or
> > > > public keys and for
> > > > > > > > >    managing the certification hierarchy.  The X.509
> > > > v3 certificate
> > > > > > > > >    format also allows communities to define private
> > > > extensions to carry
> > > > > > > > >    information unique to those communities."
> > > > > > > > >
> > > > > > > > > Then there is a section Private Internet Extesions
> > > > where two specific
> > > > > > > > > extension are specified.  I assume that this is the
> > > > same as the private
> > > > > > > > > extensions mentioned above.
> > > > > > > > >
> > > > > > > > > Question: How are arbitrary private extensions
> > > > supposed to be added?
> > > > > > > > > You must register/define an OID?
> > > > > > > > >
> > > > > > > > > Regards
> > > > > > > > > Anders R
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > >
> > > _______________________________________________________________________
> > >
> > > This message is confidential and is intended for the addressee only;
> > > unless clearly stated that this disclaimer should not apply, this
> > > e-mail is not intended to create legally binding commitments on
> > > behalf of any company in the British Interactive Broadcasting
> > > Holdings Limited group,  nor do its contents reflect the corporate
> > > views or policies of any such company. Any unauthorised disclosure,
> > > use or dissemination, either whole or partial, is prohibited. If you
> > > are not the intended recipient of the message, please notify the
> > > sender immediately.
> > > _______________________________________________________________________
> > _______________________________________________________________________
> >
> > This message is confidential and is intended for the addressee only;
> > unless clearly stated that this disclaimer should not apply, this
> > e-mail is not intended to create legally binding commitments on
> > behalf of any company in the British Interactive Broadcasting
> > Holdings Limited group,  nor do its contents reflect the corporate
> > views or policies of any such company. Any unauthorised disclosure,
> > use or dissemination, either whole or partial, is prohibited. If you
> > are not the intended recipient of the message, please notify the
> > sender immediately.
> > _______________________________________________________________________
> >
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6D35UT13716 for ietf-pkix-bks; Thu, 12 Jul 2001 20:05:30 -0700 (PDT)
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6D35Sq13712 for <[e-mail]>; Thu, 12 Jul 2001 20:05:28 -0700 (PDT)
Received: from tsg1 ([12.81.65.73]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010713030515.UMBT3707.mtiwmhc24.worldnet.att.net@tsg1>; Fri, 13 Jul 2001 03:05:15 +0000
Message-ID: <006901c10b48$936dc500$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <p05010401b772240e7d74@[128.33.84.34]>
Subject: Re: New draft of son-of-2459 
Date: Thu, 12 Jul 2001 20:02:52 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Steve -
you are wrong. An OID negotiation protocol would allow the use of the certs
and their extensions without the third party lookup process, and it for a
number of more autonomic uses of PKI it does make sense.

OIDs can be infinitely more useful than they have been to date, but not
without some better negotiations processes. Here is the obvious place to
start that.

Todd

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, July 11, 2001 8:43 AM
Subject: Re: New draft of son-of-2459 (Was:
I-DACTION:draft-ietf-pkix-new-part1-08.txt)


>
> At 3:19 PM +0000 7/11/01, [e-mail] wrote:
> >No, what I want is for the protocol to not mandate that
> >I go to a third party to use it.
> >
>
> Todd,
>
> We have a number of protocols in the IETF that make use of OIDs and
> they all make the assumption that someone who wants a new OID will go
> through the process of getting it assigned under some arc that is
> part of the global registration system, to avoid collisions.  People
> have been able to deal with this model for a number of years and
> although it is not perfect, the problems people have had are not the
> one you allude to.  We're not going to change the model now.
>
> Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6CMSHh08212 for ietf-pkix-bks; Thu, 12 Jul 2001 15:28:17 -0700 (PDT)
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CMSFm08208 for <[e-mail]>; Thu, 12 Jul 2001 15:28:15 -0700 (PDT)
Received: from webmail.worldnet.att.net ([204.127.135.40]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Thu, 12 Jul 2001 22:28:08 +0000
Received: from [161.215.27.111] by webmail.worldnet.att.net; Thu, 12 Jul 2001 22:28:07 +0000
From: [e-mail]
To: "Bland, Graham" <[e-mail]>
Cc: [e-mail]
Subject: RE: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new -part1-08.txt)
Date: Thu, 12 Jul 2001 22:28:07 +0000
X-Mailer: AT&T Message Center Version 1 (May  2 2001)
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Graham - 
To the last comment you made - We need to build "the OID
discovery and authentication protocol". 

This will allow policy and policy-centric events to be
included dynamically and authenticated inline. This in my
mind is a key missing piece of Son Of...

T.

--
Regards,
Todd
> 
> Todd,
> 
> Yes I agree in a totally closed environment, between mutually agreeing
> parties there is no need to register OIDs.  But why avoid the registration,
> it only has to be done once to establish an arc, it does not need doing for
> each OID which is allocated in a closed environment.
> 
> I cannot see how an application can be coded to handle OID collisions for a
> lower cost than the effort involved in the registration.  
> 
> Lastly how does an application handle two extensions in a certificate with
> the same identifier (OID) but having separate meanings when there is no way
> of telling them apart. 
> 
> Graham Bland
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: 11 July 2001 15:20
> > To: Housley, Russ
> > Cc: [e-mail]
> > Subject: Re: New draft of son-of-2459 (Was: I-D
> > ACTION:draft-ietf-pkix-new-part1-08.txt)
> > 
> > 
> > 
> > 
> > --
> > Regards,
> > Todd
> > > Todd:
> > > 
> > > No.
> > 
> > Yes! 
> > 
> > > 
> > > The process of obtaining an OID must ensure that the same 
> > OID is not used 
> > > for two different extensions.  If this where to happen, 
> > then a replying 
> > > party could not know which syntax or semantics to apply to 
> > the extension in 
> > > a particular certificate.
> > 
> > And this could easily be done by an agreement by two 
> > individuals or the code 
> > they are running at either end of the transaction. Or more importantly
> > by the apps being run at both ends.
> > 
> > > 
> > > I never said that the registration process had to lead to 
> > publication of 
> > > the OID, the associated syntax, or the associated 
> > semantics.  I did say, 
> > > and remain adamant, that OID use collisions must be avoided.
> > 
> > No again - what needs to happen is that the App must be coded 
> > to deal with
> > OID collisions not the protocol. 
> > But that's the whole point. The registration process is 
> > only necessary if the Use Model requires an external 
> > "lookup step"... What if the OID itself carries
> > privacy protected information? As a CERT extension 
> > this is actually a real potential and mandating that it be
> > a public process has some strange implications for limiting 
> > the scope of "Son Of..."
> > 
> > Look - If the app that is using the cert has 
> > the OID constructs it uses hard coded into it then... no 
> > public registration
> > is needed.
> > 
> > 
> > > 
> > > Russ
> > > 
> > > At 11:29 PM 7/10/2001 +0000, [e-mail] wrote:
> > > >Russ I am aware of OID registration, I have several PEN
> > > >OIDs myself.
> > > >
> > > >The point is that if
> > > >
> > > >1)  this is an OID that is only used within a closed
> > > >environment there is no need to keep anyone else from
> > > >using it.
> > > >
> > > >2)  If you are referring to a process for propagating an
> > > >OID so that both users could have the same definition on
> > > >the OID they are using, then that is a good idea but
> > > >that is not per se "registration".
> > > >
> > > >So I disagree with your commentary and pushback. What I
> > > >feel you are referring to is an arbitrary need
> > > >to "register all OIDs" as in with the IANA rather than a
> > > >method of OID content negotiation and IMHO I will
> > > >continue to disagree with your commentary.
> > > >
> > > >--
> > > >Regards,
> > > >Todd
> > > > >
> > > > > Todd:
> > > > >
> > > > > The point is that a unique OID must be used.
> > > >
> > > >Not true. If I have an OID and it is a private
> > > >system I can do whatever I want with that OID.
> > > >I do not need IANA or anyone else besides my
> > > >private use partners to tell me what the OID means.
> > > >
> > > > > Registration is the process
> > > > > used to obtain the unique OID, even if the resulting 
> > OID is not published
> > > > > in any public manner.
> > > > >
> > > > > Russ
> > > > >
> > > > >
> > > > > At 03:16 PM 7/10/2001 +0000, [e-mail] wrote:
> > > > >
> > > > > >Two points - the first is the pushback on the
> > > > > >work "methods". I believe that the term "features" is
> > > > > >better here, and to the second question... if the
> > > > > >methods are private why is there any need to register
> > > > > >them. The only need I can see in issuing a publicly
> > > > > >available OID is if there are publicly linked
> > > > > >participants of unknow origins and as such would need
> > > > > >some way of registering these "OID's" locally.
> > > > > >
> > > > > >T.
> > > > > >--
> > > > > >Regards,
> > > > > >Todd
> > > > > > >
> > > > > > > "4.2  Certificate Extensions
> > > > > > >
> > > > > > >    The extensions defined for X.509 v3 certificates 
> > provide methods for
> > > > > > >    associating additional attributes with users or 
> > public keys and for
> > > > > > >    managing the certification hierarchy.  The X.509 
> > v3 certificate
> > > > > > >    format also allows communities to define private 
> > extensions to carry
> > > > > > >    information unique to those communities."
> > > > > > >
> > > > > > > Then there is a section Private Internet Extesions 
> > where two specific
> > > > > > > extension are specified.  I assume that this is the 
> > same as the private
> > > > > > > extensions mentioned above.
> > > > > > >
> > > > > > > Question: How are arbitrary private extensions 
> > supposed to be added?
> > > > > > > You must register/define an OID?
> > > > > > >
> > > > > > > Regards
> > > > > > > Anders R
> > > > > > >
> > > > > > >
> > > > > > >
> > 
> _______________________________________________________________________
> 
> This message is confidential and is intended for the addressee only;
> unless clearly stated that this disclaimer should not apply, this 
> e-mail is not intended to create legally binding commitments on 
> behalf of any company in the British Interactive Broadcasting 
> Holdings Limited group,  nor do its contents reflect the corporate 
> views or policies of any such company. Any unauthorised disclosure, 
> use or dissemination, either whole or partial, is prohibited. If you 
> are not the intended recipient of the message, please notify the
> sender immediately.
> _______________________________________________________________________


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6CKGrH06007 for ietf-pkix-bks; Thu, 12 Jul 2001 13:16:53 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CKGqm06003 for <[e-mail]>; Thu, 12 Jul 2001 13:16:52 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17763; Thu, 12 Jul 2001 16:16:01 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRI Profile to Proposed Standard
Reply-to: [e-mail]
Date: Thu, 12 Jul 2001 16:16:01 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider the following Internet-Drafts as
Proposed Standards:

o Algorithms and Identifiers for the Internet X.509 Public Key
  Infrastructure Certificate and CRI Profile 
     <draft-ietf-pkix-ipki-pkalgs-03.txt>

o Internet X.509 Public Key Infrastructure Certificate and CRL Profile
     <draft-ietf-pkix-new-part1-08.txt>


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

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-08.txt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6CFq2n28884 for ietf-pkix-bks; Thu, 12 Jul 2001 08:52:02 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CFq0m28880 for <[e-mail]>; Thu, 12 Jul 2001 08:52:00 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA12356 for <[e-mail]>; Thu, 12 Jul 2001 17:53:07 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA15642 for <[e-mail]>; Thu, 12 Jul 2001 17:51:56 +0200
Message-ID: <[e-mail]>
Date: Thu, 12 Jul 2001 17:51:58 +0200
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: DPV and DPD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

A New Internet-Draft is available from the on-line Internet-Drafts
directories. A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-00.txt

In the advertisement, the abstract has been cut down. The full abstract 
is the following:

This document specifies two protocols. The first one, called Delegated 
Path Validation (DPV) can be used to fully delegate a path validation 
processing to an DPV server, according to a set of rules called a 
validation policy. 

The second one, called Delegated Path Discovery (DPD) can be used to 
obtain from a DPD server all the information needed (e.g. leaf 
certificates, CA certificates, full CRLs, delta-CRLs, OCSP responses) 
to locally validate a certificate according to a set of rules called 
a path validation criteria. This provides a single protocol to collect 
at one time all data elements that normally require different 
protocols.

It also defines an optional protocol allowing to define the set of 
rules to validate a certificate or to build a path for a certificate.


Since I am going on vacations on Friday July 13 th and will be back
the week prior to the next IETF meeting in London (that I will attend) 
this does not give me much time to discuss it. A few hints:

At the last meeting, OCSPv2 was discussed quite heavily. I still find that
the approach of trying to extend OCSPv1 to support both DPV and DPD is not
the right approach. I also believe that the services, as being described, 
do not fullfill some objectives.

Instead of trying to make corrections that would have been quite major, 
I have written a new draft. It takes some inputs from the work that has been
done in the S/MIME WG and re-uses some of the ASN1 structures that have been
defined in a document that should be published soon (?) (i.e. when the TSP 
document is published). The document is currently referenced as "Electronic 
Signature Formats for long term electronic signature" and is available at:
http://www.imc.org/draft-ietf-smime-esformats.

I have prepared some slides to present the document at the London meeting.

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6CEm3k22976 for ietf-pkix-bks; Thu, 12 Jul 2001 07:48:03 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6CEm1m22969 for <[e-mail]>; Thu, 12 Jul 2001 07:48:01 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Jul 2001 14:46:31 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA29152 for <[e-mail]>; Wed, 11 Jul 2001 09:11:08 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TQDW6>; Wed, 11 Jul 2001 09:11:06 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.38]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TQDWZ; Wed, 11 Jul 2001 09:11:03 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 11 Jul 2001 09:11:03 -0400
Subject: Re: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new-part1-08.txt)
In-Reply-To: <20010710232928.UBUC1777.mtiwmhc23.worldnet.att.net@webmail .worldnet.att.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Todd:

No.

The process of obtaining an OID must ensure that the same OID is not used 
for two different extensions.  If this where to happen, then a replying 
party could not know which syntax or semantics to apply to the extension in 
a particular certificate.

I never said that the registration process had to lead to publication of 
the OID, the associated syntax, or the associated semantics.  I did say, 
and remain adamant, that OID use collisions must be avoided.

Russ

At 11:29 PM 7/10/2001 +0000, [e-mail] wrote:
>Russ I am aware of OID registration, I have several PEN
>OIDs myself.
>
>The point is that if
>
>1)  this is an OID that is only used within a closed
>environment there is no need to keep anyone else from
>using it.
>
>2)  If you are referring to a process for propagating an
>OID so that both users could have the same definition on
>the OID they are using, then that is a good idea but
>that is not per se "registration".
>
>So I disagree with your commentary and pushback. What I
>feel you are referring to is an arbitrary need
>to "register all OIDs" as in with the IANA rather than a
>method of OID content negotiation and IMHO I will
>continue to disagree with your commentary.
>
>--
>Regards,
>Todd
> >
> > Todd:
> >
> > The point is that a unique OID must be used.
>
>Not true. If I have an OID and it is a private
>system I can do whatever I want with that OID.
>I do not need IANA or anyone else besides my
>private use partners to tell me what the OID means.
>
> > Registration is the process
> > used to obtain the unique OID, even if the resulting OID is not published
> > in any public manner.
> >
> > Russ
> >
> >
> > At 03:16 PM 7/10/2001 +0000, [e-mail] wrote:
> >
> > >Two points - the first is the pushback on the
> > >work "methods". I believe that the term "features" is
> > >better here, and to the second question... if the
> > >methods are private why is there any need to register
> > >them. The only need I can see in issuing a publicly
> > >available OID is if there are publicly linked
> > >participants of unknow origins and as such would need
> > >some way of registering these "OID's" locally.
> > >
> > >T.
> > >--
> > >Regards,
> > >Todd
> > > >
> > > > "4.2  Certificate Extensions
> > > >
> > > >    The extensions defined for X.509 v3 certificates provide methods for
> > > >    associating additional attributes with users or public keys and for
> > > >    managing the certification hierarchy.  The X.509 v3 certificate
> > > >    format also allows communities to define private extensions to carry
> > > >    information unique to those communities."
> > > >
> > > > Then there is a section Private Internet Extesions where two specific
> > > > extension are specified.  I assume that this is the same as the private
> > > > extensions mentioned above.
> > > >
> > > > Question: How are arbitrary private extensions supposed to be added?
> > > > You must register/define an OID?
> > > >
> > > > Regards
> > > > Anders R
> > > >
> > > >
> > > >


Received: by above.proper.com (8.11.3/8.11.3) id f6CEm2w22974 for ietf-pkix-bks; Thu, 12 Jul 2001 07:48:02 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6CElsm22961 for <[e-mail]>; Thu, 12 Jul 2001 07:47:54 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Jul 2001 14:46:25 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA05735 for <[e-mail]>; Wed, 11 Jul 2001 10:27:26 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TQFAV>; Wed, 11 Jul 2001 10:27:24 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.8]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TQFA4; Wed, 11 Jul 2001 10:27:21 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 11 Jul 2001 10:27:20 -0400
Subject: Re: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new-part1-08.txt)
In-Reply-To: <20010711141932.HEEZ2154.mtiwmhc26.worldnet.att.net@webmail .worldnet.att.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Todd:

We agree that no PUBLIC registration is needed.  However, the coding that 
you suggest to handle OID collisions is likely to be error prone.

You say that you have several PEN arcs.  If you assign an OID from one of 
those, it will be unique (unless you are sloppy and use the same one for 
more than one purpose).  You do not have to tell anyone that you made the 
assignment, the associated syntax, or the associated semantics.  Just use 
it in your application.  As long as the extension is marked non-critical, 
it will be ignored by everyone else.  If the extension is marked critical, 
everyone else will reject the certificate -- maybe that is what you want.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6CB7xh18009 for ietf-pkix-bks; Thu, 12 Jul 2001 04:07:59 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CB7vm18005 for <[e-mail]>; Thu, 12 Jul 2001 04:07:58 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01885; Thu, 12 Jul 2001 07:07:08 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-00.txt
Date: Thu, 12 Jul 2001 07:07:07 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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 Proxy 
                          Certificate Profile
	Author(s)	: S. Tuecke et al.
	Filename	: draft-ietf-pkix-proxy-00.txt
	Pages		: 
	Date		: 11-Jul-01
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 PKI certificates as defined in draft-ietf-pkix-new-
part1-08.txt (the draft update to RFC 2459), for use in the 
Internet.  The term Proxy Certificate is used to describe a 
certificate that is derived from, and signed by, a normal X.509 
Public Key End Entity Certificate or by another Proxy Certificate 
for the purpose of providing restricted impersonation within a PKI 
based authentication system.  This draft replaces draft-ietf-pkix-
impersonation-00.

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f6CB7s818003 for ietf-pkix-bks; Thu, 12 Jul 2001 04:07:54 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CB7rm17999 for <[e-mail]>; Thu, 12 Jul 2001 04:07:53 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01869; Thu, 12 Jul 2001 07:07:03 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dpv-dpd-00.txt
Date: Thu, 12 Jul 2001 07:07:03 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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		: Delegated Path Validation and Delegated Path Discovery
                          Protocols
	Author(s)	: D. Pinkas
	Filename	: draft-ietf-pkix-dpv-dpd-00.txt
	Pages		: 22
	Date		: 11-Jul-01
	
This document specifies two protocols. The first one, called Delegated 
Path Validation (DPV) can be used to fully delegate a path validation 
processing to an DPV server, according to a set of rules called a 
validation policy.

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6C9qUd15687 for ietf-pkix-bks; Thu, 12 Jul 2001 02:52:30 -0700 (PDT)
Received: from ns1.tu-graz.ac.at (ns1.tu-graz.ac.at [129.27.2.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6C9qTm15683 for <[e-mail]>; Thu, 12 Jul 2001 02:52:29 -0700 (PDT)
Received: from kraxi (b-44.vc-graz.ac.at [193.171.241.44]) by ns1.tu-graz.ac.at (8.9.3/8.9.3) with SMTP id LAA06344 for <[e-mail]>; Thu, 12 Jul 2001 11:52:28 +0200 (MET DST)
Message-ID: <002b01c10ab8$5ceed220$2cf1abc1@kraxi>
From: "Stefan Kraxberger" <[e-mail]>
To: <[e-mail]>
Subject: Experimental TSA (IAIK Graz)
Date: Thu, 12 Jul 2001 11:52:28 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Now i have made some changes according to the new draft (15). Now the
service is running again!

IP: 193.171.241.44 | Port: 318

But i have still a problem! I have tested our server with the client
implementation of timeproof where i get an ASN.1 error. But our Client works
fine with the server implementation of timeproof.
So please test our TSA

Stefan



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6C9Jjw15036 for ietf-pkix-bks; Thu, 12 Jul 2001 02:19:45 -0700 (PDT)
Received: from mailout01.sul.t-online.de (mailout01.sul.t-online.com [194.25.134.80]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6C9Jhm15032 for <[e-mail]>; Thu, 12 Jul 2001 02:19:43 -0700 (PDT)
Received: from fwd00.sul.t-online.de  by mailout01.sul.t-online.de with smtp  id 15KcdG-0003kJ-00; Thu, 12 Jul 2001 11:19:38 +0200
Received: from junker.stroeder.com (520010731148-0001@[62.224.165.169]) by fmrl00.sul.t-online.com with esmtp id 15Kcd1-29eap6C; Thu, 12 Jul 2001 11:19:23 +0200
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix on SuSE Linux 7.1 (i386)) with ESMTP id 7706C15716A for <[e-mail]>; Thu, 12 Jul 2001 11:19:21 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 12 Jul 2001 11:19:21 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
Cc: [e-mail]
Subject: Re: New draft of son-of-2459 (Was: I-D  ACTION:draft-ietf-pkix-new-part1-08.txt)
References: <36086CC80304D3119B040008C75DF5960494362D@claudio>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"Bland, Graham" wrote:
> 
> I cannot see how an application can be coded to handle OID collisions for 
> a lower cost than the effort involved in the registration.

I completely agree with that. Using non-unique OIDs will cause
nothing than grief and therefore will waste a lot of time and money
-  e.g. already by discussing it on this list.

Registration of the OID arc takes five minutes and is for free.
Maintaining the OID arc takes more time. But the latter has to be
done anyway.

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6C6U5j25785 for ietf-pkix-bks; Wed, 11 Jul 2001 23:30:05 -0700 (PDT)
Received: from claudio.bib.co.uk (gateway.bib.co.uk [195.171.24.2]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6C6U4m25781 for <[e-mail]>; Wed, 11 Jul 2001 23:30:04 -0700 (PDT)
Received: from 127.0.0.1 by claudio.bib.co.uk (InterScan E-Mail VirusWall NT); Thu, 12 Jul 2001 07:29:55 +0100 (GMT Daylight Time)
Received: by claudio with Internet Mail Service (5.5.2653.19) id <3GDWPVJK>; Thu, 12 Jul 2001 07:29:55 +0100
Message-ID: <36086CC80304D3119B040008C75DF5960494362D@claudio>
From: "Bland, Graham" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new -part1-08.txt)
Date: Thu, 12 Jul 2001 07:29:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Todd,

Yes I agree in a totally closed environment, between mutually agreeing
parties there is no need to register OIDs.  But why avoid the registration,
it only has to be done once to establish an arc, it does not need doing for
each OID which is allocated in a closed environment.

I cannot see how an application can be coded to handle OID collisions for a
lower cost than the effort involved in the registration.  

Lastly how does an application handle two extensions in a certificate with
the same identifier (OID) but having separate meanings when there is no way
of telling them apart. 

Graham Bland

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 11 July 2001 15:20
> To: Housley, Russ
> Cc: [e-mail]
> Subject: Re: New draft of son-of-2459 (Was: I-D
> ACTION:draft-ietf-pkix-new-part1-08.txt)
> 
> 
> 
> 
> --
> Regards,
> Todd
> > Todd:
> > 
> > No.
> 
> Yes! 
> 
> > 
> > The process of obtaining an OID must ensure that the same 
> OID is not used 
> > for two different extensions.  If this where to happen, 
> then a replying 
> > party could not know which syntax or semantics to apply to 
> the extension in 
> > a particular certificate.
> 
> And this could easily be done by an agreement by two 
> individuals or the code 
> they are running at either end of the transaction. Or more importantly
> by the apps being run at both ends.
> 
> > 
> > I never said that the registration process had to lead to 
> publication of 
> > the OID, the associated syntax, or the associated 
> semantics.  I did say, 
> > and remain adamant, that OID use collisions must be avoided.
> 
> No again - what needs to happen is that the App must be coded 
> to deal with
> OID collisions not the protocol. 
> But that's the whole point. The registration process is 
> only necessary if the Use Model requires an external 
> "lookup step"... What if the OID itself carries
> privacy protected information? As a CERT extension 
> this is actually a real potential and mandating that it be
> a public process has some strange implications for limiting 
> the scope of "Son Of..."
> 
> Look - If the app that is using the cert has 
> the OID constructs it uses hard coded into it then... no 
> public registration
> is needed.
> 
> 
> > 
> > Russ
> > 
> > At 11:29 PM 7/10/2001 +0000, [e-mail] wrote:
> > >Russ I am aware of OID registration, I have several PEN
> > >OIDs myself.
> > >
> > >The point is that if
> > >
> > >1)  this is an OID that is only used within a closed
> > >environment there is no need to keep anyone else from
> > >using it.
> > >
> > >2)  If you are referring to a process for propagating an
> > >OID so that both users could have the same definition on
> > >the OID they are using, then that is a good idea but
> > >that is not per se "registration".
> > >
> > >So I disagree with your commentary and pushback. What I
> > >feel you are referring to is an arbitrary need
> > >to "register all OIDs" as in with the IANA rather than a
> > >method of OID content negotiation and IMHO I will
> > >continue to disagree with your commentary.
> > >
> > >--
> > >Regards,
> > >Todd
> > > >
> > > > Todd:
> > > >
> > > > The point is that a unique OID must be used.
> > >
> > >Not true. If I have an OID and it is a private
> > >system I can do whatever I want with that OID.
> > >I do not need IANA or anyone else besides my
> > >private use partners to tell me what the OID means.
> > >
> > > > Registration is the process
> > > > used to obtain the unique OID, even if the resulting 
> OID is not published
> > > > in any public manner.
> > > >
> > > > Russ
> > > >
> > > >
> > > > At 03:16 PM 7/10/2001 +0000, [e-mail] wrote:
> > > >
> > > > >Two points - the first is the pushback on the
> > > > >work "methods". I believe that the term "features" is
> > > > >better here, and to the second question... if the
> > > > >methods are private why is there any need to register
> > > > >them. The only need I can see in issuing a publicly
> > > > >available OID is if there are publicly linked
> > > > >participants of unknow origins and as such would need
> > > > >some way of registering these "OID's" locally.
> > > > >
> > > > >T.
> > > > >--
> > > > >Regards,
> > > > >Todd
> > > > > >
> > > > > > "4.2  Certificate Extensions
> > > > > >
> > > > > >    The extensions defined for X.509 v3 certificates 
> provide methods for
> > > > > >    associating additional attributes with users or 
> public keys and for
> > > > > >    managing the certification hierarchy.  The X.509 
> v3 certificate
> > > > > >    format also allows communities to define private 
> extensions to carry
> > > > > >    information unique to those communities."
> > > > > >
> > > > > > Then there is a section Private Internet Extesions 
> where two specific
> > > > > > extension are specified.  I assume that this is the 
> same as the private
> > > > > > extensions mentioned above.
> > > > > >
> > > > > > Question: How are arbitrary private extensions 
> supposed to be added?
> > > > > > You must register/define an OID?
> > > > > >
> > > > > > Regards
> > > > > > Anders R
> > > > > >
> > > > > >
> > > > > >
> 
_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BL1Ct07421 for ietf-pkix-bks; Wed, 11 Jul 2001 14:01:12 -0700 (PDT)
Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BL1Am07411 for <[e-mail]>; Wed, 11 Jul 2001 14:01:10 -0700 (PDT)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2650.21) id <3V2SW2K1>; Wed, 11 Jul 2001 16:06:42 -0400
Message-ID: <[e-mail]>
From: "Scott, Greg" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: 2797-bis confirm cert control attribute
Date: Wed, 11 Jul 2001 16:06:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Section 5.14 of draft-ietf-pkix-2797-bis-00 has the confirm certificate
acceptance structure as:

      CMCCertId ::= IssuerSerial

Shouldn't it be?:

      CMCCertId ::= SEQUENCE {

          issuerName      Name,
          serialNumber    INTEGER}



R/s
Greg Scott
732-427-6856
http://www-pki.itsi.disa.mil/




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BG64q27248 for ietf-pkix-bks; Wed, 11 Jul 2001 09:06:04 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BG61m27242 for <[e-mail]>; Wed, 11 Jul 2001 09:06:01 -0700 (PDT)
Received: from santesson.addtrust.com ([192.168.101.102]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 11 Jul 2001 18:05:19 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 11 Jul 2001 18:05:57 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Logotypes in Certificates - Report and proposal to work on new standard
In-Reply-To: <[e-mail]. com>
References: <00c201c10941$99da7680$0500a8c0@arport> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_966242122==_.ALT"
X-OriginalArrivalTime: 11 Jul 2001 16:05:19.0406 (UTC) FILETIME=[482BFCE0:01C10A23]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--=====================_966242122==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

All,

During my previous attempts to raise the issue regarding logotypes and 
branding related to certificates, Steve Kent asked me to come back with a 
more extensive discussion report on this issue with rationales, problems 
and solutions.

Since last  IETF I have worked on this from time to time with an informal 
group of peoples from other vendors who may want to make them self known at 
their own discretion.

The result of this discussion is this report that I propose to be the 
starting point of a new RFC to be developed in PKIX.

/Stefan Santesson


Report on Logotypes in X.509 Certificates

1. Rationale
The basic function of a certificate is to bind a public key to an entity 
(subject). From a strict technical viewpoint that would be satisfied by 
just signing the identity of the subject together with its public key. The 
art of PKI have however developed certificates far beyond this 
functionality in order to meet the needs from modern global networks and 
heterogeneous IT structures.

A primary driver of the evolution from simple certificate formats to more 
complex structures is the need to distinguish between different certificate 
concepts, defining everything from assurance level, policies and 
procedures, fields of usage to name forms and semantics. Before a relying 
party can make an informed decision whether a particular certificate is 
trustworthy and relevant for its intended usage, a large number of aspects 
of the certificate may have to be processed.

All of these aspects of certificates do mainly concern systematic 
processing in order to deliver a distinct Yes or No answer to the question 
whether the certificate match predefined prerequisites and thereby is 
regarded as appropriate for its intended usage. Even though these 
information objects in certificates are appropriate and effective for 
machine processing, they are poor instruments for a corresponding human 
trust and recognition process.

The human mind prefer to structure information into categories and symbols. 
Complex structures of reality are encapsulated in easy recognizable 
logotypes and marks. The human trust process is to a smaller extent based 
on information and to a greater extent based on recognition and experience. 
Very few consumers actually read all terms and conditions they accept when 
accepting a service, instead they most commonly act in trust based on 
experience and recognition.

A big part of this process is branding, where service providers invest a 
lot of money and resources into creating a strong relation between positive 
user experiences and easily recognizable trademarks and logotypes.

This reality also extends to the realm of concepts, services and 
instruments for identification, ranging from ID-cards, passports and 
driver's licenses to credit cards, gasoline cards and loyalty cards etc, 
whose function is to identify an entity either as a person or as member of 
community, subscriber of a service, etc. These concepts and instruments of 
identification in physical form have in common the use logotypes and 
symbols, solely aimed to enhance human recognition and trust in the 
underlying concept.

As certificates play an equivalent role in electronic exchange, to the use 
of physical ID's in physical exchange, some important questions deserves 
closer attention in the investigation whether the use of logotypes in 
certificates are relevant or not.

1.1 Are human recognition concepts relevant in electronic forms of 
identification?

The answer depends on the answer to the fundamental underlying question 
whether certificates should be visible or invisible to human users and if 
certificates will be used in open environments.

If certificates are to be used in open environments and in applications 
that brings the user in conscious contact with the result of a certificate 
based identification process, then human recognition of concept is highly 
relevant, and may even be a necessity.

Examples of applications of these types are:
   - Web server identification where a user identifies the owner of the web 
site.
   - Peer entity e-mail exchange (in B2B, B2C and private communication 
exchange).
   - Other profession information processing and message exchange systems 
(such as medical records handling, and system for medical prescriptions)
   - Unstructured e-business applications (i.e. non EDI applications)

Most applications that offer the user to view the result of a certificate 
based identification process do this by allowing the user to view the 
certificate of the identified entity. This solution has however two major 
problems.

   1) The function to view a certificate is often rather hard to find for a 
non-technical user.
   2) The presentation of the certificate is rather technical and not user 
friendly. Further it contains no graphic symbols and logotypes to enhance 
human recognition.

Many investigations have shown that users in current applications don't 
"click" to view certificates. There is however a distinct possibility that 
this fact is due to how applications are structured and due to very poor 
user interfaces, much more than a proof that certificates should not be 
exposed to users at all.

1.2 Can the concepts of systematic verification processing and human 
recognition be combined in any sensible manner?

Systematic verification of a certificate (including systematic verification 
of all certificates in the path built up to a trusted root) will at most 
give a user/system either the result "Verified according to defined policy" 
or "Failed verification according to defined policy".

The systematic processing has in this case provided the user/system with 
assurance that the certificate is a valid document, but not who the subject 
of the certificate in fact is or what that entity is entitled/trusted to 
do. The latter is the task of an access control function, which may again 
be a systematic process or in fact a human recognition process, all 
dependent on application context.

So in some situations a human person will be the sole handler of the post 
verification process of identification and authorization. It may in the end 
be a human decision to accept, act on or release information based on who 
and/or what the opponent is and whom he/she represents.

The conclusion is that the distinction between systematic processing and 
human processing is rather straightforward and clear and has the character 
of being complementary rather than interfering. While the systematic 
process is focused on path processing and verification, the human 
acceptance process is focused on identification, recognition and 
authorization.

Some interference issues do however exist as handled under security 
considerations section.

2. Different types of logotypes in certificates
This report recommends standardized supported usage of 3 types of logotypes 
in certificates.

   1) Concept logotype
   2) Issuer organization logotype
   3) Subject organization logotype

The concept logotype - is the general mark for a service concept for entity 
identification and certificate issuance. Many issuers may use the concept 
logotypes to co-brand with a global concept in order to gain global 
recognition of its local service provision. This type of concept branding 
is very common in credit card business where local independent card issuers 
issue cards within a globally branded concept (such as VISA and. MasterCard 
etc.).

Issuer organization logotype - is a logotype representing the organization 
identified as part of the issuer name in the certificate.

Subject organization logotype - is a logotype representing the organization 
identified in the subject name in the certificate.

3. Technical solutions
3.1 General
A general conclusion is that there is no need to include any logotype image 
data in a certificate.

The same function may be achieved by including a hash of the logotype image 
in the certificate together with a URI/ URL identifying the location of the 
logotype image data. Applications may enhance processing and off-line 
functionality by cashing logotype data.

Other minor aspects are:
   - that the URL also defines the file format for the image data.
   - that the solution includes algorithm information about the employed 
hash algorithm.

The initially proposed general structure for logotype data is:

       LogotypeData ::= SEQUENCE {
           typeOfLogotype       TypeOflogotype,
           hashAlgorithm        AlgorithmIdentifier,
           logotypeDataHash     OCTET STRING,
           sourceDataUri        IA5String OPTIONAL }

       TypeOflogotype ::= CHOICE {
           predefinedLogotypeType    PredefinedLogotypeType,
           LogotypeTypeID            OBJECT IDENTIFIER }

       PredefinedLogotypeType ::= INTEGER {
           subject-organization-logotype(0),
           issuer-organization-logotype(1)
           concept-logotype(2)}
           (subject-organization-logotype|
            issuer-organization-logotype|
            concept-logotype,...)


The predefined logotype types are

subject-organization-logotype, if used, SHALL be used to include a logotype 
of the subject organization. The logotype SHALL be consistent with, and 
require the presence of, an organization name stored in the organization 
attribute in the subject field.

issuer-organization-logotype, if used, SHALL be used to include a logotype 
of the issuer organization. The logotype SHALL be consistent with, and 
require the presence of, an organization name stored in the organization 
attribute in the issuer field.

Concept-logotype, if used, SHALL be used to include a logotype representing 
the concept under which the issuer claims to issue this certificate.


A concept may be shared within a network of CA services, provided by one or 
several independent CA organizations.

The relationship between the subject organization and the subject 
organization logotype and the relationship between the issuer and either 
the issuer organization logotype or the concept logotype, are relationships 
claimed by the issuer. The policy under which the issuer checks these 
logotypes is outside the scope of this standard.

Any URI pointing to a file containing the logotype data SHALL include a 
file extension defining the file format (i.e. .GIF, .TIF, .JPG etc.)


3.2 Type of certificates
Logotypes according to the present model may be used in 3 types of 
certificates:
   - Selfsigned CA certificates (root certificates)
   - Intermediate CA certificates
   - End entity certificates

A reason to constrain inclusion of logotypes to end entity certificates 
would be to exclude the aspect of logotypes from path processing issues, 
where a path validating service would want to check consistency of 
logotypes in a chain.

However, as discussed in the rationale, logotypes are not aimed to be part 
of path validation or any type of systematic processing since its sole 
purpose is to enhance display of a single particular certificate to a user 
regardless of its position or function in a path construct.

The conclusions are:
   - Logotypes should not be an active component in path processing.
   - Logotypes should be allowed in all types of certificates, by the 
choice of the CA.


3.2 Place of inclusion
So far there has been 3 solutions discussed regarding where to store 
logotype data in certificates.

   - Inclusion in a policy qualifier
   - Inclusion in Issuer and Subject Alternative names extensions
   - Inclusion in a separate private extension

3.2.1 Qualifier
This solution would include logotype data as a newly defined policy qualifier.

Pros:
   - This solution provides a mechanism to directly control the use and 
display of logotypes under a particular policy

Cons:
   - Current practice and standards (RFC 2459) recommends against use of 
qualifiers
   - This is generally considered to be a major hack and stretch of 
semantics, since this type of data doesn't qualify a policy in any way.

3.2.2 Issuer and Subject Alt Names
This solution would use the other name form to include;
   - issuer and concept logotypes in the issuer alt name extension; and
   - subject organization logo in the subject alt name extension.

Pros:
   - This mechanism could possibly enable cross certifying CAs to deny any 
subordinate CA the right to include logotypes in descending end entity 
certificates by listing the logotypes name form in excludedSubtrees.

Cons:
   - Logotypes are not a name form and can't be treated as a displayable name.
   - It is generally understood that it should be possible to apply general 
name constraint mechanisms (as described in RFC 2459 as well as son of RFC 
2459) to names in the subject and issuer alt name ext. This is however not 
possible to do with logotypes due to it's non-name form.
   - This split storage of logotype data into 2 different locations, which 
may make life worse for applications with no interest in logotypes.
   - It is generally agreed that inclusion of logotype data by no means 
should be regarded as critical data. This may interfere with the 
criticality policy of the alt name extensions, especially if the 
certificate has no attributes in the subject field, forcing the subject alt 
name to be set to critical.
   - This usage would possibly interfere with the resolution between IETF 
and ITU-T regarding use of permitted subtrees.
   - Since this solution may break current implementations it would 
possibly block adoption of logotypes.


3.2.3 New extension
This solution would create a new private (non critical) extension.

logotypeInfo  EXTENSION ::= {
           SYNTAX             LogotypeSyntax
           IDENTIFIED BY      id-pe-logotypeInfo }

       id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}

       LogotypeSyntax ::= SEQUENCE OF LogotypeData


Pros:
   - This is the cleanest solution.
-       Do not impact on legacy implementations.

Cons:
   - This solution activates the issue whether this extension may be abused 
by a CA who include logotypes (in EE certificates) that violates the 
intention of a name constraints set by a chaining CA. This issue is 
addressed in the security consideration section below.

3.2.4 Conclusion
The criteria for selecting a solution must be that it doesn't destroy 
current structures and doesn't create problems and confusion.

Only the private extension solution meets this criterion and should 
therefore be selected.

4. Use in Clients
All PKI implementations require that relying party software have some 
mechanism to determine whether a trusted CA issues a particular 
certificate. This is an issue for path validation of the certificate chain 
from a trusted root, including consistent policy and name checking.

After passing this process, the general assumption must be that the CA is 
trusted to certify the information carried in any certificate extensions, 
given that the client decides to use that information. The assumption is 
regarded as general due to the fact that current standards do not provide 
any mechanism for cross-certifying CAs to constrain subordinate CAs from 
including private extensions (see security considerations).

Consequently, if relying party software accepts a CA, then it should be 
prepared to (unquestioningly) display the associated logos to its human 
user, given that it is configured to do so.

5. Security considerations
Logotypes are even worse than names regarding the possibility to securely 
and accurately define what is, and what is not, a legitimate logotype of an 
organization. There is a whole legal structure around this issue that 
doesn't need repetition in this report.

As logotypes are hard (and sometimes expensive) to verify, this increases 
the possibility of errors related to falsely assigning wrong logotypes to 
organizations.

This is however not a new issue for electronic identification instruments, 
but rather a well known problem that is already dealt with in numerous of 
similar situations in the physical world, including physical employment ID 
cards. Secondly there are situations where identification of logotypes is 
rather simple and straight forward, such as logotypes for well-known 
industries and institutes. These issues should not be stopping those 
service providers wanting to go into the issue of logotypes from doing so, 
where this is relevant.

The new problem related to electronic identification instruments in the 
form of certificates are however that certificate chains may impose 
constraints that are systematically checked in path processing algorithms, 
which in theory may be violated by logotypes.

Path processing algorithms does not, should not, and will never be able to 
control if any logotype included in any certificate violates any such 
constraints. I.e. a chaining CA may constraint subordinate CAs to only 
issue certificates to end entities within a limited name space. A 
potentially bad CA may comply with this constraint in included names but 
may still include a subject organization logotype that gives a relying 
party the impression that the subject is part of another organization or 
being part of a group of companies, which exceeds the freedom in the name 
constraint.

This is however nothing unique with a logotype extension, but a general 
problem with X.509. The fact is that a chaining CA has no absolute 
technical control over subordinate CAs behaviour with respect to inclusion 
of new private extensions that may violate any policy or constraint set in 
a chaining certificate.

The controls available to a chaining CA to protect itself against bad CAs 
are mainly:
   - Contractual agreements of suitable behaviour, including terms of 
liability and severance pay in case of material breach.
   - Control mechanisms and procedures to monitor and follow-up behaviour 
of subordinate CAs
   - Use of certificate policies to declare assurance level of logotype 
data as well as to guide applications on how to treat and display logotypes.
   - Use of revocation functions to revoke any misbehaving CA.

This may not be an issue that can be given an easy and absolute technical 
solution. Maybe the correct response is to surrender to the fact that 
involved parties must settle some aspects of PKI outside the scope of 
technical controls, and to clearly identify and communicate the associated 
risks with that.



--=====================_966242122==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
All,<br>
<br>
During my previous attempts to raise the issue regarding logotypes and
branding related to certificates, Steve Kent asked me to come back with a
more extensive discussion report on this issue with rationales, problems
and solutions.<br>
<br>
Since last&nbsp; IETF I have worked on this from time to time with an
informal group of peoples from other vendors who may want to make them
self known at their own discretion.<br>
<br>
The result of this discussion is this report that I propose to be the
starting point of a new RFC to be developed in PKIX.<br>
<br>
/Stefan Santesson<br>
<br>
<br>
<font face="Courier New, Courier">Report on Logotypes in X.509
Certificates<br>
<br>
1. Rationale<br>
The basic function of a certificate is to bind a public key to an entity
(subject). From a strict technical viewpoint that would be satisfied by
just signing the identity of the subject together with its public key.
The art of PKI have however developed certificates far beyond this
functionality in order to meet the needs from modern global networks and
heterogeneous IT structures.<br>
<br>
A primary driver of the evolution from simple certificate formats to more
complex structures is the need to distinguish between different
certificate concepts, defining everything from assurance level, policies
and procedures, fields of usage to name forms and semantics. Before a
relying party can make an informed decision whether a particular
certificate is trustworthy and relevant for its intended usage, a large
number of aspects of the certificate may have to be processed.<br>
<br>
All of these aspects of certificates do mainly concern systematic
processing in order to deliver a distinct Yes or No answer to the
question whether the certificate match predefined prerequisites and
thereby is regarded as appropriate for its intended usage. Even though
these information objects in certificates are appropriate and effective
for machine processing, they are poor instruments for a corresponding
human trust and recognition process.<br>
<br>
The human mind prefer to structure information into categories and
symbols. Complex structures of reality are encapsulated in easy
recognizable logotypes and marks. The human trust process is to a smaller
extent based on information and to a greater extent based on recognition
and experience. Very few consumers actually read all terms and conditions
they accept when accepting a service, instead they most commonly act in
trust based on experience and recognition.<br>
<br>
A big part of this process is branding, where service providers invest a
lot of money and resources into creating a strong relation between
positive user experiences and easily recognizable trademarks and
logotypes. <br>
<br>
This reality also extends to the realm of concepts, services and
instruments for identification, ranging from ID-cards, passports and
driver’s licenses to credit cards, gasoline cards and loyalty cards etc,
whose function is to identify an entity either as a person or as member
of community, subscriber of a service, etc. These concepts and
instruments of identification in physical form have in common the use
logotypes and symbols, solely aimed to enhance human recognition and
trust in the underlying concept.<br>
<br>
As certificates play an equivalent role in electronic exchange, to the
use of physical ID’s in physical exchange, some important questions
deserves closer attention in the investigation whether the use of
logotypes in certificates are relevant or not.<br>
<br>
1.1 Are human recognition concepts relevant in electronic forms of
identification?<br>
<br>
The answer depends on the answer to the fundamental underlying question
whether certificates should be visible or invisible to human users and if
certificates will be used in open environments.<br>
<br>
If certificates are to be used in open environments and in applications
that brings the user in conscious contact with the result of a
certificate based identification process, then human recognition of
concept is highly relevant, and may even be a necessity.<br>
<br>
Examples of applications of these types are:<br>
&nbsp; - Web server identification where a user identifies the owner of
the web site.<br>
&nbsp; - Peer entity e-mail exchange (in B2B, B2C and private
communication exchange).<br>
&nbsp; - Other profession information processing and message exchange
systems (such as medical records handling, and system for medical
prescriptions)<br>
&nbsp; - Unstructured e-business applications (i.e. non EDI
applications)<br>
<br>
Most applications that offer the user to view the result of a certificate
based identification process do this by allowing the user to view the
certificate of the identified entity. This solution has however two major
problems.<br>
<br>
&nbsp; 1) The function to view a certificate is often rather hard to find
for a non-technical user.<br>
&nbsp; 2) The presentation of the certificate is rather technical and not
user friendly. Further it contains no graphic symbols and logotypes to
enhance human recognition.<br>
<br>
Many investigations have shown that users in current applications don’t
“click” to view certificates. There is however a distinct possibility
that this fact is due to how applications are structured and due to very
poor user interfaces, much more than a proof that certificates should not
be exposed to users at all.<br>
<br>
1.2 Can the concepts of systematic verification processing and human
recognition be combined in any sensible manner?<br>
<br>
Systematic verification of a certificate (including systematic
verification of all certificates in the path built up to a trusted root)
will at most give a user/system either the result “Verified according to
defined policy” or “Failed verification according to defined policy”.
<br>
<br>
The systematic processing has in this case provided the user/system with
assurance that the certificate is a valid document, but not who the
subject of the certificate in fact is or what that entity is
entitled/trusted to do. The latter is the task of an access control
function, which may again be a systematic process or in fact a human
recognition process, all dependent on application context.<br>
<br>
So in some situations a human person will be the sole handler of the post
verification process of identification and authorization. It may in the
end be a human decision to accept, act on or release information based on
who and/or what the opponent is and whom he/she represents.<br>
<br>
The conclusion is that the distinction between systematic processing and
human processing is rather straightforward and clear and has the
character of being complementary rather than interfering. While the
systematic process is focused on path processing and verification, the
human acceptance process is focused on identification, recognition and
authorization. <br>
<br>
Some interference issues do however exist as handled under security
considerations section.<br>
<br>
2. Different types of logotypes in certificates<br>
This report recommends standardized supported usage of 3 types of
logotypes in certificates.<br>
<br>
&nbsp; 1) Concept logotype<br>
&nbsp; 2) Issuer organization logotype<br>
&nbsp; 3) Subject organization logotype<br>
<br>
The concept logotype - is the general mark for a service concept for
entity identification and certificate issuance. Many issuers may use the
concept logotypes to co-brand with a global concept in order to gain
global recognition of its local service provision. This type of concept
branding is very common in credit card business where local independent
card issuers issue cards within a globally branded concept (such as VISA
and. MasterCard etc.).<br>
<br>
Issuer organization logotype - is a logotype representing the
organization identified as part of the issuer name in the
certificate.<br>
<br>
Subject organization logotype - is a logotype representing the
organization identified in the subject name in the certificate.<br>
<br>
3. Technical solutions<br>
3.1 General<br>
A general conclusion is that there is no need to include any logotype
image data in a certificate.<br>
<br>
The same function may be achieved by including a hash of the logotype
image in the certificate together with a URI/ URL identifying the
location of the logotype image data. Applications may enhance processing
and off-line functionality by cashing logotype data. <br>
<br>
Other minor aspects are:<br>
&nbsp; - that the URL also defines the file format for the image
data.<br>
&nbsp; - that the solution includes algorithm information about the
employed hash algorithm.<br>
<br>
The initially proposed general structure for logotype data is:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LogotypeData ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
typeOfLogotype&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TypeOflogotype,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
hashAlgorithm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AlgorithmIdentifier,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
logotypeDataHash&nbsp;&nbsp;&nbsp;&nbsp; OCTET STRING,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sourceDataUri&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IA5String
OPTIONAL }<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TypeOflogotype ::= CHOICE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
predefinedLogotypeType&nbsp;&nbsp;&nbsp; PredefinedLogotypeType,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
LogotypeTypeID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OBJECT IDENTIFIER }<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PredefinedLogotypeType ::= INTEGER { 
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
subject-organization-logotype(0),<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
issuer-organization-logotype(1)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
concept-logotype(2)} <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(subject-organization-logotype|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
issuer-organization-logotype|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
concept-logotype,...)<br>
<br>
<br>
The predefined logotype types are<br>
<br>
subject-organization-logotype, if used, SHALL be used to include a
logotype of the subject organization. The logotype SHALL be consistent
with, and require the presence of, an organization name stored in the
organization attribute in the subject field.<br>
<br>
issuer-organization-logotype, if used, SHALL be used to include a
logotype of the issuer organization. The logotype SHALL be consistent
with, and require the presence of, an organization name stored in the
organization attribute in the issuer field.<br>
<br>
Concept-logotype, if used, SHALL be used to include a logotype
representing the concept under which the issuer claims to issue this
certificate.<br>
<br>
<br>
A concept may be shared within a network of CA services, provided by one
or several independent CA organizations.<br>
<br>
The relationship between the subject organization and the subject
organization logotype and the relationship between the issuer and either
the issuer organization logotype or the concept logotype, are
relationships claimed by the issuer. The policy under which the issuer
checks these logotypes is outside the scope of this standard. <br>
<br>
Any URI pointing to a file containing the logotype data SHALL include a
file extension defining the file format (i.e. .GIF, .TIF, .JPG 
etc.)<br>
<br>
<br>
3.2 Type of certificates<br>
Logotypes according to the present model may be used in 3 types of
certificates:<br>
&nbsp; - Selfsigned CA certificates (root certificates)<br>
&nbsp; - Intermediate CA certificates<br>
&nbsp; - End entity certificates<br>
<br>
A reason to constrain inclusion of logotypes to end entity certificates
would be to exclude the aspect of logotypes from path processing issues,
where a path validating service would want to check consistency of
logotypes in a chain.<br>
<br>
However, as discussed in the rationale, logotypes are not aimed to be
part of path validation or any type of systematic processing since its
sole purpose is to enhance display of a single particular certificate to
a user regardless of its position or function in a path construct.<br>
<br>
The conclusions are:<br>
&nbsp; - Logotypes should not be an active component in path
processing.<br>
&nbsp; - Logotypes should be allowed in all types of certificates, by the
choice of the CA.<br>
<br>
<br>
3.2 Place of inclusion<br>
So far there has been 3 solutions discussed regarding where to store
logotype data in certificates.<br>
<br>
&nbsp; - Inclusion in a policy qualifier<br>
&nbsp; - Inclusion in Issuer and Subject Alternative names
extensions<br>
&nbsp; - Inclusion in a separate private extension<br>
<br>
3.2.1 Qualifier<br>
This solution would include logotype data as a newly defined policy
qualifier.<br>
<br>
Pros:<br>
&nbsp; - This solution provides a mechanism to directly control the use
and display of logotypes under a particular policy<br>
<br>
Cons:<br>
&nbsp; - Current practice and standards (RFC 2459) recommends against use
of qualifiers<br>
&nbsp; - This is generally considered to be a major hack and stretch of
semantics, since this type of data doesn’t qualify a policy in any
way.<br>
<br>
3.2.2 Issuer and Subject Alt Names<br>
This solution would use the other name form to include; <br>
&nbsp; - issuer and concept logotypes in the issuer alt name extension;
and <br>
&nbsp; - subject organization logo in the subject alt name
extension.<br>
<br>
Pros:<br>
&nbsp; - This mechanism could possibly enable cross certifying CAs to
deny any subordinate CA the right to include logotypes in descending end
entity certificates by listing the logotypes name form in
excludedSubtrees. <br>
<br>
Cons:<br>
&nbsp; - Logotypes are not a name form and can’t be treated as a
displayable name.<br>
&nbsp; - It is generally understood that it should be possible to apply
general name constraint mechanisms (as described in RFC 2459 as well as
son of RFC 2459) to names in the subject and issuer alt name ext. This is
however not possible to do with logotypes due to it’s non-name 
form.<br>
&nbsp; - This split storage of logotype data into 2 different locations,
which may make life worse for applications with no interest in
logotypes.<br>
&nbsp; - It is generally agreed that inclusion of logotype data by no
means should be regarded as critical data. This may interfere with the
criticality policy of the alt name extensions, especially if the
certificate has no attributes in the subject field, forcing the subject
alt name to be set to critical.<br>
&nbsp; - This usage would possibly interfere with the resolution between
IETF and ITU-T regarding use of permitted subtrees.<br>
&nbsp; - Since this solution may break current implementations it would
possibly block adoption of logotypes.<br>
<br>
<br>
3.2.3 New extension<br>
This solution would create a new private (non critical) extension.<br>
<br>
logotypeInfo&nbsp; EXTENSION ::= {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
LogotypeSyntax<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IDENTIFIED
BY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; id-pe-logotypeInfo }<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; id-pe-logotypeInfo OBJECT IDENTIFIER&nbsp;
::= {id-pe XX}<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LogotypeSyntax ::= SEQUENCE OF
LogotypeData<br>
<br>
<br>
Pros:<br>
&nbsp; - This is the cleanest solution. </font>
<dl><font face="Times New Roman, Times">
<dd>-<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face="Courier New, Courier">Do
not impact on legacy implementations.<br>
<br>

</dl>Cons:<br>
&nbsp; - This solution activates the issue whether this extension may be
abused by a CA who include logotypes (in EE certificates) that violates
the intention of a name constraints set by a chaining CA. This issue is
addressed in the security consideration section below.<br>
<br>
3.2.4 Conclusion<br>
The criteria for selecting a solution must be that it doesn’t destroy
current structures and doesn’t create problems and confusion.<br>
<br>
Only the private extension solution meets this criterion and should
therefore be selected.<br>
<br>
4. Use in Clients<br>
All PKI implementations require that relying party software have some
mechanism to determine whether a trusted CA issues a particular
certificate. This is an issue for path validation of the certificate
chain from a trusted root, including consistent policy and name
checking.<br>
<br>
After passing this process, the general assumption must be that the CA is
trusted to certify the information carried in any certificate extensions,
given that the client decides to use that information. The assumption is
regarded as general due to the fact that current standards do not provide
any mechanism for cross-certifying CAs to constrain subordinate CAs from
including private extensions (see security considerations).<br>
<br>
Consequently, if relying party software accepts a CA, then it should be
prepared to (unquestioningly) display the associated logos to its human
user, given that it is configured to do so.<br>
<br>
5. Security considerations<br>
Logotypes are even worse than names regarding the possibility to securely
and accurately define what is, and what is not, a legitimate logotype of
an organization. There is a whole legal structure around this issue that
doesn’t need repetition in this report.<br>
<br>
As logotypes are hard (and sometimes expensive) to verify, this increases
the possibility of errors related to falsely assigning wrong logotypes to
organizations. <br>
<br>
This is however not a new issue for electronic identification
instruments, but rather a well known problem that is already dealt with
in numerous of similar situations in the physical world, including
physical employment ID cards. Secondly there are situations where
identification of logotypes is rather simple and straight forward, such
as logotypes for well-known industries and institutes. These issues
should not be stopping those service providers wanting to go into the
issue of logotypes from doing so, where this is relevant.<br>
<br>
The new problem related to electronic identification instruments in the
form of certificates are however that certificate chains may impose
constraints that are systematically checked in path processing
algorithms, which in theory may be violated by logotypes. <br>
<br>
Path processing algorithms does not, should not, and will never be able
to control if any logotype included in any certificate violates any such
constraints. I.e. a chaining CA may constraint subordinate CAs to only
issue certificates to end entities within a limited name space. A
potentially bad CA may comply with this constraint in included names but
may still include a subject organization logotype that gives a relying
party the impression that the subject is part of another organization or
being part of a group of companies, which exceeds the freedom in the name
constraint.<br>
<br>
This is however nothing unique with a logotype extension, but a general
problem with X.509. The fact is that a chaining CA has no absolute
technical control over subordinate CAs behaviour with respect to
inclusion of new private extensions that may violate any policy or
constraint set in a chaining certificate.<br>
<br>
The controls available to a chaining CA to protect itself against bad CAs
are mainly:<br>
&nbsp; - Contractual agreements of suitable behaviour, including terms of
liability and severance pay in case of material breach.<br>
&nbsp; - Control mechanisms and procedures to monitor and follow-up
behaviour of subordinate CAs<br>
&nbsp; - Use of certificate policies to declare assurance level of
logotype data as well as to guide applications on how to treat and
display logotypes.&nbsp; <br>
&nbsp; - Use of revocation functions to revoke any misbehaving CA.<br>
&nbsp; <br>
This may not be an issue that can be given an easy and absolute technical
solution. Maybe the correct response is to surrender to the fact that
involved parties must settle some aspects of PKI outside the scope of
technical controls, and to clearly identify and communicate the
associated risks with that.<br>
<br>
<br>
</font></html>

--=====================_966242122==_.ALT--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BFj7Q25819 for ietf-pkix-bks; Wed, 11 Jul 2001 08:45:07 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BFj5m25810 for <[e-mail]>; Wed, 11 Jul 2001 08:45:05 -0700 (PDT)
Received: from [128.33.84.34] (comsec.bbn.com [128.33.84.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23421; Wed, 11 Jul 2001 11:46:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05010401b772240e7d74@[128.33.84.34]>
In-Reply-To:  <[e-mail].n et>
References:  <[e-mail].n et>
Date: Wed, 11 Jul 2001 11:43:28 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new-part1-08.txt)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 3:19 PM +0000 7/11/01, [e-mail] wrote:
>No, what I want is for the protocol to not mandate that
>I go to a third party to use it.
>

Todd,

We have a number of protocols in the IETF that make use of OIDs and 
they all make the assumption that someone who wants a new OID will go 
through the process of getting it assigned under some arc that is 
part of the global registration system, to avoid collisions.  People 
have been able to deal with this model for a number of years and 
although it is not perfect, the problems people have had are not the 
one you allude to.  We're not going to change the model now.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BFKTT21426 for ietf-pkix-bks; Wed, 11 Jul 2001 08:20:29 -0700 (PDT)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BFJ7m21335 for <[e-mail]>; Wed, 11 Jul 2001 08:19:07 -0700 (PDT)
Received: from webmail.worldnet.att.net ([204.127.135.58]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Wed, 11 Jul 2001 15:19:03 +0000
Received: from [161.215.27.111] by webmail.worldnet.att.net; Wed, 11 Jul 2001 15:19:02 +0000
From: [e-mail]
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Subject: Re: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new-part1-08.txt)
Date: Wed, 11 Jul 2001 15:19:02 +0000
X-Mailer: AT&T Message Center Version 1 (May  2 2001)
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

No, what I want is for the protocol to not mandate that 
I go to a third party to use it.

T.

--
Regards,
Todd
> Todd:
> 
> We agree that no PUBLIC registration is needed.  However, the coding that 
> you suggest to handle OID collisions is likely to be error prone.
> 
> You say that you have several PEN arcs.  If you assign an OID from one of 
> those, it will be unique (unless you are sloppy and use the same one for 
> more than one purpose).  You do not have to tell anyone that you made the 
> assignment, the associated syntax, or the associated semantics.  Just use 
> it in your application.  As long as the extension is marked non-critical, 
> it will be ignored by everyone else.  If the extension is marked critical, 
> everyone else will reject the certificate -- maybe that is what you want.
> 
> Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BETUC19605 for ietf-pkix-bks; Wed, 11 Jul 2001 07:29:30 -0700 (PDT)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BETSm19601 for <[e-mail]>; Wed, 11 Jul 2001 07:29:28 -0700 (PDT)
Received: from webmail.worldnet.att.net ([204.127.135.58]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Wed, 11 Jul 2001 14:29:19 +0000
Received: from [161.215.27.111] by webmail.worldnet.att.net; Wed, 11 Jul 2001 14:29:19 +0000
From: [e-mail]
To: "Bland, Graham" <[e-mail]>
Cc: [e-mail]
Subject: RE: New draft of son-of-2459 (Was: I-D  ACTION:draft-ietf-pkix-ne w-part1-08.txt)
Date: Wed, 11 Jul 2001 14:29:19 +0000
X-Mailer: AT&T Message Center Version 1 (May  2 2001)
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

By the way - I do agree that in the instances where 
local registration, is required that you are dead on in 
that it likely need only extend down to the org's ARC.


--
Regards,
Todd
> Todd,
> 
> Surely the registration here for private use need only extend down to the
> private arc of the controlling organisation.  If corporation X has an arc
> registered then it can maintain uniqueness within this arc without
> registering each full OID separately.
> 
> If it is making a unique OID public then it should be registered as part of
> the publication process. If it is for private use then registration is not
> needed, just an agreement between the parties within the private
> implementations.
> 
> 
> Graham Bland
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: 10 July 2001 16:17
> > To: Anders Rundgren
> > Cc: [e-mail]; Tim Polk
> > Subject: Re: New draft of son-of-2459 (Was: I-D
> > ACTION:draft-ietf-pkix-new-part1-08.txt)
> > 
> > 
> > 
> > Two points - the first is the pushback on the 
> > work "methods". I believe that the term "features" is 
> > better here, and to the second question... if the 
> > methods are private why is there any need to register 
> > them. The only need I can see in issuing a publicly 
> > available OID is if there are publicly linked 
> > participants of unknow origins and as such would need 
> > some way of registering these "OID's" locally.
> > 
> > T.
> > --
> > Regards,
> > Todd
> > > 
> > > "4.2  Certificate Extensions
> > > 
> > >    The extensions defined for X.509 v3 certificates provide 
> > methods for
> > >    associating additional attributes with users or public 
> > keys and for
> > >    managing the certification hierarchy.  The X.509 v3 certificate
> > >    format also allows communities to define private 
> > extensions to carry
> > >    information unique to those communities."
> > > 
> > > Then there is a section Private Internet Extesions where 
> > two specific
> > > extension are specified.  I assume that this is the same as 
> > the private
> > > extensions mentioned above.
> > > 
> > > Question: How are arbitrary private extensions supposed to be added?
> > > You must register/define an OID?
> > > 
> > > Regards
> > > Anders R
> > > 
> > > 
> > > 
> > 
> _______________________________________________________________________
> 
> This message is confidential and is intended for the addressee only;
> unless clearly stated that this disclaimer should not apply, this 
> e-mail is not intended to create legally binding commitments on 
> behalf of any company in the British Interactive Broadcasting 
> Holdings Limited group,  nor do its contents reflect the corporate 
> views or policies of any such company. Any unauthorised disclosure, 
> use or dissemination, either whole or partial, is prohibited. If you 
> are not the intended recipient of the message, please notify the
> sender immediately.
> _______________________________________________________________________


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BES2n19573 for ietf-pkix-bks; Wed, 11 Jul 2001 07:28:02 -0700 (PDT)
Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BES0m19569 for <[e-mail]>; Wed, 11 Jul 2001 07:28:00 -0700 (PDT)
Received: from webmail.worldnet.att.net ([204.127.135.58]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Wed, 11 Jul 2001 14:27:56 +0000
Received: from [161.215.27.111] by webmail.worldnet.att.net; Wed, 11 Jul 2001 14:27:56 +0000
From: [e-mail]
To: "Bland, Graham" <[e-mail]>
Cc: [e-mail]
Subject: RE: New draft of son-of-2459 (Was: I-D  ACTION:draft-ietf-pkix-ne w-part1-08.txt)
Date: Wed, 11 Jul 2001 14:27:56 +0000
X-Mailer: AT&T Message Center Version 1 (May  2 2001)
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Graham - the issue is that in some application contexts 
that OID values can and will be hard coded into the 
applications that use them.

For that reason alone it is not smart to constrain the 
protocol use to mandate it. Rather it should be left 
optional and a method of OID corruption or collision 
detection be added if you are so inclined. Otherwise 
there is a mandated need to go to the TTP (the ARC) to 
get the OID identified and that - err well.

The point is that this again is an instance where the 
application that uses the process should be making these 
decisions. Or is it that it is PKIX's opinion that app 
developers are incompetent to do so and must be 
protected from this potential?

--
Regards,
Todd
> Todd,
> 
> Surely the registration here for private use need only extend down to the
> private arc of the controlling organisation.  If corporation X has an arc
> registered then it can maintain uniqueness within this arc without
> registering each full OID separately.
> 
> If it is making a unique OID public then it should be registered as part of
> the publication process. If it is for private use then registration is not
> needed, just an agreement between the parties within the private
> implementations.
> 
> 
> Graham Bland
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: 10 July 2001 16:17
> > To: Anders Rundgren
> > Cc: [e-mail]; Tim Polk
> > Subject: Re: New draft of son-of-2459 (Was: I-D
> > ACTION:draft-ietf-pkix-new-part1-08.txt)
> > 
> > 
> > 
> > Two points - the first is the pushback on the 
> > work "methods". I believe that the term "features" is 
> > better here, and to the second question... if the 
> > methods are private why is there any need to register 
> > them. The only need I can see in issuing a publicly 
> > available OID is if there are publicly linked 
> > participants of unknow origins and as such would need 
> > some way of registering these "OID's" locally.
> > 
> > T.
> > --
> > Regards,
> > Todd
> > > 
> > > "4.2  Certificate Extensions
> > > 
> > >    The extensions defined for X.509 v3 certificates provide 
> > methods for
> > >    associating additional attributes with users or public 
> > keys and for
> > >    managing the certification hierarchy.  The X.509 v3 certificate
> > >    format also allows communities to define private 
> > extensions to carry
> > >    information unique to those communities."
> > > 
> > > Then there is a section Private Internet Extesions where 
> > two specific
> > > extension are specified.  I assume that this is the same as 
> > the private
> > > extensions mentioned above.
> > > 
> > > Question: How are arbitrary private extensions supposed to be added?
> > > You must register/define an OID?
> > > 
> > > Regards
> > > Anders R
> > > 
> > > 
> > > 
> > 
> _______________________________________________________________________
> 
> This message is confidential and is intended for the addressee only;
> unless clearly stated that this disclaimer should not apply, this 
> e-mail is not intended to create legally binding commitments on 
> behalf of any company in the British Interactive Broadcasting 
> Holdings Limited group,  nor do its contents reflect the corporate 
> views or policies of any such company. Any unauthorised disclosure, 
> use or dissemination, either whole or partial, is prohibited. If you 
> are not the intended recipient of the message, please notify the
> sender immediately.
> _______________________________________________________________________


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BEL7O19416 for ietf-pkix-bks; Wed, 11 Jul 2001 07:21:07 -0700 (PDT)
Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BEJkm19381 for <[e-mail]>; Wed, 11 Jul 2001 07:19:46 -0700 (PDT)
Received: from webmail.worldnet.att.net ([204.127.135.58]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Wed, 11 Jul 2001 14:19:32 +0000
Received: from [161.215.27.111] by webmail.worldnet.att.net; Wed, 11 Jul 2001 14:19:31 +0000
From: [e-mail]
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Subject: Re: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new-part1-08.txt)
Date: Wed, 11 Jul 2001 14:19:31 +0000
X-Mailer: AT&T Message Center Version 1 (May  2 2001)
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--
Regards,
Todd
> Todd:
> 
> No.

Yes! 

> 
> The process of obtaining an OID must ensure that the same OID is not used 
> for two different extensions.  If this where to happen, then a replying 
> party could not know which syntax or semantics to apply to the extension in 
> a particular certificate.

And this could easily be done by an agreement by two individuals or the code 
they are running at either end of the transaction. Or more importantly
by the apps being run at both ends.

> 
> I never said that the registration process had to lead to publication of 
> the OID, the associated syntax, or the associated semantics.  I did say, 
> and remain adamant, that OID use collisions must be avoided.

No again - what needs to happen is that the App must be coded to deal with
OID collisions not the protocol. 
But that's the whole point. The registration process is 
only necessary if the Use Model requires an external 
"lookup step"... What if the OID itself carries
privacy protected information? As a CERT extension 
this is actually a real potential and mandating that it be
a public process has some strange implications for limiting 
the scope of "Son Of..."

Look - If the app that is using the cert has 
the OID constructs it uses hard coded into it then... no public registration
is needed.


> 
> Russ
> 
> At 11:29 PM 7/10/2001 +0000, [e-mail] wrote:
> >Russ I am aware of OID registration, I have several PEN
> >OIDs myself.
> >
> >The point is that if
> >
> >1)  this is an OID that is only used within a closed
> >environment there is no need to keep anyone else from
> >using it.
> >
> >2)  If you are referring to a process for propagating an
> >OID so that both users could have the same definition on
> >the OID they are using, then that is a good idea but
> >that is not per se "registration".
> >
> >So I disagree with your commentary and pushback. What I
> >feel you are referring to is an arbitrary need
> >to "register all OIDs" as in with the IANA rather than a
> >method of OID content negotiation and IMHO I will
> >continue to disagree with your commentary.
> >
> >--
> >Regards,
> >Todd
> > >
> > > Todd:
> > >
> > > The point is that a unique OID must be used.
> >
> >Not true. If I have an OID and it is a private
> >system I can do whatever I want with that OID.
> >I do not need IANA or anyone else besides my
> >private use partners to tell me what the OID means.
> >
> > > Registration is the process
> > > used to obtain the unique OID, even if the resulting OID is not published
> > > in any public manner.
> > >
> > > Russ
> > >
> > >
> > > At 03:16 PM 7/10/2001 +0000, [e-mail] wrote:
> > >
> > > >Two points - the first is the pushback on the
> > > >work "methods". I believe that the term "features" is
> > > >better here, and to the second question... if the
> > > >methods are private why is there any need to register
> > > >them. The only need I can see in issuing a publicly
> > > >available OID is if there are publicly linked
> > > >participants of unknow origins and as such would need
> > > >some way of registering these "OID's" locally.
> > > >
> > > >T.
> > > >--
> > > >Regards,
> > > >Todd
> > > > >
> > > > > "4.2  Certificate Extensions
> > > > >
> > > > >    The extensions defined for X.509 v3 certificates provide methods for
> > > > >    associating additional attributes with users or public keys and for
> > > > >    managing the certification hierarchy.  The X.509 v3 certificate
> > > > >    format also allows communities to define private extensions to carry
> > > > >    information unique to those communities."
> > > > >
> > > > > Then there is a section Private Internet Extesions where two specific
> > > > > extension are specified.  I assume that this is the same as the private
> > > > > extensions mentioned above.
> > > > >
> > > > > Question: How are arbitrary private extensions supposed to be added?
> > > > > You must register/define an OID?
> > > > >
> > > > > Regards
> > > > > Anders R
> > > > >
> > > > >
> > > > >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6B7qiD04330 for ietf-pkix-bks; Wed, 11 Jul 2001 00:52:44 -0700 (PDT)
Received: from claudio.bib.co.uk (gateway.bib.co.uk [195.171.24.2]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6B7qgm04326 for <[e-mail]>; Wed, 11 Jul 2001 00:52:42 -0700 (PDT)
Received: from 127.0.0.1 by claudio.bib.co.uk (InterScan E-Mail VirusWall NT); Wed, 11 Jul 2001 08:52:26 +0100 (GMT Daylight Time)
Received: by claudio with Internet Mail Service (5.5.2653.19) id <3GDWPAKX>; Wed, 11 Jul 2001 08:52:26 +0100
Message-ID: <36086CC80304D3119B040008C75DF59604943628@claudio>
From: "Bland, Graham" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: New draft of son-of-2459 (Was: I-D  ACTION:draft-ietf-pkix-ne w-part1-08.txt)
Date: Wed, 11 Jul 2001 08:52:19 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Todd,

Surely the registration here for private use need only extend down to the
private arc of the controlling organisation.  If corporation X has an arc
registered then it can maintain uniqueness within this arc without
registering each full OID separately.

If it is making a unique OID public then it should be registered as part of
the publication process. If it is for private use then registration is not
needed, just an agreement between the parties within the private
implementations.


Graham Bland


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 10 July 2001 16:17
> To: Anders Rundgren
> Cc: [e-mail]; Tim Polk
> Subject: Re: New draft of son-of-2459 (Was: I-D
> ACTION:draft-ietf-pkix-new-part1-08.txt)
> 
> 
> 
> Two points - the first is the pushback on the 
> work "methods". I believe that the term "features" is 
> better here, and to the second question... if the 
> methods are private why is there any need to register 
> them. The only need I can see in issuing a publicly 
> available OID is if there are publicly linked 
> participants of unknow origins and as such would need 
> some way of registering these "OID's" locally.
> 
> T.
> --
> Regards,
> Todd
> > 
> > "4.2  Certificate Extensions
> > 
> >    The extensions defined for X.509 v3 certificates provide 
> methods for
> >    associating additional attributes with users or public 
> keys and for
> >    managing the certification hierarchy.  The X.509 v3 certificate
> >    format also allows communities to define private 
> extensions to carry
> >    information unique to those communities."
> > 
> > Then there is a section Private Internet Extesions where 
> two specific
> > extension are specified.  I assume that this is the same as 
> the private
> > extensions mentioned above.
> > 
> > Question: How are arbitrary private extensions supposed to be added?
> > You must register/define an OID?
> > 
> > Regards
> > Anders R
> > 
> > 
> > 
> 
_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ANTWG09024 for ietf-pkix-bks; Tue, 10 Jul 2001 16:29:32 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ANTUm09020 for <[e-mail]>; Tue, 10 Jul 2001 16:29:30 -0700 (PDT)
Received: from webmail.worldnet.att.net ([204.127.135.43]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Tue, 10 Jul 2001 23:29:28 +0000
Received: from [161.215.27.111] by webmail.worldnet.att.net; Tue, 10 Jul 2001 23:29:28 +0000
From: [e-mail]
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Subject: Re: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new-part1-08.txt)
Date: Tue, 10 Jul 2001 23:29:28 +0000
X-Mailer: AT&T Message Center Version 1 (May  2 2001)
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ I am aware of OID registration, I have several PEN 
OIDs myself. 

The point is that if 

1)  this is an OID that is only used within a closed 
environment there is no need to keep anyone else from 
using it. 

2)  If you are referring to a process for propagating an 
OID so that both users could have the same definition on 
the OID they are using, then that is a good idea but 
that is not per se "registration".

So I disagree with your commentary and pushback. What I 
feel you are referring to is an arbitrary need 
to "register all OIDs" as in with the IANA rather than a 
method of OID content negotiation and IMHO I will 
continue to disagree with your commentary.

--
Regards,
Todd
> 
> Todd:
> 
> The point is that a unique OID must be used.  

Not true. If I have an OID and it is a private 
system I can do whatever I want with that OID. 
I do not need IANA or anyone else besides my 
private use partners to tell me what the OID means.

> Registration is the process 
> used to obtain the unique OID, even if the resulting OID is not published 
> in any public manner.
> 
> Russ
> 
> 
> At 03:16 PM 7/10/2001 +0000, [e-mail] wrote:
> 
> >Two points - the first is the pushback on the
> >work "methods". I believe that the term "features" is
> >better here, and to the second question... if the
> >methods are private why is there any need to register
> >them. The only need I can see in issuing a publicly
> >available OID is if there are publicly linked
> >participants of unknow origins and as such would need
> >some way of registering these "OID's" locally.
> >
> >T.
> >--
> >Regards,
> >Todd
> > >
> > > "4.2  Certificate Extensions
> > >
> > >    The extensions defined for X.509 v3 certificates provide methods for
> > >    associating additional attributes with users or public keys and for
> > >    managing the certification hierarchy.  The X.509 v3 certificate
> > >    format also allows communities to define private extensions to carry
> > >    information unique to those communities."
> > >
> > > Then there is a section Private Internet Extesions where two specific
> > > extension are specified.  I assume that this is the same as the private
> > > extensions mentioned above.
> > >
> > > Question: How are arbitrary private extensions supposed to be added?
> > > You must register/define an OID?
> > >
> > > Regards
> > > Anders R
> > >
> > >
> > >


Received: by above.proper.com (8.11.3/8.11.3) id f6AHdxw27561 for ietf-pkix-bks; Tue, 10 Jul 2001 10:39:59 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6AHdvm27550 for <[e-mail]>; Tue, 10 Jul 2001 10:39:58 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Jul 2001 17:38:31 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA02529 for <[e-mail]>; Tue, 10 Jul 2001 13:39:58 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TP5R1>; Tue, 10 Jul 2001 13:39:56 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TP5RD; Tue, 10 Jul 2001 13:39:53 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 10 Jul 2001 13:37:43 -0400
Subject: Re: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new-part1-08.txt)
In-Reply-To: <20010710151639.KFUB3707.mtiwmhc24.worldnet.att.net@webmail .worldnet.att.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Todd:

The point is that a unique OID must be used.  Registration is the process 
used to obtain the unique OID, even if the resulting OID is not published 
in any public manner.

Russ


At 03:16 PM 7/10/2001 +0000, [e-mail] wrote:

>Two points - the first is the pushback on the
>work "methods". I believe that the term "features" is
>better here, and to the second question... if the
>methods are private why is there any need to register
>them. The only need I can see in issuing a publicly
>available OID is if there are publicly linked
>participants of unknow origins and as such would need
>some way of registering these "OID's" locally.
>
>T.
>--
>Regards,
>Todd
> >
> > "4.2  Certificate Extensions
> >
> >    The extensions defined for X.509 v3 certificates provide methods for
> >    associating additional attributes with users or public keys and for
> >    managing the certification hierarchy.  The X.509 v3 certificate
> >    format also allows communities to define private extensions to carry
> >    information unique to those communities."
> >
> > Then there is a section Private Internet Extesions where two specific
> > extension are specified.  I assume that this is the same as the private
> > extensions mentioned above.
> >
> > Question: How are arbitrary private extensions supposed to be added?
> > You must register/define an OID?
> >
> > Regards
> > Anders R
> >
> >
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AFdbV20716 for ietf-pkix-bks; Tue, 10 Jul 2001 08:39:37 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6AFdZm20706 for <[e-mail]>; Tue, 10 Jul 2001 08:39:36 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Jul 2001 15:38:09 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA21301; Tue, 10 Jul 2001 11:39:36 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <LR8TPYNB>; Tue, 10 Jul 2001 11:39:34 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LR8TPYNA; Tue, 10 Jul 2001 11:39:31 -0400
From: "Housley, Russ" <[e-mail]>
To: Anders Rundgren <[e-mail]>
Cc: [e-mail], Tim Polk <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 10 Jul 2001 11:39:25 -0400
Subject: Re: New draft of son-of-2459 (Was: I-D  ACTION:draft-ietf-pkix-new-part1-08.txt)
In-Reply-To: <00c201c10941$99da7680$0500a8c0@arport>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Anders:

Use of private extensions is discouraged (especially critical ones).

You can assign the OIDs for private extensions from any arc that you 
control.  I strongly suspect that an organization like Telia already has an 
arc assigned.  Locating the registrar within Telia is left as an exercise 
to the reader.

Russ

At 03:09 PM 7/10/2001 +0200, Anders Rundgren wrote:

>"4.2  Certificate Extensions
>
>    The extensions defined for X.509 v3 certificates provide methods for
>    associating additional attributes with users or public keys and for
>    managing the certification hierarchy.  The X.509 v3 certificate
>    format also allows communities to define private extensions to carry
>    information unique to those communities."
>
>Then there is a section Private Internet Extesions where two specific
>extension are specified.  I assume that this is the same as the private
>extensions mentioned above.
>
>Question: How are arbitrary private extensions supposed to be added?
>You must register/define an OID?
>
>Regards
>Anders R


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AFGih17394 for ietf-pkix-bks; Tue, 10 Jul 2001 08:16:44 -0700 (PDT)
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AFGhm17387 for <[e-mail]>; Tue, 10 Jul 2001 08:16:43 -0700 (PDT)
Received: from webmail.worldnet.att.net ([204.127.135.60]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <[e-mail]>; Tue, 10 Jul 2001 15:16:39 +0000
Received: from [161.215.27.111] by webmail.worldnet.att.net; Tue, 10 Jul 2001 15:16:38 +0000
From: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>, "Tim Polk" <[e-mail]>
Subject: Re: New draft of son-of-2459 (Was: I-D  ACTION:draft-ietf-pkix-new-part1-08.txt)
Date: Tue, 10 Jul 2001 15:16:38 +0000
X-Mailer: AT&T Message Center Version 1 (May  2 2001)
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Two points - the first is the pushback on the 
work "methods". I believe that the term "features" is 
better here, and to the second question... if the 
methods are private why is there any need to register 
them. The only need I can see in issuing a publicly 
available OID is if there are publicly linked 
participants of unknow origins and as such would need 
some way of registering these "OID's" locally.

T.
--
Regards,
Todd
> 
> "4.2  Certificate Extensions
> 
>    The extensions defined for X.509 v3 certificates provide methods for
>    associating additional attributes with users or public keys and for
>    managing the certification hierarchy.  The X.509 v3 certificate
>    format also allows communities to define private extensions to carry
>    information unique to those communities."
> 
> Then there is a section Private Internet Extesions where two specific
> extension are specified.  I assume that this is the same as the private
> extensions mentioned above.
> 
> Question: How are arbitrary private extensions supposed to be added?
> You must register/define an OID?
> 
> Regards
> Anders R
> 
> 
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AESBn12853 for ietf-pkix-bks; Tue, 10 Jul 2001 07:28:11 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AES9m12848 for <[e-mail]>; Tue, 10 Jul 2001 07:28:10 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00846; Tue, 10 Jul 2001 10:27:19 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-03.txt
Date: Tue, 10 Jul 2001 10:27:19 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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		: Algorithms and Identifiers for the Internet X.509 
                          Public Key Infrastructure Certificate and CRI Profile
	Author(s)	: L. Bassham, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ipki-pkalgs-03.txt
	Pages		: 27
	Date		: 09-Jul-01
	
This document specifies algorithm identifiers and ASN.1 encoding
formats for digital signatures and subject public keys used in the
Internet X.509 Public Key Infrastructure (PKI).  Digital signatures
are used to sign certificates and certificate revocation lists
(CRLs).  Certificates include the public key of the named subject.

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f6ADJkl11080 for ietf-pkix-bks; Tue, 10 Jul 2001 06:19:46 -0700 (PDT)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ADJjm11076 for <[e-mail]>; Tue, 10 Jul 2001 06:19:45 -0700 (PDT)
Received: from arport ([212.181.94.147]) by maila.telia.com (8.11.2/8.11.0) with SMTP id f6ADJiJ15414; Tue, 10 Jul 2001 15:19:44 +0200 (CEST)
Message-ID: <00c201c10941$99da7680$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Tim Polk" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: New draft of son-of-2459 (Was: I-D  ACTION:draft-ietf-pkix-new-part1-08.txt)
Date: Tue, 10 Jul 2001 15:09:49 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"4.2  Certificate Extensions

   The extensions defined for X.509 v3 certificates provide methods for
   associating additional attributes with users or public keys and for
   managing the certification hierarchy.  The X.509 v3 certificate
   format also allows communities to define private extensions to carry
   information unique to those communities."

Then there is a section Private Internet Extesions where two specific
extension are specified.  I assume that this is the same as the private
extensions mentioned above.

Question: How are arbitrary private extensions supposed to be added?
You must register/define an OID?

Regards
Anders R





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f67EVR012109 for ietf-pkix-bks; Sat, 7 Jul 2001 07:31:27 -0700 (PDT)
Received: from sek11.acrosswireless.com ([213.212.5.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f67EVPm12104 for <[e-mail]>; Sat, 7 Jul 2001 07:31:25 -0700 (PDT)
Received: from sek11.acrosswireless.com ([127.0.0.1]) by sek11.acrosswireless.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 7 Jul 2001 16:29:01 +0200
Received: from data1 ([213.212.5.230]:12095) (HELO acrossw01.acrosswireless.com) by sek11.acrosswireless.com ([192.168.1.11]:25) (F-Secure Anti-Virus for Internet Mail 5.0.53 Release) with SMTP; Sat, 7 Jul 2001 14:29:01 -0000
Received: by acrossw01.acrosswireless.com with Internet Mail Service (5.5.2650.21) id <32RJZQ31>; Sat, 7 Jul 2001 16:28:52 +0200
Message-ID: <[e-mail]>
From: Olle Larsson <[e-mail]>
To: Olle Larsson <[e-mail]>, "'Trevor Freeman'" <[e-mail]>, Ambarish Malpani <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Should a CRL number be unique or not ?
Date: Sat, 7 Jul 2001 16:28:49 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
X-OriginalArrivalTime: 07 Jul 2001 14:29:01.0840 (UTC) FILETIME=[2AD26100:01C106F1]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

My apologies: scrap that. Mental meltdown...

/Olle

-----Original Message-----
From: Olle Larsson [mailto:[e-mail]]
Sent: Saturday, July 07, 2001 12:11 PM
To: 'Trevor Freeman'; Ambarish Malpani
Cc: '[e-mail]'
Subject: RE: Should a CRL number be unique or not ?




Trevor,

Constructing a local CRL like you say, ie by using the thisUpdate field
only, imposes a requirement that only one delta CRL may be issued per second
and issuer, as the date field doesn't come with a higher resolution than
that.

Is that really a fair requirement for a general internet PKI?
I doubt it.

/Olle

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: Friday, July 06, 2001 11:43 PM
To: Ambarish Malpani
Cc: [e-mail]
Subject: RE: Should a CRL number be unique or not ?


Ambrish,
Yes, I have considered that and I don't see it makes an impact on the
requiremtns for the CRL number extension in the delta CRL. You are just
pointing out that the delta CRL indicator extension in te delta CRL may
have the value of 11 in the example delta 2 rather than 10.

The assertion Dave made was that the CRL number extension (N.B. not the
delta CRL indicator extension) in the delta CRL was necessary for
applications trying to construct local CRLs. I don't think the CRL
number extension in the delta CRL helps.

Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Friday, July 06, 2001 11:52 AM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: Should a CRL number be unique or not ?



Trevor,
    If delta2 was off a base of CRLNumber 11, then you would need to
retrieve the full CRL for CRLNumber 11 - even thought CRLNumber 11 might
just be the combination of CRLNumber 10 + delta1

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 11:44 AM
> To: Ambarish Malpani; David P. Kemp
> Cc: [e-mail]
> Subject: RE: Should a CRL number be unique or not ?
> 
> 
> Hi Ambrish,
> I acknowledge the need for the delta CRL indicator extension in the 
> delta CRL which contains the CRL number of the base CRL. That is not 
> what I am talking about. I am talking about the CRL number extension 
> in the delta itself - which I agree is a common mistake to make. I 
> don't see the value of the CRL number extension in the delta CRL if 
> you are simply trying to establish the sequence of delta CRLs.
> 
> So equally
> base CRL, CRL number = 10
> 
> Delta1, delta CRL indecator = 10, this update = 12:00 pm
> 
> Delta2, delta CRL indeactor = 10, this update = 12:01pm
> 
> It is ovious which base number I need, and which is the freshest delta

> CRLs.
> 
> If I had an application building is own local database from
> delta CRLs,
> then it has all the information it needs.
> 
> Trevor
> 
> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 10:53 AM
> To: Trevor Freeman; David P. Kemp
> Cc: [e-mail]
> Subject: RE: Should a CRL number be unique or not ?
> 
> 
> 
> Hi Trevor,
>     I believe what Dave was trying to say, is that by having a 
> CRLNumber on the delta, you can know what your new effective base is,
> so that if the new delta is off a CRL at or before the new effective
> base, you can apply it to the locally created CRL data.
> 
> For example:
> 
> You get a full CRL with CRLNumber 10
> Get delta1 with a base of 10 and CRLNumber of 11
> Get delta2 with a base of 11 and a CRLNumber of 12
> 
> You can now apply delta2 to (CRLNumber 10 + delta1), without
> ever having
> had to get CRLNumber 11.
> 
> Hope this helps,
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> 
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[e-mail]]
> > Sent: Friday, July 06, 2001 9:09 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Should a CRL number be unique or not ?
> > 
> > 
> > Hi Dave,
> > 
> > I don't see the CRL number is that vital in the construction of a 
> > local CRL.
> > 
> > The application must start a db of s\n from a base CRL. Then the
> > application needs to update that DB by adding the list of 
> s\n from the
> 
> > next delta CRL. The "this update time" can be used to
> determine from a
> 
> > set of deltas, which is the oldest. The only reason you
> need to apply
> > them in sequence is because of the "remove from CRL" reason codes,
> > otherwise it would not matter. As you process the next 
> delta you will
> > get a number of "collisions", by design which you ignore,
> these will
> > be because have already either added or removed the s\n
> referenced in
> > the delta.
> > As a point of interest any application doing this behavior
> with delta
> > CRLs only, will start to diverge from applications using base
> > and delta
> > CRLs because what these applications will not do is purge s\n of
> > certificates which have expired. So technically speaking 
> they will not
> > contain identical information.
> > 
> > Trevor
> > 
> 
> ....[Bunch of stuff deleted]
>  
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f67Dlhj11687 for ietf-pkix-bks; Sat, 7 Jul 2001 06:47:43 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f67Dlfm11683 for <[e-mail]>; Sat, 7 Jul 2001 06:47:41 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <333TMQW0>; Sat, 7 Jul 2001 09:47:35 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Trevor Freeman <[e-mail]>, Ambarish Malpani <[e-mail]>
Cc: [e-mail]
Subject: RE: Should a CRL number be unique or not ?
Date: Sat, 7 Jul 2001 09:36:57 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: application/x-pkcs7-mime; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

MIJGtwYJKoZIhvcNAQcCoIJGqDCCRqQCAQExCzAJBgUrDgMCGgUAMII7NgYJKoZIhvcNAQcBoII7
JwSCOyNDb250ZW50LVR5cGU6IG11bHRpcGFydC9hbHRlcm5hdGl2ZTsNCglib3VuZGFyeT0iLS09
X05leHRQYXJ0X1NUSl8yODcxNTk1Mi45OTQ1MTM0NjQiDQoNCg0KLS0tLT1fTmV4dFBhcnRfU1RK
XzI4NzE1OTUyLjk5NDUxMzQ2NA0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9
Imlzby04ODU5LTEiDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxl
DQoNClRyZXZvcjoNCg0KSXQgaGVscHMgaWYgb25lIG9mIHlvdXIgb2JqZWN0aXZlcyBpcyB0byBu
b3QgZ28gdG8gdGhlIHJlcG9zaXRvcnkgYW5kIHJldHJpZXZlIHJlZmVyZW5jZWQ9DQogYmFzZSBl
YWNoIHRpbWUgYW5kIHlvdSAgd2FudCB0byB1c2UgbG9jYWxseSBjb25zdHJ1Y3RlZCBmdWxsIENS
TCBpbnN0ZWFkLg0KDQpJIHdvdWxkIGVuY291cmFnZSB5b3UgdG8gcmVhZCB0aGUgYW5uZXggb24g
ZGVsdGEgQ1JMIGluIHRoZSBjdXJyZW50IGRyYWZ0IG9mIFguNTA5IHRvIGZ1bGx5PQ0KIHVuZGVy
c3RhbmQgdGhpcy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRyZXZvciBG
cmVlbWFuID01Qm1haWx0bzp0cmV2b3JmPTQwd2luZG93cy5taWNyb3NvZnQuY29tPTVEDQpTZW50
OiBGcmlkYXksIEp1bHkgMDYsIDIwMDEgNTo0MyBQTQ0KVG86IEFtYmFyaXNoIE1hbHBhbmkNCkNj
OiBpZXRmLXBraXg9NDBpbWMub3JnDQpTdWJqZWN0OiBSRTogU2hvdWxkIGEgQ1JMIG51bWJlciBi
ZSB1bmlxdWUgb3Igbm90ID8NCg0KDQpBbWJyaXNoLA0KWWVzLCBJIGhhdmUgY29uc2lkZXJlZCB0
aGF0IGFuZCBJIGRvbid0IHNlZSBpdCBtYWtlcyBhbiBpbXBhY3Qgb24gdGhlDQpyZXF1aXJlbXRu
cyBmb3IgdGhlIENSTCBudW1iZXIgZXh0ZW5zaW9uIGluIHRoZSBkZWx0YSBDUkwuIFlvdSBhcmUg
anVzdA0KcG9pbnRpbmcgb3V0IHRoYXQgdGhlIGRlbHRhIENSTCBpbmRpY2F0b3IgZXh0ZW5zaW9u
IGluIHRlIGRlbHRhIENSTCBtYXkNCmhhdmUgdGhlIHZhbHVlIG9mIDExIGluIHRoZSBleGFtcGxl
IGRlbHRhIDIgcmF0aGVyIHRoYW4gMTAuDQoNClRoZSBhc3NlcnRpb24gRGF2ZSBtYWRlIHdhcyB0
aGF0IHRoZSBDUkwgbnVtYmVyIGV4dGVuc2lvbiAoTi5CLiBub3QgdGhlDQpkZWx0YSBDUkwgaW5k
aWNhdG9yIGV4dGVuc2lvbikgaW4gdGhlIGRlbHRhIENSTCB3YXMgbmVjZXNzYXJ5IGZvcg0KYXBw
bGljYXRpb25zIHRyeWluZyB0byBjb25zdHJ1Y3QgbG9jYWwgQ1JMcy4gSSBkb24ndCB0aGluayB0
aGUgQ1JMDQpudW1iZXIgZXh0ZW5zaW9uIGluIHRoZSBkZWx0YSBDUkwgaGVscHMuDQoNClRyZXZv
cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW1iYXJpc2ggTWFscGFuaSA9
NUJtYWlsdG86YW1iYXJpc2g9NDB2YWxpY2VydC5jb209NUQ9MjANClNlbnQ6IEZyaWRheSwgSnVs
eSAwNiwgMjAwMSAxMTo1MiBBTQ0KVG86IFRyZXZvciBGcmVlbWFuDQpDYzogaWV0Zi1wa2l4PTQw
aW1jLm9yZw0KU3ViamVjdDogUkU6IFNob3VsZCBhIENSTCBudW1iZXIgYmUgdW5pcXVlIG9yIG5v
dCA/DQoNCg0KDQpUcmV2b3IsDQogICAgSWYgZGVsdGEyIHdhcyBvZmYgYSBiYXNlIG9mIENSTE51
bWJlciAxMSwgdGhlbiB5b3Ugd291bGQgbmVlZCB0bw0KcmV0cmlldmUgdGhlIGZ1bGwgQ1JMIGZv
ciBDUkxOdW1iZXIgMTEgLSBldmVuIHRob3VnaHQgQ1JMTnVtYmVyIDExIG1pZ2h0DQpqdXN0IGJl
IHRoZSBjb21iaW5hdGlvbiBvZiBDUkxOdW1iZXIgMTAgKyBkZWx0YTENCg0KUmVnYXJkcywNCkFt
YmFyaXNoDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQW1iYXJpc2ggTWFscGFuaQ0KQXJjaGl0ZWN0ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNjUwLjU2Ny41NDU3DQpW
YWxpQ2VydCwgSW5jLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbWJhcmlzaD00
MHZhbGljZXJ0LmNvbQ0KMzM5IE4uIEJlcm5hcmRvIEF2ZS4gICAgICAgICAgICAgICAgICAgICAg
ICAgIGh0dHA6Ly93d3cudmFsaWNlcnQuY29tDQpNb3VudGFpbiBWaWV3LCBDQSA5NDA0Mw0KDQoN
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVHJldm9yIEZyZWVtYW4gPTVC
bWFpbHRvOnRyZXZvcmY9NDB3aW5kb3dzLm1pY3Jvc29mdC5jb209NUQNCj4gU2VudDogRnJpZGF5
LCBKdWx5IDA2LCAyMDAxIDExOjQ0IEFNDQo+IFRvOiBBbWJhcmlzaCBNYWxwYW5pOyBEYXZpZCBQ
LiBLZW1wDQo+IENjOiBpZXRmLXBraXg9NDBpbWMub3JnDQo+IFN1YmplY3Q6IFJFOiBTaG91bGQg
YSBDUkwgbnVtYmVyIGJlIHVuaXF1ZSBvciBub3QgPw0KPj0yMA0KPj0yMA0KPiBIaSBBbWJyaXNo
LA0KPiBJIGFja25vd2xlZGdlIHRoZSBuZWVkIGZvciB0aGUgZGVsdGEgQ1JMIGluZGljYXRvciBl
eHRlbnNpb24gaW4gdGhlPTIwDQo+IGRlbHRhIENSTCB3aGljaCBjb250YWlucyB0aGUgQ1JMIG51
bWJlciBvZiB0aGUgYmFzZSBDUkwuIFRoYXQgaXMgbm90PTIwDQo+IHdoYXQgSSBhbSB0YWxraW5n
IGFib3V0LiBJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIENSTCBudW1iZXIgZXh0ZW5zaW9uPTIwDQo+
IGluIHRoZSBkZWx0YSBpdHNlbGYgLSB3aGljaCBJIGFncmVlIGlzIGEgY29tbW9uIG1pc3Rha2Ug
dG8gbWFrZS4gST0yMA0KPiBkb24ndCBzZWUgdGhlIHZhbHVlIG9mIHRoZSBDUkwgbnVtYmVyIGV4
dGVuc2lvbiBpbiB0aGUgZGVsdGEgQ1JMIGlmPTIwDQo+IHlvdSBhcmUgc2ltcGx5IHRyeWluZyB0
byBlc3RhYmxpc2ggdGhlIHNlcXVlbmNlIG9mIGRlbHRhIENSTHMuDQo+PTIwDQo+IFNvIGVxdWFs
bHkNCj4gYmFzZSBDUkwsIENSTCBudW1iZXIgPTNEIDEwDQo+PTIwDQo+IERlbHRhMSwgZGVsdGEg
Q1JMIGluZGVjYXRvciA9M0QgMTAsIHRoaXMgdXBkYXRlID0zRCAxMjowMCBwbQ0KPj0yMA0KPiBE
ZWx0YTIsIGRlbHRhIENSTCBpbmRlYWN0b3IgPTNEIDEwLCB0aGlzIHVwZGF0ZSA9M0QgMTI6MDFw
bQ0KPj0yMA0KPiBJdCBpcyBvdmlvdXMgd2hpY2ggYmFzZSBudW1iZXIgSSBuZWVkLCBhbmQgd2hp
Y2ggaXMgdGhlIGZyZXNoZXN0IGRlbHRhDQoNCj4gQ1JMcy4NCj49MjANCj4gSWYgSSBoYWQgYW4g
YXBwbGljYXRpb24gYnVpbGRpbmcgaXMgb3duIGxvY2FsIGRhdGFiYXNlIGZyb20NCj4gZGVsdGEg
Q1JMcywNCj4gdGhlbiBpdCBoYXMgYWxsIHRoZSBpbmZvcm1hdGlvbiBpdCBuZWVkcy4NCj49MjAN
Cj4gVHJldm9yDQo+PTIwDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFt
YmFyaXNoIE1hbHBhbmkgPTVCbWFpbHRvOmFtYmFyaXNoPTQwdmFsaWNlcnQuY29tPTVEDQo+IFNl
bnQ6IEZyaWRheSwgSnVseSAwNiwgMjAwMSAxMDo1MyBBTQ0KPiBUbzogVHJldm9yIEZyZWVtYW47
IERhdmlkIFAuIEtlbXANCj4gQ2M6IGlldGYtcGtpeD00MGltYy5vcmcNCj4gU3ViamVjdDogUkU6
IFNob3VsZCBhIENSTCBudW1iZXIgYmUgdW5pcXVlIG9yIG5vdCA/DQo+PTIwDQo+PTIwDQo+PTIw
DQo+IEhpIFRyZXZvciwNCj4gICAgIEkgYmVsaWV2ZSB3aGF0IERhdmUgd2FzIHRyeWluZyB0byBz
YXksIGlzIHRoYXQgYnkgaGF2aW5nIGE9MjANCj4gQ1JMTnVtYmVyIG9uIHRoZSBkZWx0YSwgeW91
IGNhbiBrbm93IHdoYXQgeW91ciBuZXcgZWZmZWN0aXZlIGJhc2UgaXMsDQo+IHNvIHRoYXQgaWYg
dGhlIG5ldyBkZWx0YSBpcyBvZmYgYSBDUkwgYXQgb3IgYmVmb3JlIHRoZSBuZXcgZWZmZWN0aXZl
DQo+IGJhc2UsIHlvdSBjYW4gYXBwbHkgaXQgdG8gdGhlIGxvY2FsbHkgY3JlYXRlZCBDUkwgZGF0
YS4NCj49MjANCj4gRm9yIGV4YW1wbGU6DQo+PTIwDQo+IFlvdSBnZXQgYSBmdWxsIENSTCB3aXRo
IENSTE51bWJlciAxMA0KPiBHZXQgZGVsdGExIHdpdGggYSBiYXNlIG9mIDEwIGFuZCBDUkxOdW1i
ZXIgb2YgMTENCj4gR2V0IGRlbHRhMiB3aXRoIGEgYmFzZSBvZiAxMSBhbmQgYSBDUkxOdW1iZXIg
b2YgMTINCj49MjANCj4gWW91IGNhbiBub3cgYXBwbHkgZGVsdGEyIHRvIChDUkxOdW1iZXIgMTAg
KyBkZWx0YTEpLCB3aXRob3V0DQo+IGV2ZXIgaGF2aW5nDQo+IGhhZCB0byBnZXQgQ1JMTnVtYmVy
IDExLg0KPj0yMA0KPiBIb3BlIHRoaXMgaGVscHMsDQo+IFJlZ2FyZHMsDQo+IEFtYmFyaXNoDQo+
PTIwDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBBbWJhcmlzaCBNYWxwYW5pDQo+IEFyY2hpdGVjdCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDY1MC41NjcuNTQ1Nw0K
PiBWYWxpQ2VydCwgSW5jLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbWJhcmlz
aD00MHZhbGljZXJ0LmNvbQ0KPiAzMzkgTi4gQmVybmFyZG8gQXZlLiAgICAgICAgICAgICAgICAg
ICAgICAgICAgaHR0cDovL3d3dy52YWxpY2VydC5jb20NCj4gTW91bnRhaW4gVmlldywgQ0EgOTQw
NDMNCj49MjANCj49MjANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206
IFRyZXZvciBGcmVlbWFuID01Qm1haWx0bzp0cmV2b3JmPTQwd2luZG93cy5taWNyb3NvZnQuY29t
PTVEDQo+ID4gU2VudDogRnJpZGF5LCBKdWx5IDA2LCAyMDAxIDk6MDkgQU0NCj4gPiBUbzogRGF2
aWQgUC4gS2VtcA0KPiA+IENjOiBpZXRmLXBraXg9NDBpbWMub3JnDQo+ID4gU3ViamVjdDogUkU6
IFNob3VsZCBhIENSTCBudW1iZXIgYmUgdW5pcXVlIG9yIG5vdCA/DQo+ID49MjANCj4gPj0yMA0K
PiA+IEhpIERhdmUsDQo+ID49MjANCj4gPiBJIGRvbid0IHNlZSB0aGUgQ1JMIG51bWJlciBpcyB0
aGF0IHZpdGFsIGluIHRoZSBjb25zdHJ1Y3Rpb24gb2YgYT0yMA0KPiA+IGxvY2FsIENSTC4NCj4g
Pj0yMA0KPiA+IFRoZSBhcHBsaWNhdGlvbiBtdXN0IHN0YXJ0IGEgZGIgb2Ygcz01Q24gZnJvbSBh
IGJhc2UgQ1JMLiBUaGVuIHRoZQ0KPiA+IGFwcGxpY2F0aW9uIG5lZWRzIHRvIHVwZGF0ZSB0aGF0
IERCIGJ5IGFkZGluZyB0aGUgbGlzdCBvZj0yMA0KPiBzPTVDbiBmcm9tIHRoZQ0KPj0yMA0KPiA+
IG5leHQgZGVsdGEgQ1JMLiBUaGUgPTIydGhpcyB1cGRhdGUgdGltZT0yMiBjYW4gYmUgdXNlZCB0
bw0KPiBkZXRlcm1pbmUgZnJvbSBhDQo+PTIwDQo+ID4gc2V0IG9mIGRlbHRhcywgd2hpY2ggaXMg
dGhlIG9sZGVzdC4gVGhlIG9ubHkgcmVhc29uIHlvdQ0KPiBuZWVkIHRvIGFwcGx5DQo+ID4gdGhl
bSBpbiBzZXF1ZW5jZSBpcyBiZWNhdXNlIG9mIHRoZSA9MjJyZW1vdmUgZnJvbSBDUkw9MjIgcmVh
c29uIGNvZGVzLA0KPiA+IG90aGVyd2lzZSBpdCB3b3VsZCBub3QgbWF0dGVyLiBBcyB5b3UgcHJv
Y2VzcyB0aGUgbmV4dD0yMA0KPiBkZWx0YSB5b3Ugd2lsbA0KPiA+IGdldCBhIG51bWJlciBvZiA9
MjJjb2xsaXNpb25zPTIyLCBieSBkZXNpZ24gd2hpY2ggeW91IGlnbm9yZSwNCj4gdGhlc2Ugd2ls
bA0KPiA+IGJlIGJlY2F1c2UgaGF2ZSBhbHJlYWR5IGVpdGhlciBhZGRlZCBvciByZW1vdmVkIHRo
ZSBzPTVDbg0KPiByZWZlcmVuY2VkIGluDQo+ID4gdGhlIGRlbHRhLg0KPiA+IEFzIGEgcG9pbnQg
b2YgaW50ZXJlc3QgYW55IGFwcGxpY2F0aW9uIGRvaW5nIHRoaXMgYmVoYXZpb3INCj4gd2l0aCBk
ZWx0YQ0KPiA+IENSTHMgb25seSwgd2lsbCBzdGFydCB0byBkaXZlcmdlIGZyb20gYXBwbGljYXRp
b25zIHVzaW5nIGJhc2UNCj4gPiBhbmQgZGVsdGENCj4gPiBDUkxzIGJlY2F1c2Ugd2hhdCB0aGVz
ZSBhcHBsaWNhdGlvbnMgd2lsbCBub3QgZG8gaXMgcHVyZ2Ugcz01Q24gb2YNCj4gPiBjZXJ0aWZp
Y2F0ZXMgd2hpY2ggaGF2ZSBleHBpcmVkLiBTbyB0ZWNobmljYWxseSBzcGVha2luZz0yMA0KPiB0
aGV5IHdpbGwgbm90DQo+ID4gY29udGFpbiBpZGVudGljYWwgaW5mb3JtYXRpb24uDQo+ID49MjAN
Cj4gPiBUcmV2b3INCj4gPj0yMA0KPj0yMA0KPiAuLi4uPTVCQnVuY2ggb2Ygc3R1ZmYgZGVsZXRl
ZD01RA0KPiA9MjANCj49MjANCg0KLS0tLT1fTmV4dFBhcnRfU1RKXzI4NzE1OTUyLjk5NDUxMzQ2
NA0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9ydGYNCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rp
bmc6IGJhc2U2NA0KDQplMXh5ZEdZeFhHRnVjMmxjWVc1emFXTndaekV5TlRKY1puSnZiWFJsZUhR
Z1hHUmxabVl3ZTF4bWIyNTBkR0pzDQpEUXA3WEdZd1hHWnpkMmx6Y3lCQmNtbGhiRHQ5RFFwN1hH
WXhYR1p0YjJSbGNtNGdRMjkxY21sbGNpQk9aWGM3DQpmUTBLZTF4bU1seG1ibWxzWEdaamFHRnlj
MlYwTWlCVGVXMWliMnc3ZlEwS2UxeG1NMXhtYlc5a1pYSnVYR1pqDQphR0Z5YzJWME1DQkRiM1Z5
YVdWeUlFNWxkenQ5ZlEwS2UxeGpiMnh2Y25SaWJGeHlaV1F3WEdkeVpXVnVNRnhpDQpiSFZsTUR0
Y2NtVmtNRnhuY21WbGJqQmNZbXgxWlRJMU5UdDlEUXBjZFdNeFhIQmhjbVJjY0d4aGFXNWNaR1Zt
DQpkR0ZpTXpZd0lGeG1NRnhtY3pJd0lGUnlaWFp2Y2pwY2NHRnlEUXBjY0dGeURRcEpkQ0JvWld4
d2N5QnBaaUJ2DQpibVVnYjJZZ2VXOTFjaUJ2WW1wbFkzUnBkbVZ6SUdseklIUnZJRzV2ZENCbmJ5
QjBieUIwYUdVZ2NtVndiM05wDQpkRzl5ZVNCaGJtUWdjbVYwY21sbGRtVWdjbVZtWlhKbGJtTmxa
Q0JpWVhObElHVmhZMmdnZEdsdFpTQmhibVFnDQplVzkxSUNCM1lXNTBJSFJ2SUhWelpTQnNiMk5o
Ykd4NUlHTnZibk4wY25WamRHVmtJR1oxYkd3Z1ExSk1JR2x1DQpjM1JsWVdRdVhIQmhjZzBLWEhC
aGNnMEtTU0IzYjNWc1pDQmxibU52ZFhKaFoyVWdlVzkxSUhSdklISmxZV1FnDQpkR2hsSUdGdWJt
VjRJRzl1SUdSbGJIUmhJRU5TVENCcGJpQjBhR1VnWTNWeWNtVnVkQ0JrY21GbWRDQnZaaUJZDQpM
alV3T1NCMGJ5Qm1kV3hzZVNCMWJtUmxjbk4wWVc1a0lIUm9hWE11WEhCaGNnMEtYSEJoY2cwS0xT
MHRMUzFQDQpjbWxuYVc1aGJDQk5aWE56WVdkbExTMHRMUzFjY0dGeURRcEdjbTl0T2lCVWNtVjJi
M0lnUm5KbFpXMWhiaUJiDQpiV0ZwYkhSdk9uUnlaWFp2Y21aQWQybHVaRzkzY3k1dGFXTnliM052
Wm5RdVkyOXRYVnh3WVhJTkNsTmxiblE2DQpJRVp5YVdSaGVTd2dTblZzZVNBd05pd2dNakF3TVNB
MU9qUXpJRkJOWEhCaGNnMEtWRzg2SUVGdFltRnlhWE5vDQpJRTFoYkhCaGJtbGNjR0Z5RFFwRFl6
b2dhV1YwWmkxd2EybDRRR2x0WXk1dmNtZGNjR0Z5RFFwVGRXSnFaV04wDQpPaUJTUlRvZ1UyaHZk
V3hrSUdFZ1ExSk1JRzUxYldKbGNpQmlaU0IxYm1seGRXVWdiM0lnYm05MElEOWNjR0Z5DQpEUXBj
Y0dGeURRcGNjR0Z5RFFwQmJXSnlhWE5vTEZ4d1lYSU5DbGxsY3l3Z1NTQm9ZWFpsSUdOdmJuTnBa
R1Z5DQpaV1FnZEdoaGRDQmhibVFnU1NCa2IyNG5kQ0J6WldVZ2FYUWdiV0ZyWlhNZ1lXNGdhVzF3
WVdOMElHOXVJSFJvDQpaVnh3WVhJTkNuSmxjWFZwY21WdGRHNXpJR1p2Y2lCMGFHVWdRMUpNSUc1
MWJXSmxjaUJsZUhSbGJuTnBiMjRnDQphVzRnZEdobElHUmxiSFJoSUVOU1RDNGdXVzkxSUdGeVpT
QnFkWE4wWEhCaGNnMEtjRzlwYm5ScGJtY2diM1YwDQpJSFJvWVhRZ2RHaGxJR1JsYkhSaElFTlNU
Q0JwYm1ScFkyRjBiM0lnWlhoMFpXNXphVzl1SUdsdUlIUmxJR1JsDQpiSFJoSUVOU1RDQnRZWGxj
Y0dGeURRcG9ZWFpsSUhSb1pTQjJZV3gxWlNCdlppQXhNU0JwYmlCMGFHVWdaWGhoDQpiWEJzWlNC
a1pXeDBZU0F5SUhKaGRHaGxjaUIwYUdGdUlERXdMbHh3WVhJTkNseHdZWElOQ2xSb1pTQmhjM05s
DQpjblJwYjI0Z1JHRjJaU0J0WVdSbElIZGhjeUIwYUdGMElIUm9aU0JEVWt3Z2JuVnRZbVZ5SUdW
NGRHVnVjMmx2DQpiaUFvVGk1Q0xpQnViM1FnZEdobFhIQmhjZzBLWkdWc2RHRWdRMUpNSUdsdVpH
bGpZWFJ2Y2lCbGVIUmxibk5wDQpiMjRwSUdsdUlIUm9aU0JrWld4MFlTQkRVa3dnZDJGeklHNWxZ
MlZ6YzJGeWVTQm1iM0pjY0dGeURRcGhjSEJzDQphV05oZEdsdmJuTWdkSEo1YVc1bklIUnZJR052
Ym5OMGNuVmpkQ0JzYjJOaGJDQkRVa3h6TGlCSklHUnZiaWQwDQpJSFJvYVc1cklIUm9aU0JEVWt4
Y2NHRnlEUXB1ZFcxaVpYSWdaWGgwWlc1emFXOXVJR2x1SUhSb1pTQmtaV3gwDQpZU0JEVWt3Z2FH
VnNjSE11WEhCaGNnMEtYSEJoY2cwS1ZISmxkbTl5WEhCaGNnMEtYSEJoY2cwS0xTMHRMUzFQDQpj
bWxuYVc1aGJDQk5aWE56WVdkbExTMHRMUzFjY0dGeURRcEdjbTl0T2lCQmJXSmhjbWx6YUNCTllX
eHdZVzVwDQpJRnR0WVdsc2RHODZZVzFpWVhKcGMyaEFkbUZzYVdObGNuUXVZMjl0WFNCY2NHRnlE
UXBUWlc1ME9pQkdjbWxrDQpZWGtzSUVwMWJIa2dNRFlzSURJd01ERWdNVEU2TlRJZ1FVMWNjR0Z5
RFFwVWJ6b2dWSEpsZG05eUlFWnlaV1Z0DQpZVzVjY0dGeURRcERZem9nYVdWMFppMXdhMmw0UUds
dFl5NXZjbWRjY0dGeURRcFRkV0pxWldOME9pQlNSVG9nDQpVMmh2ZFd4a0lHRWdRMUpNSUc1MWJX
SmxjaUJpWlNCMWJtbHhkV1VnYjNJZ2JtOTBJRDljY0dGeURRcGNjR0Z5DQpEUXBjY0dGeURRcGNj
R0Z5RFFwVWNtVjJiM0lzWEhCaGNnMEtJQ0FnSUVsbUlHUmxiSFJoTWlCM1lYTWdiMlptDQpJR0Vn
WW1GelpTQnZaaUJEVWt4T2RXMWlaWElnTVRFc0lIUm9aVzRnZVc5MUlIZHZkV3hrSUc1bFpXUWdk
RzljDQpjR0Z5RFFweVpYUnlhV1YyWlNCMGFHVWdablZzYkNCRFVrd2dabTl5SUVOU1RFNTFiV0ps
Y2lBeE1TQXRJR1YyDQpaVzRnZEdodmRXZG9kQ0JEVWt4T2RXMWlaWElnTVRFZ2JXbG5hSFJjY0dG
eURRcHFkWE4wSUdKbElIUm9aU0JqDQpiMjFpYVc1aGRHbHZiaUJ2WmlCRFVreE9kVzFpWlhJZ01U
QWdLeUJrWld4MFlURmNjR0Z5RFFwY2NHRnlEUXBTDQpaV2RoY21SekxGeHdZWElOQ2tGdFltRnlh
WE5vWEhCaGNnMEtYSEJoY2cwS0xTMHRMUzB0TFMwdExTMHRMUzB0DQpMUzB0TFMwdExTMHRMUzB0
TFMwdExTMHRMUzB0TFMwdExTMHRMUzB0TFMwdExTMHRMUzB0TFMwdExTMHRMUzB0DQpMUzB0TFMw
dFhIQmhjZzBLUVcxaVlYSnBjMmdnVFdGc2NHRnVhVnh3WVhJTkNrRnlZMmhwZEdWamRDQWdJQ0Fn
DQpJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnSUNB
Z0lEWTFNQzQxDQpOamN1TlRRMU4xeHdZWElOQ2xaaGJHbERaWEowTENCSmJtTXVJQ0FnSUNBZ0lD
QWdJQ0FnSUNBZ0lDQWdJQ0FnDQpJQ0FnSUNBZ0lDQWdJQ0FnSUdGdFltRnlhWE5vUUhaaGJHbGpa
WEowTG1OdmJWeHdZWElOQ2pNek9TQk9MaUJDDQpaWEp1WVhKa2J5QkJkbVV1SUNBZ0lDQWdJQ0Fn
SUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0JvZEhSd09pOHZkM2QzDQpMblpoYkdsalpYSjBMbU52YlZ4
d1lYSU5DazF2ZFc1MFlXbHVJRlpwWlhjc0lFTkJJRGswTURRelhIQmhjZzBLDQpYSEJoY2cwS1hI
QmhjZzBLUGlBdExTMHRMVTl5YVdkcGJtRnNJRTFsYzNOaFoyVXRMUzB0TFZ4d1lYSU5DajRnDQpS
bkp2YlRvZ1ZISmxkbTl5SUVaeVpXVnRZVzRnVzIxaGFXeDBienAwY21WMmIzSm1RSGRwYm1SdmQz
TXViV2xqDQpjbTl6YjJaMExtTnZiVjFjY0dGeURRbytJRk5sYm5RNklFWnlhV1JoZVN3Z1NuVnNl
U0F3Tml3Z01qQXdNU0F4DQpNVG8wTkNCQlRWeHdZWElOQ2o0Z1ZHODZJRUZ0WW1GeWFYTm9JRTFo
YkhCaGJtazdJRVJoZG1sa0lGQXVJRXRsDQpiWEJjY0dGeURRbytJRU5qT2lCcFpYUm1MWEJyYVho
QWFXMWpMbTl5WjF4d1lYSU5DajRnVTNWaWFtVmpkRG9nDQpVa1U2SUZOb2IzVnNaQ0JoSUVOU1RD
QnVkVzFpWlhJZ1ltVWdkVzVwY1hWbElHOXlJRzV2ZENBL1hIQmhjZzBLDQpQaUJjY0dGeURRbytJ
Rnh3WVhJTkNqNGdTR2tnUVcxaWNtbHphQ3hjY0dGeURRbytJRWtnWVdOcmJtOTNiR1ZrDQpaMlVn
ZEdobElHNWxaV1FnWm05eUlIUm9aU0JrWld4MFlTQkRVa3dnYVc1a2FXTmhkRzl5SUdWNGRHVnVj
Mmx2DQpiaUJwYmlCMGFHVWdYSEJoY2cwS1BpQmtaV3gwWVNCRFVrd2dkMmhwWTJnZ1kyOXVkR0Zw
Ym5NZ2RHaGxJRU5TDQpUQ0J1ZFcxaVpYSWdiMllnZEdobElHSmhjMlVnUTFKTUxpQlVhR0YwSUds
eklHNXZkQ0JjY0dGeURRbytJSGRvDQpZWFFnU1NCaGJTQjBZV3hyYVc1bklHRmliM1YwTGlCSklH
RnRJSFJoYkd0cGJtY2dZV0p2ZFhRZ2RHaGxJRU5TDQpUQ0J1ZFcxaVpYSWdaWGgwWlc1emFXOXVJ
Rnh3WVhJTkNqNGdhVzRnZEdobElHUmxiSFJoSUdsMGMyVnNaaUF0DQpJSGRvYVdOb0lFa2dZV2R5
WldVZ2FYTWdZU0JqYjIxdGIyNGdiV2x6ZEdGclpTQjBieUJ0WVd0bExpQkpJRnh3DQpZWElOQ2o0
Z1pHOXVKM1FnYzJWbElIUm9aU0IyWVd4MVpTQnZaaUIwYUdVZ1ExSk1JRzUxYldKbGNpQmxlSFJs
DQpibk5wYjI0Z2FXNGdkR2hsSUdSbGJIUmhJRU5TVENCcFppQmNjR0Z5RFFvK0lIbHZkU0JoY21V
Z2MybHRjR3g1DQpJSFJ5ZVdsdVp5QjBieUJsYzNSaFlteHBjMmdnZEdobElITmxjWFZsYm1ObElH
OW1JR1JsYkhSaElFTlNUSE11DQpYSEJoY2cwS1BpQmNjR0Z5RFFvK0lGTnZJR1Z4ZFdGc2JIbGNj
R0Z5RFFvK0lHSmhjMlVnUTFKTUxDQkRVa3dnDQpiblZ0WW1WeUlEMGdNVEJjY0dGeURRbytJRnh3
WVhJTkNqNGdSR1ZzZEdFeExDQmtaV3gwWVNCRFVrd2dhVzVrDQpaV05oZEc5eUlEMGdNVEFzSUhS
b2FYTWdkWEJrWVhSbElEMGdNVEk2TURBZ2NHMWNjR0Z5RFFvK0lGeHdZWElODQpDajRnUkdWc2RH
RXlMQ0JrWld4MFlTQkRVa3dnYVc1a1pXRmpkRzl5SUQwZ01UQXNJSFJvYVhNZ2RYQmtZWFJsDQpJ
RDBnTVRJNk1ERndiVnh3WVhJTkNqNGdYSEJoY2cwS1BpQkpkQ0JwY3lCdmRtbHZkWE1nZDJocFky
Z2dZbUZ6DQpaU0J1ZFcxaVpYSWdTU0J1WldWa0xDQmhibVFnZDJocFkyZ2dhWE1nZEdobElHWnla
WE5vWlhOMElHUmxiSFJoDQpYSEJoY2cwS1hIQmhjZzBLUGlCRFVreHpMbHh3WVhJTkNqNGdYSEJo
Y2cwS1BpQkpaaUJKSUdoaFpDQmhiaUJoDQpjSEJzYVdOaGRHbHZiaUJpZFdsc1pHbHVaeUJwY3lC
dmQyNGdiRzlqWVd3Z1pHRjBZV0poYzJVZ1puSnZiVnh3DQpZWElOQ2o0Z1pHVnNkR0VnUTFKTWN5
eGNjR0Z5RFFvK0lIUm9aVzRnYVhRZ2FHRnpJR0ZzYkNCMGFHVWdhVzVtDQpiM0p0WVhScGIyNGdh
WFFnYm1WbFpITXVYSEJoY2cwS1BpQmNjR0Z5RFFvK0lGUnlaWFp2Y2x4d1lYSU5DajRnDQpYSEJo
Y2cwS1BpQXRMUzB0TFU5eWFXZHBibUZzSUUxbGMzTmhaMlV0TFMwdExWeHdZWElOQ2o0Z1JuSnZi
VG9nDQpRVzFpWVhKcGMyZ2dUV0ZzY0dGdWFTQmJiV0ZwYkhSdk9tRnRZbUZ5YVhOb1FIWmhiR2xq
WlhKMExtTnZiVjFjDQpjR0Z5RFFvK0lGTmxiblE2SUVaeWFXUmhlU3dnU25Wc2VTQXdOaXdnTWpB
d01TQXhNRG8xTXlCQlRWeHdZWElODQpDajRnVkc4NklGUnlaWFp2Y2lCR2NtVmxiV0Z1T3lCRVlY
WnBaQ0JRTGlCTFpXMXdYSEJoY2cwS1BpQkRZem9nDQphV1YwWmkxd2EybDRRR2x0WXk1dmNtZGNj
R0Z5RFFvK0lGTjFZbXBsWTNRNklGSkZPaUJUYUc5MWJHUWdZU0JEDQpVa3dnYm5WdFltVnlJR0ps
SUhWdWFYRjFaU0J2Y2lCdWIzUWdQMXh3WVhJTkNqNGdYSEJoY2cwS1BpQmNjR0Z5DQpEUW8rSUZ4
d1lYSU5DajRnU0drZ1ZISmxkbTl5TEZ4d1lYSU5DajRnSUNBZ0lFa2dZbVZzYVdWMlpTQjNhR0Yw
DQpJRVJoZG1VZ2QyRnpJSFJ5ZVdsdVp5QjBieUJ6WVhrc0lHbHpJSFJvWVhRZ1lua2dhR0YyYVc1
bklHRWdYSEJoDQpjZzBLUGlCRFVreE9kVzFpWlhJZ2IyNGdkR2hsSUdSbGJIUmhMQ0I1YjNVZ1ky
RnVJR3R1YjNjZ2QyaGhkQ0I1DQpiM1Z5SUc1bGR5QmxabVpsWTNScGRtVWdZbUZ6WlNCcGN5eGNj
R0Z5RFFvK0lITnZJSFJvWVhRZ2FXWWdkR2hsDQpJRzVsZHlCa1pXeDBZU0JwY3lCdlptWWdZU0JE
VWt3Z1lYUWdiM0lnWW1WbWIzSmxJSFJvWlNCdVpYY2daV1ptDQpaV04wYVhabFhIQmhjZzBLUGlC
aVlYTmxMQ0I1YjNVZ1kyRnVJR0Z3Y0d4NUlHbDBJSFJ2SUhSb1pTQnNiMk5oDQpiR3g1SUdOeVpX
RjBaV1FnUTFKTUlHUmhkR0V1WEhCaGNnMEtQaUJjY0dGeURRbytJRVp2Y2lCbGVHRnRjR3hsDQpP
bHh3WVhJTkNqNGdYSEJoY2cwS1BpQlpiM1VnWjJWMElHRWdablZzYkNCRFVrd2dkMmwwYUNCRFVr
eE9kVzFpDQpaWElnTVRCY2NHRnlEUW8rSUVkbGRDQmtaV3gwWVRFZ2QybDBhQ0JoSUdKaGMyVWdi
MllnTVRBZ1lXNWtJRU5TDQpURTUxYldKbGNpQnZaaUF4TVZ4d1lYSU5DajRnUjJWMElHUmxiSFJo
TWlCM2FYUm9JR0VnWW1GelpTQnZaaUF4DQpNU0JoYm1RZ1lTQkRVa3hPZFcxaVpYSWdiMllnTVRK
Y2NHRnlEUW8rSUZ4d1lYSU5DajRnV1c5MUlHTmhiaUJ1DQpiM2NnWVhCd2JIa2daR1ZzZEdFeUlI
UnZJQ2hEVWt4T2RXMWlaWElnTVRBZ0t5QmtaV3gwWVRFcExDQjNhWFJvDQpiM1YwWEhCaGNnMEtQ
aUJsZG1WeUlHaGhkbWx1WjF4d1lYSU5DajRnYUdGa0lIUnZJR2RsZENCRFVreE9kVzFpDQpaWEln
TVRFdVhIQmhjZzBLUGlCY2NHRnlEUW8rSUVodmNHVWdkR2hwY3lCb1pXeHdjeXhjY0dGeURRbytJ
RkpsDQpaMkZ5WkhNc1hIQmhjZzBLUGlCQmJXSmhjbWx6YUZ4d1lYSU5DajRnWEhCaGNnMEtQaUF0
TFMwdExTMHRMUzB0DQpMUzB0TFMwdExTMHRMUzB0TFMwdExTMHRMUzB0TFMwdExTMHRMUzB0TFMw
dExTMHRMUzB0TFMwdExTMHRMUzB0DQpMUzB0TFMwdExTMHRMUzFjY0dGeURRbytJRUZ0WW1GeWFY
Tm9JRTFoYkhCaGJtbGNjR0Z5RFFvK0lFRnlZMmhwDQpkR1ZqZENBZ0lDQWdJQ0FnSUNBZ0lDQWdJ
Q0FnSUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnDQpJQ0FnSURZMU1DNDFOamN1
TlRRMU4xeHdZWElOQ2o0Z1ZtRnNhVU5sY25Rc0lFbHVZeTRnSUNBZ0lDQWdJQ0FnDQpJQ0FnSUNB
Z0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ1lXMWlZWEpwYzJoQWRtRnNhV05sY25RdVkyOXRYSEJo
DQpjZzBLUGlBek16a2dUaTRnUW1WeWJtRnlaRzhnUVhabExpQWdJQ0FnSUNBZ0lDQWdJQ0FnSUNB
Z0lDQWdJQ0FnDQpJQ0FnYUhSMGNEb3ZMM2QzZHk1MllXeHBZMlZ5ZEM1amIyMWNjR0Z5RFFvK0lF
MXZkVzUwWVdsdUlGWnBaWGNzDQpJRU5CSURrME1EUXpYSEJoY2cwS1BpQmNjR0Z5RFFvK0lGeHdZ
WElOQ2o0Z1BpQXRMUzB0TFU5eWFXZHBibUZzDQpJRTFsYzNOaFoyVXRMUzB0TFZ4d1lYSU5DajRn
UGlCR2NtOXRPaUJVY21WMmIzSWdSbkpsWlcxaGJpQmJiV0ZwDQpiSFJ2T25SeVpYWnZjbVpBZDJs
dVpHOTNjeTV0YVdOeWIzTnZablF1WTI5dFhWeHdZWElOQ2o0Z1BpQlRaVzUwDQpPaUJHY21sa1lY
a3NJRXAxYkhrZ01EWXNJREl3TURFZ09Ub3dPU0JCVFZ4d1lYSU5DajRnUGlCVWJ6b2dSR0YyDQph
V1FnVUM0Z1MyVnRjRnh3WVhJTkNqNGdQaUJEWXpvZ2FXVjBaaTF3YTJsNFFHbHRZeTV2Y21kY2NH
RnlEUW8rDQpJRDRnVTNWaWFtVmpkRG9nVWtVNklGTm9iM1ZzWkNCaElFTlNUQ0J1ZFcxaVpYSWdZ
bVVnZFc1cGNYVmxJRzl5DQpJRzV2ZENBL1hIQmhjZzBLUGlBK0lGeHdZWElOQ2o0Z1BpQmNjR0Z5
RFFvK0lENGdTR2tnUkdGMlpTeGNjR0Z5DQpEUW8rSUQ0Z1hIQmhjZzBLUGlBK0lFa2daRzl1SjNR
Z2MyVmxJSFJvWlNCRFVrd2diblZ0WW1WeUlHbHpJSFJvDQpZWFFnZG1sMFlXd2dhVzRnZEdobElH
TnZibk4wY25WamRHbHZiaUJ2WmlCaElGeHdZWElOQ2o0Z1BpQnNiMk5oDQpiQ0JEVWt3dVhIQmhj
ZzBLUGlBK0lGeHdZWElOQ2o0Z1BpQlVhR1VnWVhCd2JHbGpZWFJwYjI0Z2JYVnpkQ0J6DQpkR0Z5
ZENCaElHUmlJRzltSUhOY1hHNGdabkp2YlNCaElHSmhjMlVnUTFKTUxpQlVhR1Z1SUhSb1pWeHdZ
WElODQpDajRnUGlCaGNIQnNhV05oZEdsdmJpQnVaV1ZrY3lCMGJ5QjFjR1JoZEdVZ2RHaGhkQ0JF
UWlCaWVTQmhaR1JwDQpibWNnZEdobElHeHBjM1FnYjJZZ1hIQmhjZzBLUGlCelhGeHVJR1p5YjIw
Z2RHaGxYSEJoY2cwS1BpQmNjR0Z5DQpEUW8rSUQ0Z2JtVjRkQ0JrWld4MFlTQkRVa3d1SUZSb1pT
QWlkR2hwY3lCMWNHUmhkR1VnZEdsdFpTSWdZMkZ1DQpJR0psSUhWelpXUWdkRzljY0dGeURRbytJ
R1JsZEdWeWJXbHVaU0JtY205dElHRmNjR0Z5RFFvK0lGeHdZWElODQpDajRnUGlCelpYUWdiMlln
WkdWc2RHRnpMQ0IzYUdsamFDQnBjeUIwYUdVZ2IyeGtaWE4wTGlCVWFHVWdiMjVzDQplU0J5WldG
emIyNGdlVzkxWEhCaGNnMEtQaUJ1WldWa0lIUnZJR0Z3Y0d4NVhIQmhjZzBLUGlBK0lIUm9aVzBn
DQphVzRnYzJWeGRXVnVZMlVnYVhNZ1ltVmpZWFZ6WlNCdlppQjBhR1VnSW5KbGJXOTJaU0JtY205
dElFTlNUQ0lnDQpjbVZoYzI5dUlHTnZaR1Z6TEZ4d1lYSU5DajRnUGlCdmRHaGxjbmRwYzJVZ2FY
UWdkMjkxYkdRZ2JtOTBJRzFoDQpkSFJsY2k0Z1FYTWdlVzkxSUhCeWIyTmxjM01nZEdobElHNWxl
SFFnWEhCaGNnMEtQaUJrWld4MFlTQjViM1VnDQpkMmxzYkZ4d1lYSU5DajRnUGlCblpYUWdZU0J1
ZFcxaVpYSWdiMllnSW1OdmJHeHBjMmx2Ym5NaUxDQmllU0JrDQpaWE5wWjI0Z2QyaHBZMmdnZVc5
MUlHbG5ibTl5WlN4Y2NHRnlEUW8rSUhSb1pYTmxJSGRwYkd4Y2NHRnlEUW8rDQpJRDRnWW1VZ1lt
VmpZWFZ6WlNCb1lYWmxJR0ZzY21WaFpIa2daV2wwYUdWeUlHRmtaR1ZrSUc5eUlISmxiVzkyDQpa
V1FnZEdobElITmNYRzVjY0dGeURRbytJSEpsWm1WeVpXNWpaV1FnYVc1Y2NHRnlEUW8rSUQ0Z2RH
aGxJR1JsDQpiSFJoTGx4d1lYSU5DajRnUGlCQmN5QmhJSEJ2YVc1MElHOW1JR2x1ZEdWeVpYTjBJ
R0Z1ZVNCaGNIQnNhV05oDQpkR2x2YmlCa2IybHVaeUIwYUdseklHSmxhR0YyYVc5eVhIQmhjZzBL
UGlCM2FYUm9JR1JsYkhSaFhIQmhjZzBLDQpQaUErSUVOU1RITWdiMjVzZVN3Z2QybHNiQ0J6ZEdG
eWRDQjBieUJrYVhabGNtZGxJR1p5YjIwZ1lYQndiR2xqDQpZWFJwYjI1eklIVnphVzVuSUdKaGMy
VmNjR0Z5RFFvK0lENGdZVzVrSUdSbGJIUmhYSEJoY2cwS1BpQStJRU5TDQpUSE1nWW1WallYVnpa
U0IzYUdGMElIUm9aWE5sSUdGd2NHeHBZMkYwYVc5dWN5QjNhV3hzSUc1dmRDQmtieUJwDQpjeUJ3
ZFhKblpTQnpYRnh1SUc5bVhIQmhjZzBLUGlBK0lHTmxjblJwWm1sallYUmxjeUIzYUdsamFDQm9Z
WFpsDQpJR1Y0Y0dseVpXUXVJRk52SUhSbFkyaHVhV05oYkd4NUlITndaV0ZyYVc1bklGeHdZWElO
Q2o0Z2RHaGxlU0IzDQphV3hzSUc1dmRGeHdZWElOQ2o0Z1BpQmpiMjUwWVdsdUlHbGtaVzUwYVdO
aGJDQnBibVp2Y20xaGRHbHZiaTVjDQpjR0Z5RFFvK0lENGdYSEJoY2cwS1BpQStJRlJ5WlhadmNs
eHdZWElOQ2o0Z1BpQmNjR0Z5RFFvK0lGeHdZWElODQpDajRnTGk0dUxsdENkVzVqYUNCdlppQnpk
SFZtWmlCa1pXeGxkR1ZrWFZ4d1lYSU5DajRnSUZ4d1lYSU5DajRnDQpYSEJoY2cwS2ZRPT0NCi0t
LS09X05leHRQYXJ0X1NUSl8yODcxNTk1Mi45OTQ1MTM0NjQtLQ0KoIIJFjCCAyYwggKPoAMCAQIC
BDjFf+8wDQYJKoZIhvcNAQEFBQAwMjELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxETAP
BgNVBAsTCEJ1c2luZXNzMB4XDTAwMTIyMDE4MzYzN1oXDTAzMTIyMDE5MDYzN1owXTELMAkGA1UE
BhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxETAPBgNVBAsTCEJ1c2luZXNzMSkwDgYDVQQFEwcyRVNY
QzAxMBcGA1UEAxMQU2FudG9zaCBDaG9raGFuaTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
qSK56MpWGE1q1GHXvYq/lPziycmVs1vo25+bhgb9cYaB5n1I3I160AnNxAgOvh8U29nRJWojG5Q1
YFgfSI76gA3grraqriqvmUs4xW7KgU6VcNd9AUhQmGzqYqH3tH5w+S0CmSA12d9OQOTWyTG0eabG
RDEZ37wzI049q2l5MsUCAwEAAaOCARwwggEYMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDAw
MTIyMDE4MzYzN1qBDzIwMDMwMTI2MDcwNjM3WjAgBgNVHREEGTAXgRVjaG9raGFuaUBjeWduYWNv
bS5jb20wVAYDVR0fBE0wSzBJoEegRaRDMEExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0
MREwDwYDVQQLEwhCdXNpbmVzczENMAsGA1UEAxMEQ1JMODAfBgNVHSMEGDAWgBQFJIggTrCyUczL
odnpZySG1fmwRTAdBgNVHQ4EFgQUWNPvo9pGAu2Dq4/Elw9CEXMr9RIwCQYDVR0TBAIwADAZBgkq
hkiG9n0HQQAEDDAKGwRWNS4wAwIEsDANBgkqhkiG9w0BAQUFAAOBgQBuV1P8g8S0H9yWGXpo1O3x
FifX9exmaaWqvA5ZRf7mjOP4lDIIVdTh+V1hUdwTh390fSuQlruXDBiaMIyUaiNLFY2hxLJMoTZh
Au+AelRiTLyQ2Ka/864C/F4PKrvt+IjCfjXepS8Azj3s6QZRpuefRH1+DgtT+zc6G7U7iSzrHzCC
AvcwggJgoAMCAQICBDjFf+0wDQYJKoZIhvcNAQEFBQAwMjELMAkGA1UEBhMCQ0ExEDAOBgNVBAoT
B0VudHJ1c3QxETAPBgNVBAsTCEJ1c2luZXNzMB4XDTAwMTIyMDE4MzU0OVoXDTAzMTIyMDE5MDU0
OVowXTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxETAPBgNVBAsTCEJ1c2luZXNzMSkw
DgYDVQQFEwcyRVNYQzAxMBcGA1UEAxMQU2FudG9zaCBDaG9raGFuaTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAtjtkRJN1Hl9oXaPaOUb4TI2oWYsPzK2zSDy2gMydVJm9KnHQ+C/5XMxcpIJs
aLPPYYXgh0p9akw6v7Yk4ie+M5h3ww++I3j0Mv+JKEZAvPolmiJIpPZrsplmJU6ikV58kQAwHqNa
31xLnefn6Jpmknx28PzmQe7eUVtH5lJI4V0CAwEAAaOB7jCB6zAgBgNVHREEGTAXgRVjaG9raGFu
aUBjeWduYWNvbS5jb20wVAYDVR0fBE0wSzBJoEegRaRDMEExCzAJBgNVBAYTAkNBMRAwDgYDVQQK
EwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczENMAsGA1UEAxMEQ1JMODALBgNVHQ8EBAMCBSAw
HwYDVR0jBBgwFoAUBSSIIE6wslHMy6HZ6WckhtX5sEUwHQYDVR0OBBYEFDGD8nnq0goH9f6lE+us
BtPUf/dpMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjUuMAMCBJAwDQYJKoZIhvcNAQEF
BQADgYEAW+1tXXgkxTpU6b2emHJU4lgqRXCJFNNjPvOE9FrthgrnmxOo1OOCfK+nw72YarEgCfot
cKqZP/OGBiZWyWXDB88C2MotJGFDL3dikj54pRoxaOeVSWFlmzh7R58oci5XitnpImobimuIEAn4
HkZqxZhtBuXzfibPZkumDn8RHP8wggLtMIICVqADAgECAgQyRsSjMA0GCSqGSIb3DQEBBQUAMDIx
CzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczAeFw05ODA4
MTkxOTEyMDZaFw0xODA4MTkxOTQyMDZaMDIxCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0
MREwDwYDVQQLEwhCdXNpbmVzczCBnTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEA0IBgoGWlwptm
AbxopaoSELaZIvJHlWg+vqcqkQlA6mSAzTEHQl79k5aUq4cPZQTK5SnsUoY3aPN8IyTN8+SDmIJ/
3qwFvxG1Xkbi1UDo6qB/TR1zwBoxpz7iL8XH5gLWSaijFab+bMeTamSeL05l0JjF0AoAmxnwAjU7
Zl4kdWkCAQOjggEQMIIBDDARBglghkgBhvhCAQEEBAMCAAcwVAYDVR0fBE0wSzBJoEegRaRDMEEx
CzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczENMAsGA1UE
AxMEQ1JMMTArBgNVHRAEJDAigA8xOTk4MDgxOTE5MTIwNlqBDzIwMTgwODE5MTkxMjA2WjALBgNV
HQ8EBAMCAQYwHwYDVR0jBBgwFoAUBSSIIE6wslHMy6HZ6WckhtX5sEUwHQYDVR0OBBYEFAUkiCBO
sLJRzMuh2elnJIbV+bBFMAwGA1UdEwQFMAMBAf8wGQYJKoZIhvZ9B0EABAwwChsEVjQuMAMCBJAw
DQYJKoZIhvcNAQEFBQADgYEAmD6AijZUbsSo9EEAndDqyGjE//ykwKT/dTIpu67gSfhpGf7mQBea
OGolH3y5mxHz0blLUjrymf7GGDoUreA2AL84s5nptEYAFxAaRGi/y+8igk9FE3clhwDIlJHKRjYJ
mE+xb32k7r2qXFLiVEh8gW5+Vpezs9jYtPN+2w7qjVwxggI8MIICOAIBATA6MDIxCzAJBgNVBAYT
AkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzcwIEOMV/7zAJBgUrDgMCGgUA
oIIBWDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTA3MDcxMzQ0
MjRaMCMGCSqGSIb3DQEJBDEWBBSOwc2LMHAd0yC4uUkwqye9WMxgBjCB+AYJKoZIhvcNAQkPMYHq
MIHnMA8GCSqGSIb2fQdCCgICAIAwDgYJKoZIhvZ9B0IKAgEoMA0GCCqGSIb3DQMCAgE6MA4GCCqG
SIb3DQMCAgIAoDAKBggqhkiG9w0DBzAHBgUrDgMCBzANBgsrBgEEAYE8BwEBAjAHBgUrDgMCGjAK
BggqhkiG9w0CBTALBgkqhkiG9w0BAQEwCwYJKoZIhvcNAQEHMAkGByqGSM44BAEwCQYHKoZIzj0C
ATALBgkqhkiG9w0BAQUwCwYJKoZIhvcNAQEEMAkGByqGSM44BAMwCQYHKoZIzj0EATAMBgoqhkiG
9w0BCQ8BMA0GCSqGSIb3DQEBAQUABIGACmKqMvQTYyLewio2DAk3QKN1HVb06+ZzAOiiecygHEST
4fUjlwJ3DdzfUN1A5r1xh3eG5QOopL8aUB9yUIoKU2Bj73uSHIfgoRQ2IHIxGwSdrY9p0V3oWAga
gfJIMvcQQ10gUrrn8Nz8Df4NrtGyS2/dyhEVtUppih51a4mcG4w=


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f67ADZl05720 for ietf-pkix-bks; Sat, 7 Jul 2001 03:13:35 -0700 (PDT)
Received: from sek11.acrosswireless.com ([213.212.5.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f67ADXm05716 for <[e-mail]>; Sat, 7 Jul 2001 03:13:34 -0700 (PDT)
Received: from sek11.acrosswireless.com ([127.0.0.1]) by sek11.acrosswireless.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 7 Jul 2001 12:11:08 +0200
Received: from data1 ([213.212.5.230]:55773) (HELO acrossw01.acrosswireless.com) by sek11.acrosswireless.com ([192.168.1.11]:25) (F-Secure Anti-Virus for Internet Mail 5.0.53 Release) with SMTP; Sat, 7 Jul 2001 10:11:08 -0000
Received: by acrossw01.acrosswireless.com with Internet Mail Service (5.5.2650.21) id <32RJZQMS>; Sat, 7 Jul 2001 12:10:59 +0200
Message-ID: <[e-mail]>
From: Olle Larsson <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, Ambarish Malpani <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Should a CRL number be unique or not ?
Date: Sat, 7 Jul 2001 12:10:52 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
X-OriginalArrivalTime: 07 Jul 2001 10:11:08.0934 (UTC) FILETIME=[24404A60:01C106CD]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Trevor,

Constructing a local CRL like you say, ie by using the thisUpdate field
only, imposes a requirement that only one delta CRL may be issued per second
and issuer, as the date field doesn't come with a higher resolution than
that.

Is that really a fair requirement for a general internet PKI?
I doubt it.

/Olle

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: Friday, July 06, 2001 11:43 PM
To: Ambarish Malpani
Cc: [e-mail]
Subject: RE: Should a CRL number be unique or not ?


Ambrish,
Yes, I have considered that and I don't see it makes an impact on the
requiremtns for the CRL number extension in the delta CRL. You are just
pointing out that the delta CRL indicator extension in te delta CRL may
have the value of 11 in the example delta 2 rather than 10.

The assertion Dave made was that the CRL number extension (N.B. not the
delta CRL indicator extension) in the delta CRL was necessary for
applications trying to construct local CRLs. I don't think the CRL
number extension in the delta CRL helps.

Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Friday, July 06, 2001 11:52 AM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: Should a CRL number be unique or not ?



Trevor,
    If delta2 was off a base of CRLNumber 11, then you would need to
retrieve the full CRL for CRLNumber 11 - even thought CRLNumber 11 might
just be the combination of CRLNumber 10 + delta1

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 11:44 AM
> To: Ambarish Malpani; David P. Kemp
> Cc: [e-mail]
> Subject: RE: Should a CRL number be unique or not ?
> 
> 
> Hi Ambrish,
> I acknowledge the need for the delta CRL indicator extension in the 
> delta CRL which contains the CRL number of the base CRL. That is not 
> what I am talking about. I am talking about the CRL number extension 
> in the delta itself - which I agree is a common mistake to make. I 
> don't see the value of the CRL number extension in the delta CRL if 
> you are simply trying to establish the sequence of delta CRLs.
> 
> So equally
> base CRL, CRL number = 10
> 
> Delta1, delta CRL indecator = 10, this update = 12:00 pm
> 
> Delta2, delta CRL indeactor = 10, this update = 12:01pm
> 
> It is ovious which base number I need, and which is the freshest delta

> CRLs.
> 
> If I had an application building is own local database from
> delta CRLs,
> then it has all the information it needs.
> 
> Trevor
> 
> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 10:53 AM
> To: Trevor Freeman; David P. Kemp
> Cc: [e-mail]
> Subject: RE: Should a CRL number be unique or not ?
> 
> 
> 
> Hi Trevor,
>     I believe what Dave was trying to say, is that by having a 
> CRLNumber on the delta, you can know what your new effective base is,
> so that if the new delta is off a CRL at or before the new effective
> base, you can apply it to the locally created CRL data.
> 
> For example:
> 
> You get a full CRL with CRLNumber 10
> Get delta1 with a base of 10 and CRLNumber of 11
> Get delta2 with a base of 11 and a CRLNumber of 12
> 
> You can now apply delta2 to (CRLNumber 10 + delta1), without
> ever having
> had to get CRLNumber 11.
> 
> Hope this helps,
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> 
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[e-mail]]
> > Sent: Friday, July 06, 2001 9:09 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Should a CRL number be unique or not ?
> > 
> > 
> > Hi Dave,
> > 
> > I don't see the CRL number is that vital in the construction of a 
> > local CRL.
> > 
> > The application must start a db of s\n from a base CRL. Then the
> > application needs to update that DB by adding the list of 
> s\n from the
> 
> > next delta CRL. The "this update time" can be used to
> determine from a
> 
> > set of deltas, which is the oldest. The only reason you
> need to apply
> > them in sequence is because of the "remove from CRL" reason codes,
> > otherwise it would not matter. As you process the next 
> delta you will
> > get a number of "collisions", by design which you ignore,
> these will
> > be because have already either added or removed the s\n
> referenced in
> > the delta.
> > As a point of interest any application doing this behavior
> with delta
> > CRLs only, will start to diverge from applications using base
> > and delta
> > CRLs because what these applications will not do is purge s\n of
> > certificates which have expired. So technically speaking 
> they will not
> > contain identical information.
> > 
> > Trevor
> > 
> 
> ....[Bunch of stuff deleted]
>  
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66M5ae17187 for ietf-pkix-bks; Fri, 6 Jul 2001 15:05:36 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.11.3/8.11.3) with SMTP id f66M5Vm17183 for <[e-mail]>; Fri, 6 Jul 2001 15:05:31 -0700 (PDT)
Received: from 157.54.9.100 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Jul 2001 14:44:44 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 14:44:04 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 14:44:18 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 14:43:28 -0700
content-class: urn:content-classes:message
Subject: RE: Should a CRL number be unique or not ?
MIME-Version: 1.0
Date: Fri, 6 Jul 2001 14:43:28 -0700
Content-Type: multipart/signed; boundary="----=_NextPart_000_0013_01C1062A.21E58E90"; protocol="application/x-pkcs7-signature"; micalg=SHA1
X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Should a CRL number be unique or not ?
Thread-Index: AcEGTUdDFx2oH85aRyayt3F/WqW/GwAFne7Q
From: "Trevor Freeman" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 06 Jul 2001 21:43:28.0623 (UTC) FILETIME=[B16C0FF0:01C10664]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C1062A.21E58E90
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Ambrish,
Yes, I have considered that and I don't see it makes an impact on the
requiremtns for the CRL number extension in the delta CRL. You are just
pointing out that the delta CRL indicator extension in te delta CRL may
have the value of 11 in the example delta 2 rather than 10.

The assertion Dave made was that the CRL number extension (N.B. not the
delta CRL indicator extension) in the delta CRL was necessary for
applications trying to construct local CRLs. I don't think the CRL
number extension in the delta CRL helps.

Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Friday, July 06, 2001 11:52 AM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: Should a CRL number be unique or not ?



Trevor,
    If delta2 was off a base of CRLNumber 11, then you would need to
retrieve the full CRL for CRLNumber 11 - even thought CRLNumber 11 might
just be the combination of CRLNumber 10 + delta1

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 11:44 AM
> To: Ambarish Malpani; David P. Kemp
> Cc: [e-mail]
> Subject: RE: Should a CRL number be unique or not ?
> 
> 
> Hi Ambrish,
> I acknowledge the need for the delta CRL indicator extension in the 
> delta CRL which contains the CRL number of the base CRL. That is not 
> what I am talking about. I am talking about the CRL number extension 
> in the delta itself - which I agree is a common mistake to make. I 
> don't see the value of the CRL number extension in the delta CRL if 
> you are simply trying to establish the sequence of delta CRLs.
> 
> So equally
> base CRL, CRL number = 10
> 
> Delta1, delta CRL indecator = 10, this update = 12:00 pm
> 
> Delta2, delta CRL indeactor = 10, this update = 12:01pm
> 
> It is ovious which base number I need, and which is the freshest delta

> CRLs.
> 
> If I had an application building is own local database from
> delta CRLs,
> then it has all the information it needs.
> 
> Trevor
> 
> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 10:53 AM
> To: Trevor Freeman; David P. Kemp
> Cc: [e-mail]
> Subject: RE: Should a CRL number be unique or not ?
> 
> 
> 
> Hi Trevor,
>     I believe what Dave was trying to say, is that by having a 
> CRLNumber on the delta, you can know what your new effective base is,
> so that if the new delta is off a CRL at or before the new effective
> base, you can apply it to the locally created CRL data.
> 
> For example:
> 
> You get a full CRL with CRLNumber 10
> Get delta1 with a base of 10 and CRLNumber of 11
> Get delta2 with a base of 11 and a CRLNumber of 12
> 
> You can now apply delta2 to (CRLNumber 10 + delta1), without
> ever having
> had to get CRLNumber 11.
> 
> Hope this helps,
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> 
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[e-mail]]
> > Sent: Friday, July 06, 2001 9:09 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Should a CRL number be unique or not ?
> > 
> > 
> > Hi Dave,
> > 
> > I don't see the CRL number is that vital in the construction of a 
> > local CRL.
> > 
> > The application must start a db of s\n from a base CRL. Then the
> > application needs to update that DB by adding the list of 
> s\n from the
> 
> > next delta CRL. The "this update time" can be used to
> determine from a
> 
> > set of deltas, which is the oldest. The only reason you
> need to apply
> > them in sequence is because of the "remove from CRL" reason codes,
> > otherwise it would not matter. As you process the next 
> delta you will
> > get a number of "collisions", by design which you ignore,
> these will
> > be because have already either added or removed the s\n
> referenced in
> > the delta.
> > As a point of interest any application doing this behavior
> with delta
> > CRLs only, will start to diverge from applications using base
> > and delta
> > CRLs because what these applications will not do is purge s\n of
> > certificates which have expired. So technically speaking 
> they will not
> > contain identical information.
> > 
> > Trevor
> > 
> 
> ....[Bunch of stuff deleted]
>  
> 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUijCCA0Aw
ggKpoAMCAQICECElZvdedYS4R497WbSp4hIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx
EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv
b3QgQ0EwHhcNMDAwOTIwMjEyNDQ1WhcNMDIwOTIwMjEzMzI4WjBMMQswCQYDVQQGEwJVUzESMBAG
A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD
QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxym3bBtJ93ep9YM9eFtrJSmFA8NG6OtxTKRL
LyorXMYNUzLsdozvGWdSZwlzbvATakzrzriuqq7QgaBzJvS0Oq8yAzthqf0jBQysGvTH1LHieo3b
mCFFOOUtGvfdJGbEMvTb8cT0yxAgPJ7Or0WZta77f/ARUNWWv6g7TNUUhe0CAwEAAaOCASEwggEd
MBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud
DgQWBBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGloIGihk5odHRwOi8v
d2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy
MFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNv
bVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMBAGCSsGAQQBgjcVAQQDAgEA
MA0GCSqGSIb3DQEBBQUAA4GBAAj54W8kzais9v83BJCkQFSgVejj3junPZCxUeCnGzzDmrxUuOPc
ofoYlSwZ/11uLoVVc5qCkEZknWSmwRRViiizyf3dRuYsR9seP2ixJUtKHHwbqHeoQpUpZpOt+czy
LOKJpPc9ihx917XumDCrNTF0Urn8pouG9wYyB3wUnmSdMIIFMDCCBO+gAwIBAgIKYW/U2AAAAAAA
AzAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsT
BU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4X
DTAwMDkyNTIzMjcyM1oXDTAxMDkyNTIzMzQxNlowSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1p
Y3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEAupHMN0lJw9ae2Ic2yZBICCqeP2H6Re4B1Rnk+KETtF0S15jq
7ea5n/+z43Da9CqjunNJaLT7rX4o9NHUN7eP5aKlZ7aRP+EoT0wB51OPsjZKuFWptbdL7PEVHAuO
UrOOjyZ0ITR432vqcJ/L3AouTyuCuN7/1kw9tMMRl5erzkUCAwEAAaOCA10wggNZMBAGCSsGAQQB
gjcVAQQDAgEAMB0GA1UdDgQWBBTJRFZKkBN8qfMzBmve0Jm758jO6TAZBgkrBgEEAYI3FAIEDB4K
AFMAdQBiAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBR5II7e
pN8kVyKCvm3OC5j8FM5BQjCCAVYGA1UdHwSCAU0wggFJMIIBRaCCAUGgggE9hlxodHRwOi8vd2hp
Y2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMEludGVybWVkaWF0ZSUy
MFN1Ym9yZGluYXRlJTIwV2hpY2EyLmNybIaB3GxkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlh
dGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMixDTj13aGljYTIsQ049Q0RQLENOPVB1YmxpYyUyMEtl
eSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWlj
cm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9
Y1JMRGlzdHJpYnV0aW9uUG9pbnQwggFwBggrBgEFBQcBAQSCAWIwggFeMIGDBggrBgEFBQcwAoZ3
aHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2EyLm50ZGV2
Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBJbnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNh
Mi5jcnQwgdUGCCsGAQUFBzAChoHIbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1
Ym9yZGluYXRlJTIwV2hpY2EyLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1T
ZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FD
ZXJ0aWZpY2F0ZT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwCQYHKoZI
zjgEAwMwADAtAhUA5UHxWLBZ8zXgJgd7ecJ4BW5po4ICFCf3VEVyF7k5XJoMIVrDvDBHwVrbMIIF
oTCCBQqgAwIBAgIKGja7EgAAAAAAAjANBgkqhkiG9w0BAQUFADBMMQswCQYDVQQGEwJVUzESMBAG
A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD
QTAeFw0wMDA5MjUyMzI0MTZaFw0wMTA5MjUyMzM0MTZaMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUg
U3Vib3JkaW5hdGUgV2hpY2EyMIIBtjCCASsGByqGSM44BAEwggEeAoGBAM33k4tehmdxq/WAJjhP
tyAwpe/Xs2MX1Jhc2ShMrwnG1hkPkHiYHBfIR7QFKv+J3tlXp1ej93ofwXW9gD1jayyrtfjcNqHK
skGIrYJoVB9WT9BTAlmXEN3gBJgI1Tkh3KsbzpMPDmabhRtb+Ahmn0dUdaxmukabDOJW539YPj/9
AhUA76t5INGQllcDcGCPneHWb2MEDHUCgYA4+rooQzuD3Xf9zRqeEEH0MXR5q1ax9nBBlaE9XnVJ
EqqIUc7nqSWLh85Smp4zUEqaL3nIRPzgPAGl1g3HuEtG3IKQlbIbgg/AsLY6pQfu1oiP7NlH4NWL
kKRDrWbSueFKvBuwNmio0JG7r2MH5OO3QSUKua7Exgsg0RR+rkjfiwOBhAACgYAcJAh8mC7+Ha2b
GsznzWsQiBrcATowbZE2woOE5vLOzAILXRnC2n4Q+C0zDXp80KvPfUNPAGfgk741D/2U0gZEL488
3ASeR4IN3ETWSJHBUGU6l2EXoREy3WScNwo2gZchPPJq9uR7FLLCM9AKprz/Gd6ystAXtwhdZwrH
mawlJaOCAlswggJXMBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBR5II7epN8kVyKCvm3OC5j8
FM5BQjAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAcYwDwYDVR0TAQH/BAUw
AwEB/zAfBgNVHSMEGDAWgBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGl
oIGihk5odHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwv
TlRERVYlMjBTQSUyMFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYu
bWljcm9zb2Z0LmNvbVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMIIBDwYI
KwYBBQUHAQEEggEBMIH+MHwGCCsGAQUFBzAChnBodHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5t
aWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29t
X05UREVWJTIwU0ElMjBSb290JTIwQ0EuY3J0MH4GCCsGAQUFBzAChnJmaWxlOi8vXFx3aGljYXNh
cm9vdGNhLm50ZGV2Lm1pY3Jvc29mdC5jb21cQ2VydEVucm9sbFx3aGljYXNhcm9vdGNhLm50ZGV2
Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBTQSUyMFJvb3QlMjBDQS5jcnQwDQYJKoZIhvcNAQEFBQAD
gYEAL4HlyexkgagQx3sh6yj2kff49+Kpg2cNW+BmHoAEhjk/0A9knSiOsdKxpICFqAe62YJ5tntl
4LtnW8LMnGwt9pp1nDC66thpoAXl9Nw0iP9r+xNtZGZovKQ6ZBiM1ph9kLqHfCVYGmsrOYIM9X5h
MqVdm5OdWwTnZmh08TirPRwwggZpMIIF0qADAgECAgo+xCJqAAAAApu4MA0GCSqGSIb3DQEBBQUA
MEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYD
VQQDEw9OVERFViBJU1NVRTMgQ0EwHhcNMDEwNDI3MTgzMTI3WhcNMDEwOTI1MjMzNDE2WjCBrDET
MBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEVMBMGCgmSJomT
8ixkARkWBW50ZGV2MQwwCgYDVQQLEwNJVEcxDjAMBgNVBAsTBVVzZXJzMRcwFQYDVQQDEw5UcmV2
b3IgRnJlZW1hbjEsMCoGCSqGSIb3DQEJARYddHJldm9yZkB3aW5kb3dzLm1pY3Jvc29mdC5jb20w
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALMVg148IfruQrM0j5qas4ZbiYpKLglnKd3G2/TQ
SUGMkh4L06jyZJdnYD9V5okQTuvNeAiItg7AYOZYvEltA6fSP3e1GYqjZeJ5pXJjCECuebcbNb9c
qNQJjukjDGLYvlq8pT2c0I4R+olx9k4aowthS951IzkcTnl2APmWAY4zAgMBAAGjggPwMIID7DAL
BgNVHQ8EBAMCBLAwNgYJKoZIhvcNAQkPBCkwJzANBggqhkiG9w0DAgIBODANBggqhkiG9w0DBAIB
ODAHBgUrDgMCBzA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+m
FYenvuIJjrGt8U0CAW0CAQAwHQYDVR0OBBYEFG9xWGRt1a6bGtu2+SM1nyIeq+qTMB8GA1UdIwQY
MBaAFMlEVkqQE3yp8zMGa97QmbvnyM7pMIIBJgYDVR0fBIIBHTCCARkwggEVoIIBEaCCAQ2GRGh0
dHA6Ly93aGljYTMubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUz
JTIwQ0EuY3JshoHEbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENBLENOPXdoaWNhMyxDTj1D
RFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv
bixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/
YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAT8GCCsGAQUFBwEBBIIBMTCC
AS0wawYIKwYBBQUHMAKGX2h0dHA6Ly93aGljYTMubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5y
b2xsL3doaWNhMy5udGRldi5taWNyb3NvZnQuY29tX05UREVWJTIwSVNTVUUzJTIwQ0EuY3J0MIG9
BggrBgEFBQcwAoaBsGxkYXA6Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSxDTj1BSUEsQ049UHVi
bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRl
dixEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0
aWZpY2F0aW9uQXV0aG9yaXR5MBMGA1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcVCgQOMAww
CgYIKwYBBQUHAwQwVQYDVR0RBE4wTKArBgorBgEEAYI3FAIDoB0MG3RyZXZvcmZAbnRkZXYubWlj
cm9zb2Z0LmNvbYEddHJldm9yZkB3aW5kb3dzLm1pY3Jvc29mdC5jb20wLwYJKwYBBAGCNxQCBCIe
IABBAHUAdABvAEUAeABjAGgAYQBuAGcAZQBVAHMAZQByMA0GCSqGSIb3DQEBBQUAA4GBAHF2BsCe
UuP9UrqvEXcXRAex+Dze5RWoC3e6atdC0NyiJLSndI+uvD7xBdpxP7MOKtUmcBgzyvBJ9+Ls2eZy
M8U8tmXHwHzZ9l/HEY8xr/0G27A3H4CDAP4hHhsv2hVh5NMTg/t68iyRuupLQQJhmSAOUtrr73Mk
hbjMbAyxe3PaMYICnzCCApsCAQEwWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0
MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgo+xCJqAAAAApu4MAkG
BSsOAwIaBQCgggGcMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAx
MDcwNjIxNDQxN1owIwYJKoZIhvcNAQkEMRYEFPeELTMb37FLlaxtr+TLXw31MAkoMGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCSsGAQQBgjcQBDFbMFkw
SzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNV
BAMTD05UREVWIElTU1VFMyBDQQIKPsQiagAAAAKbuDBqBgsqhkiG9w0BCRACCzFboFkwSzELMAkG
A1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05U
REVWIElTU1VFMyBDQQIKPsQiagAAAAKbuDANBgkqhkiG9w0BAQEFAASBgJ56f05WjM8aZwz2Qmh0
XWLjQSkzxwuOpRtCv6v8PuaXvOduO+qLyFg32oeZxI13atKO1KH1Oixsc1I59pOqs7fMbPAOgPil
MW44XWh1EBsP8GZ/SGAyYtaDFoaR3hmPmpJA5jlulTfjY+xdHVhYCq1XE2QxnAyAu9Py5Y0uOn8J
AAAAAAAA

------=_NextPart_000_0013_01C1062A.21E58E90--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66IuPC13341 for ietf-pkix-bks; Fri, 6 Jul 2001 11:56:25 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66IuOm13337 for <[e-mail]>; Fri, 6 Jul 2001 11:56:24 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 6 Jul 2001 11:56:54 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 06 Jul 2001 11:56:53 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <N8CDMGTC>; Fri, 06 Jul 2001 11:52:27 -0700
Content-return: allowed
Date: Fri, 06 Jul 2001 11:52:19 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Should a CRL number be unique or not ?
To: "'Trevor Freeman'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Trevor,
    If delta2 was off a base of CRLNumber 11, then you would need
to retrieve the full CRL for CRLNumber 11 - even thought CRLNumber 11
might just be the combination of CRLNumber 10 + delta1

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 11:44 AM
> To: Ambarish Malpani; David P. Kemp
> Cc: [e-mail]
> Subject: RE: Should a CRL number be unique or not ?
> 
> 
> Hi Ambrish,
> I acknowledge the need for the delta CRL indicator extension in the
> delta CRL which contains the CRL number of the base CRL. That is not
> what I am talking about. I am talking about the CRL number 
> extension in
> the delta itself - which I agree is a common mistake to make. I don't
> see the value of the CRL number extension in the delta CRL if you are
> simply trying to establish the sequence of delta CRLs.
> 
> So equally
> base CRL, CRL number = 10
> 
> Delta1, delta CRL indecator = 10, this update = 12:00 pm
> 
> Delta2, delta CRL indeactor = 10, this update = 12:01pm
> 
> It is ovious which base number I need, and which is the freshest delta
> CRLs.
> 
> If I had an application building is own local database from 
> delta CRLs,
> then it has all the information it needs.
> 
> Trevor
> 
> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]] 
> Sent: Friday, July 06, 2001 10:53 AM
> To: Trevor Freeman; David P. Kemp
> Cc: [e-mail]
> Subject: RE: Should a CRL number be unique or not ?
> 
> 
> 
> Hi Trevor,
>     I believe what Dave was trying to say, is that by having
> a CRLNumber on the delta, you can know what your new 
> effective base is,
> so that if the new delta is off a CRL at or before the new effective
> base, you can apply it to the locally created CRL data.
> 
> For example:
> 
> You get a full CRL with CRLNumber 10
> Get delta1 with a base of 10 and CRLNumber of 11
> Get delta2 with a base of 11 and a CRLNumber of 12
> 
> You can now apply delta2 to (CRLNumber 10 + delta1), without 
> ever having
> had to get CRLNumber 11.
> 
> Hope this helps,
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> 
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[e-mail]]
> > Sent: Friday, July 06, 2001 9:09 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Should a CRL number be unique or not ?
> > 
> > 
> > Hi Dave,
> > 
> > I don't see the CRL number is that vital in the construction
> > of a local
> > CRL.
> > 
> > The application must start a db of s\n from a base CRL. Then the 
> > application needs to update that DB by adding the list of 
> s\n from the
> 
> > next delta CRL. The "this update time" can be used to 
> determine from a
> 
> > set of deltas, which is the oldest. The only reason you 
> need to apply 
> > them in sequence is because of the "remove from CRL" reason codes, 
> > otherwise it would not matter. As you process the next 
> delta you will 
> > get a number of "collisions", by design which you ignore, 
> these will 
> > be because have already either added or removed the s\n 
> referenced in 
> > the delta.
> > As a point of interest any application doing this behavior 
> with delta
> > CRLs only, will start to diverge from applications using base 
> > and delta
> > CRLs because what these applications will not do is purge s\n of
> > certificates which have expired. So technically speaking 
> they will not
> > contain identical information.
> > 
> > Trevor
> > 
> 
> ....[Bunch of stuff deleted]
>  
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66IqNQ13294 for ietf-pkix-bks; Fri, 6 Jul 2001 11:52:23 -0700 (PDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.3/8.11.3) with SMTP id f66IqMm13290 for <[e-mail]>; Fri, 6 Jul 2001 11:52:22 -0700 (PDT)
Received: from 157.54.9.100 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Jul 2001 11:45:20 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 11:44:46 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 11:44:31 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 11:43:56 -0700
content-class: urn:content-classes:message
Subject: RE: Should a CRL number be unique or not ?
MIME-Version: 1.0
Date: Fri, 6 Jul 2001 11:43:55 -0700
Content-Type: multipart/signed; boundary="----=_NextPart_000_0048_01C10611.0D48F3A0"; protocol="application/x-pkcs7-signature"; micalg=SHA1
X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Should a CRL number be unique or not ?
Thread-Index: AcEGRmQax7WBBtIgSRCIjmPi0eoUnwAArhuw
From: "Trevor Freeman" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 06 Jul 2001 18:43:56.0093 (UTC) FILETIME=[9C7E6ED0:01C1064B]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0048_01C10611.0D48F3A0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Ambrish,
I acknowledge the need for the delta CRL indicator extension in the
delta CRL which contains the CRL number of the base CRL. That is not
what I am talking about. I am talking about the CRL number extension in
the delta itself - which I agree is a common mistake to make. I don't
see the value of the CRL number extension in the delta CRL if you are
simply trying to establish the sequence of delta CRLs.

So equally
base CRL, CRL number = 10

Delta1, delta CRL indecator = 10, this update = 12:00 pm

Delta2, delta CRL indeactor = 10, this update = 12:01pm

It is ovious which base number I need, and which is the freshest delta
CRLs.

If I had an application building is own local database from delta CRLs,
then it has all the information it needs.

Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Friday, July 06, 2001 10:53 AM
To: Trevor Freeman; David P. Kemp
Cc: [e-mail]
Subject: RE: Should a CRL number be unique or not ?



Hi Trevor,
    I believe what Dave was trying to say, is that by having
a CRLNumber on the delta, you can know what your new effective base is,
so that if the new delta is off a CRL at or before the new effective
base, you can apply it to the locally created CRL data.

For example:

You get a full CRL with CRLNumber 10
Get delta1 with a base of 10 and CRLNumber of 11
Get delta2 with a base of 11 and a CRLNumber of 12

You can now apply delta2 to (CRLNumber 10 + delta1), without ever having
had to get CRLNumber 11.

Hope this helps,
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 9:09 AM
> To: David P. Kemp
> Cc: [e-mail]
> Subject: RE: Should a CRL number be unique or not ?
> 
> 
> Hi Dave,
> 
> I don't see the CRL number is that vital in the construction
> of a local
> CRL.
> 
> The application must start a db of s\n from a base CRL. Then the 
> application needs to update that DB by adding the list of s\n from the

> next delta CRL. The "this update time" can be used to determine from a

> set of deltas, which is the oldest. The only reason you need to apply 
> them in sequence is because of the "remove from CRL" reason codes, 
> otherwise it would not matter. As you process the next delta you will 
> get a number of "collisions", by design which you ignore, these will 
> be because have already either added or removed the s\n referenced in 
> the delta.
> As a point of interest any application doing this behavior with delta
> CRLs only, will start to diverge from applications using base 
> and delta
> CRLs because what these applications will not do is purge s\n of
> certificates which have expired. So technically speaking they will not
> contain identical information.
> 
> Trevor
> 

....[Bunch of stuff deleted]
 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUijCCA0Aw
ggKpoAMCAQICECElZvdedYS4R497WbSp4hIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx
EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv
b3QgQ0EwHhcNMDAwOTIwMjEyNDQ1WhcNMDIwOTIwMjEzMzI4WjBMMQswCQYDVQQGEwJVUzESMBAG
A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD
QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxym3bBtJ93ep9YM9eFtrJSmFA8NG6OtxTKRL
LyorXMYNUzLsdozvGWdSZwlzbvATakzrzriuqq7QgaBzJvS0Oq8yAzthqf0jBQysGvTH1LHieo3b
mCFFOOUtGvfdJGbEMvTb8cT0yxAgPJ7Or0WZta77f/ARUNWWv6g7TNUUhe0CAwEAAaOCASEwggEd
MBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud
DgQWBBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGloIGihk5odHRwOi8v
d2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy
MFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNv
bVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMBAGCSsGAQQBgjcVAQQDAgEA
MA0GCSqGSIb3DQEBBQUAA4GBAAj54W8kzais9v83BJCkQFSgVejj3junPZCxUeCnGzzDmrxUuOPc
ofoYlSwZ/11uLoVVc5qCkEZknWSmwRRViiizyf3dRuYsR9seP2ixJUtKHHwbqHeoQpUpZpOt+czy
LOKJpPc9ihx917XumDCrNTF0Urn8pouG9wYyB3wUnmSdMIIFMDCCBO+gAwIBAgIKYW/U2AAAAAAA
AzAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsT
BU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4X
DTAwMDkyNTIzMjcyM1oXDTAxMDkyNTIzMzQxNlowSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1p
Y3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEAupHMN0lJw9ae2Ic2yZBICCqeP2H6Re4B1Rnk+KETtF0S15jq
7ea5n/+z43Da9CqjunNJaLT7rX4o9NHUN7eP5aKlZ7aRP+EoT0wB51OPsjZKuFWptbdL7PEVHAuO
UrOOjyZ0ITR432vqcJ/L3AouTyuCuN7/1kw9tMMRl5erzkUCAwEAAaOCA10wggNZMBAGCSsGAQQB
gjcVAQQDAgEAMB0GA1UdDgQWBBTJRFZKkBN8qfMzBmve0Jm758jO6TAZBgkrBgEEAYI3FAIEDB4K
AFMAdQBiAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBR5II7e
pN8kVyKCvm3OC5j8FM5BQjCCAVYGA1UdHwSCAU0wggFJMIIBRaCCAUGgggE9hlxodHRwOi8vd2hp
Y2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMEludGVybWVkaWF0ZSUy
MFN1Ym9yZGluYXRlJTIwV2hpY2EyLmNybIaB3GxkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlh
dGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMixDTj13aGljYTIsQ049Q0RQLENOPVB1YmxpYyUyMEtl
eSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWlj
cm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9
Y1JMRGlzdHJpYnV0aW9uUG9pbnQwggFwBggrBgEFBQcBAQSCAWIwggFeMIGDBggrBgEFBQcwAoZ3
aHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2EyLm50ZGV2
Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBJbnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNh
Mi5jcnQwgdUGCCsGAQUFBzAChoHIbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1
Ym9yZGluYXRlJTIwV2hpY2EyLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1T
ZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FD
ZXJ0aWZpY2F0ZT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwCQYHKoZI
zjgEAwMwADAtAhUA5UHxWLBZ8zXgJgd7ecJ4BW5po4ICFCf3VEVyF7k5XJoMIVrDvDBHwVrbMIIF
oTCCBQqgAwIBAgIKGja7EgAAAAAAAjANBgkqhkiG9w0BAQUFADBMMQswCQYDVQQGEwJVUzESMBAG
A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD
QTAeFw0wMDA5MjUyMzI0MTZaFw0wMTA5MjUyMzM0MTZaMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUg
U3Vib3JkaW5hdGUgV2hpY2EyMIIBtjCCASsGByqGSM44BAEwggEeAoGBAM33k4tehmdxq/WAJjhP
tyAwpe/Xs2MX1Jhc2ShMrwnG1hkPkHiYHBfIR7QFKv+J3tlXp1ej93ofwXW9gD1jayyrtfjcNqHK
skGIrYJoVB9WT9BTAlmXEN3gBJgI1Tkh3KsbzpMPDmabhRtb+Ahmn0dUdaxmukabDOJW539YPj/9
AhUA76t5INGQllcDcGCPneHWb2MEDHUCgYA4+rooQzuD3Xf9zRqeEEH0MXR5q1ax9nBBlaE9XnVJ
EqqIUc7nqSWLh85Smp4zUEqaL3nIRPzgPAGl1g3HuEtG3IKQlbIbgg/AsLY6pQfu1oiP7NlH4NWL
kKRDrWbSueFKvBuwNmio0JG7r2MH5OO3QSUKua7Exgsg0RR+rkjfiwOBhAACgYAcJAh8mC7+Ha2b
GsznzWsQiBrcATowbZE2woOE5vLOzAILXRnC2n4Q+C0zDXp80KvPfUNPAGfgk741D/2U0gZEL488
3ASeR4IN3ETWSJHBUGU6l2EXoREy3WScNwo2gZchPPJq9uR7FLLCM9AKprz/Gd6ystAXtwhdZwrH
mawlJaOCAlswggJXMBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBR5II7epN8kVyKCvm3OC5j8
FM5BQjAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAcYwDwYDVR0TAQH/BAUw
AwEB/zAfBgNVHSMEGDAWgBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGl
oIGihk5odHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwv
TlRERVYlMjBTQSUyMFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYu
bWljcm9zb2Z0LmNvbVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMIIBDwYI
KwYBBQUHAQEEggEBMIH+MHwGCCsGAQUFBzAChnBodHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5t
aWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29t
X05UREVWJTIwU0ElMjBSb290JTIwQ0EuY3J0MH4GCCsGAQUFBzAChnJmaWxlOi8vXFx3aGljYXNh
cm9vdGNhLm50ZGV2Lm1pY3Jvc29mdC5jb21cQ2VydEVucm9sbFx3aGljYXNhcm9vdGNhLm50ZGV2
Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBTQSUyMFJvb3QlMjBDQS5jcnQwDQYJKoZIhvcNAQEFBQAD
gYEAL4HlyexkgagQx3sh6yj2kff49+Kpg2cNW+BmHoAEhjk/0A9knSiOsdKxpICFqAe62YJ5tntl
4LtnW8LMnGwt9pp1nDC66thpoAXl9Nw0iP9r+xNtZGZovKQ6ZBiM1ph9kLqHfCVYGmsrOYIM9X5h
MqVdm5OdWwTnZmh08TirPRwwggZpMIIF0qADAgECAgo+xCJqAAAAApu4MA0GCSqGSIb3DQEBBQUA
MEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYD
VQQDEw9OVERFViBJU1NVRTMgQ0EwHhcNMDEwNDI3MTgzMTI3WhcNMDEwOTI1MjMzNDE2WjCBrDET
MBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEVMBMGCgmSJomT
8ixkARkWBW50ZGV2MQwwCgYDVQQLEwNJVEcxDjAMBgNVBAsTBVVzZXJzMRcwFQYDVQQDEw5UcmV2
b3IgRnJlZW1hbjEsMCoGCSqGSIb3DQEJARYddHJldm9yZkB3aW5kb3dzLm1pY3Jvc29mdC5jb20w
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALMVg148IfruQrM0j5qas4ZbiYpKLglnKd3G2/TQ
SUGMkh4L06jyZJdnYD9V5okQTuvNeAiItg7AYOZYvEltA6fSP3e1GYqjZeJ5pXJjCECuebcbNb9c
qNQJjukjDGLYvlq8pT2c0I4R+olx9k4aowthS951IzkcTnl2APmWAY4zAgMBAAGjggPwMIID7DAL
BgNVHQ8EBAMCBLAwNgYJKoZIhvcNAQkPBCkwJzANBggqhkiG9w0DAgIBODANBggqhkiG9w0DBAIB
ODAHBgUrDgMCBzA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+m
FYenvuIJjrGt8U0CAW0CAQAwHQYDVR0OBBYEFG9xWGRt1a6bGtu2+SM1nyIeq+qTMB8GA1UdIwQY
MBaAFMlEVkqQE3yp8zMGa97QmbvnyM7pMIIBJgYDVR0fBIIBHTCCARkwggEVoIIBEaCCAQ2GRGh0
dHA6Ly93aGljYTMubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUz
JTIwQ0EuY3JshoHEbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENBLENOPXdoaWNhMyxDTj1D
RFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv
bixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/
YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAT8GCCsGAQUFBwEBBIIBMTCC
AS0wawYIKwYBBQUHMAKGX2h0dHA6Ly93aGljYTMubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5y
b2xsL3doaWNhMy5udGRldi5taWNyb3NvZnQuY29tX05UREVWJTIwSVNTVUUzJTIwQ0EuY3J0MIG9
BggrBgEFBQcwAoaBsGxkYXA6Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSxDTj1BSUEsQ049UHVi
bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRl
dixEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0
aWZpY2F0aW9uQXV0aG9yaXR5MBMGA1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcVCgQOMAww
CgYIKwYBBQUHAwQwVQYDVR0RBE4wTKArBgorBgEEAYI3FAIDoB0MG3RyZXZvcmZAbnRkZXYubWlj
cm9zb2Z0LmNvbYEddHJldm9yZkB3aW5kb3dzLm1pY3Jvc29mdC5jb20wLwYJKwYBBAGCNxQCBCIe
IABBAHUAdABvAEUAeABjAGgAYQBuAGcAZQBVAHMAZQByMA0GCSqGSIb3DQEBBQUAA4GBAHF2BsCe
UuP9UrqvEXcXRAex+Dze5RWoC3e6atdC0NyiJLSndI+uvD7xBdpxP7MOKtUmcBgzyvBJ9+Ls2eZy
M8U8tmXHwHzZ9l/HEY8xr/0G27A3H4CDAP4hHhsv2hVh5NMTg/t68iyRuupLQQJhmSAOUtrr73Mk
hbjMbAyxe3PaMYICnzCCApsCAQEwWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0
MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgo+xCJqAAAAApu4MAkG
BSsOAwIaBQCgggGcMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAx
MDcwNjE4NDQ0NVowIwYJKoZIhvcNAQkEMRYEFK1tS+3mJ2eMrRcJBRHEXfkChMA2MGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCSsGAQQBgjcQBDFbMFkw
SzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNV
BAMTD05UREVWIElTU1VFMyBDQQIKPsQiagAAAAKbuDBqBgsqhkiG9w0BCRACCzFboFkwSzELMAkG
A1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05U
REVWIElTU1VFMyBDQQIKPsQiagAAAAKbuDANBgkqhkiG9w0BAQEFAASBgHqF4u2DeB6d0YSpmrFw
h8oCqAeGOim1WsMHrEU8jHp6tC1HO64fmSSVk4uCrn9KdtIhDDG0pwZw08V9Jw+w8juBbOhosrz4
XEu5snr/VpX/404jN60RbpvTG5iM3R73c0oh7e+A/X24dp86r/c4S9Kh5RTHWREP/FMu7SLh9mdn
AAAAAAAA

------=_NextPart_000_0048_01C10611.0D48F3A0--


Received: by above.proper.com (8.11.3/8.11.3) id f66HvI411791 for ietf-pkix-bks; Fri, 6 Jul 2001 10:57:18 -0700 (PDT)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66HvIm11787 for <[e-mail]>; Fri, 6 Jul 2001 10:57:18 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 6 Jul 2001 10:57:42 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 06 Jul 2001 10:57:41 -0700 (PDT)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <N8CDMGMB>; Fri, 06 Jul 2001 10:53:15 -0700
Content-return: allowed
Date: Fri, 06 Jul 2001 10:53:13 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Should a CRL number be unique or not ?
To: "'Trevor Freeman'" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi Trevor,
    I believe what Dave was trying to say, is that by having
a CRLNumber on the delta, you can know what your new effective
base is, so that if the new delta is off a CRL at or before
the new effective base, you can apply it to the locally
created CRL data.

For example:

You get a full CRL with CRLNumber 10
Get delta1 with a base of 10 and CRLNumber of 11
Get delta2 with a base of 11 and a CRLNumber of 12

You can now apply delta2 to (CRLNumber 10 + delta1), without
ever having had to get CRLNumber 11.

Hope this helps,
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Friday, July 06, 2001 9:09 AM
> To: David P. Kemp
> Cc: [e-mail]
> Subject: RE: Should a CRL number be unique or not ?
> 
> 
> Hi Dave,
> 
> I don't see the CRL number is that vital in the construction 
> of a local
> CRL.
> 
> The application must start a db of s\n from a base CRL. Then the
> application needs to update that DB by adding the list of s\n from the
> next delta CRL. The "this update time" can be used to determine from a
> set of deltas, which is the oldest. The only reason you need to apply
> them in sequence is because of the "remove from CRL" reason codes,
> otherwise it would not matter. As you process the next delta you will
> get a number of "collisions", by design which you ignore, 
> these will be
> because have already either added or removed the s\n referenced in the
> delta. 
> As a point of interest any application doing this behavior with delta
> CRLs only, will start to diverge from applications using base 
> and delta
> CRLs because what these applications will not do is purge s\n of
> certificates which have expired. So technically speaking they will not
> contain identical information.
> 
> Trevor
> 

....[Bunch of stuff deleted]
 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66GXLI10140 for ietf-pkix-bks; Fri, 6 Jul 2001 09:33:21 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.3/8.11.3) with SMTP id f66GXJm10136 for <[e-mail]>; Fri, 6 Jul 2001 09:33:19 -0700 (PDT)
Received: from 157.54.9.104 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Jul 2001 09:06:58 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 09:09:36 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 09:09:20 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 09:08:45 -0700
content-class: urn:content-classes:message
Subject: RE: Should a CRL number be unique or not ?
MIME-Version: 1.0
Date: Fri, 6 Jul 2001 09:08:45 -0700
Content-Type: multipart/signed; boundary="----=_NextPart_000_0005_01C105FB.606A3D70"; protocol="application/x-pkcs7-signature"; micalg=SHA1
X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Should a CRL number be unique or not ?
Thread-Index: AcEDPfRsjBBO8PJUSPKH7MBuOKROAQA5ASAw
From: "Trevor Freeman" <[e-mail]>
To: "David P. Kemp" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 06 Jul 2001 16:08:45.0890 (UTC) FILETIME=[EF2E3220:01C10635]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C105FB.606A3D70
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Dave,

I don't see the CRL number is that vital in the construction of a local
CRL.

The application must start a db of s\n from a base CRL. Then the
application needs to update that DB by adding the list of s\n from the
next delta CRL. The "this update time" can be used to determine from a
set of deltas, which is the oldest. The only reason you need to apply
them in sequence is because of the "remove from CRL" reason codes,
otherwise it would not matter. As you process the next delta you will
get a number of "collisions", by design which you ignore, these will be
because have already either added or removed the s\n referenced in the
delta. 
As a point of interest any application doing this behavior with delta
CRLs only, will start to diverge from applications using base and delta
CRLs because what these applications will not do is purge s\n of
certificates which have expired. So technically speaking they will not
contain identical information.

Trevor

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]] 
Sent: Monday, July 02, 2001 2:17 PM
Cc: [e-mail]
Subject: Re: Should a CRL number be unique or not ?



Trevor Freeman wrote:
> 
> Sorry to be a heretic, but why do we need a CRL number in the delta
> CRL? The "This Update" time seems far less ambiguous as a mechanism 
> for determining succession of delta CRLs - without resorting so 
> linguistic gymnastics. Having determined the delta CRL is of the same 
> scope which the CRL numner plays no pary, a simple comparison of the 
> This update time tells me which came last. Just keep the CRL number in

> the base since you need that for the delta CRL indecator extension.


Trevor,

That would be correct if a delta (call it "delta B") were applied only
to a complete CRL downloaded by the application.

But it is possible to save bandwidth by locally constructing the base
CRL instead of downloading a complete CRL.  Since the constructed base
needs a CRL number, the delta ("delta A") used to construct it must have
a CRL number.

   Complete CRL: ->  Delta A:
    CRL# = 1          baseCRL# = 1
                      CRL# = 2

                       |
                       V

                     locally-constructed   ->  Delta B:
                     complete CRL:              baseCRL# = 2
                      CRL# = 2

An application that supports delta CRLs is not required to support local
construction.  But an application that performs local construction
requires the CRL number extension to be present in delta CRLs - the
application cannot function without that extension regardless of whether
constructed CRLs are "numbered".

Denis argues that although the constructed CRL is built from Delta A and
Delta A must have a CRL number, the constructed CRL need not be assigned
a number.  That line of reasoning strikes me as pure sophistry. But
regardless of its merits, the identical argument can be made against
propogating thisUpdate and nextUpdate from Delta A to the constructed
CRL. Not propogating CRL number does not make the algorithm any more
general, it merely forces the algorithm description to be more verbose.


Denis says:
> This would lead to option D:
> 
>    The CRL number is a non-critical CRL extension which conveys a
>    unique number for a given CRL scope and CRL issuer. CRL issuers 
>    conforming to this profile MUST include this extension in all CRLs.
> 
> Only for reasons of backward compatibility, I will not push this
> proposal, but we have to understand that CRL numbers have an unneeded 
> and overloaded semantics. So why we should make clear that local CRL 
> numbers are no more than ONE way to implement an algorithm that could 
> also be implemented using thisUpdate. Saying that using an algorithm 
> that exhibits the same properties would be equally valid is not 
> enough, because the reader will understand that the algorithm has to 
> use CRL numbers. It would help to say that an algorithm using 
> thisUpdate could also be constructed.

The reader will understand correctly that any algorithm for constructed
CRLs requires delta CRLs to contain the CRL number extension.  An
algorithm using thisUpdate and CRL number is possible; an algorithm
using thisUpdate alone is not.

Moreover, if as in option D CRL numbers are merely unique and not
time-ordered, then an application cannot use a base CRL more recent than
that specified in the deltaCRLIndicator extension.  You were previously
happy when Russ changed "greater than or equal to" to "equal to or
greater than". Option D would force it to be exactly "equal to" and
would make thisUpdate irrelevant when matching a delta to its base.  You
can't have it both ways; either you want a construction algorithm which
permits the use of thisUpdate, or you want CRL numbers to be unique but
unordered thereby excluding the use of thisUpdate.

If a new delta CRL extension were defined which contained a
"baseThisUpdate" time, then an alternate algorithm which does not use
CRL numbers would be possible. But PKIX requires delta CRLs to contain
the deltaCRLIndicator extension and PKIX does not profile the X.509
crlScope extension, therefore an algorithm using thisUpdate alone to
link a delta to its base cannot be defined within this edition of Part
1.  Perhaps in grandson-of-2459.

Regards,
Dave

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUijCCA0Aw
ggKpoAMCAQICECElZvdedYS4R497WbSp4hIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx
EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv
b3QgQ0EwHhcNMDAwOTIwMjEyNDQ1WhcNMDIwOTIwMjEzMzI4WjBMMQswCQYDVQQGEwJVUzESMBAG
A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD
QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxym3bBtJ93ep9YM9eFtrJSmFA8NG6OtxTKRL
LyorXMYNUzLsdozvGWdSZwlzbvATakzrzriuqq7QgaBzJvS0Oq8yAzthqf0jBQysGvTH1LHieo3b
mCFFOOUtGvfdJGbEMvTb8cT0yxAgPJ7Or0WZta77f/ARUNWWv6g7TNUUhe0CAwEAAaOCASEwggEd
MBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud
DgQWBBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGloIGihk5odHRwOi8v
d2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy
MFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNv
bVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMBAGCSsGAQQBgjcVAQQDAgEA
MA0GCSqGSIb3DQEBBQUAA4GBAAj54W8kzais9v83BJCkQFSgVejj3junPZCxUeCnGzzDmrxUuOPc
ofoYlSwZ/11uLoVVc5qCkEZknWSmwRRViiizyf3dRuYsR9seP2ixJUtKHHwbqHeoQpUpZpOt+czy
LOKJpPc9ihx917XumDCrNTF0Urn8pouG9wYyB3wUnmSdMIIFMDCCBO+gAwIBAgIKYW/U2AAAAAAA
AzAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsT
BU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4X
DTAwMDkyNTIzMjcyM1oXDTAxMDkyNTIzMzQxNlowSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1p
Y3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEAupHMN0lJw9ae2Ic2yZBICCqeP2H6Re4B1Rnk+KETtF0S15jq
7ea5n/+z43Da9CqjunNJaLT7rX4o9NHUN7eP5aKlZ7aRP+EoT0wB51OPsjZKuFWptbdL7PEVHAuO
UrOOjyZ0ITR432vqcJ/L3AouTyuCuN7/1kw9tMMRl5erzkUCAwEAAaOCA10wggNZMBAGCSsGAQQB
gjcVAQQDAgEAMB0GA1UdDgQWBBTJRFZKkBN8qfMzBmve0Jm758jO6TAZBgkrBgEEAYI3FAIEDB4K
AFMAdQBiAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBR5II7e
pN8kVyKCvm3OC5j8FM5BQjCCAVYGA1UdHwSCAU0wggFJMIIBRaCCAUGgggE9hlxodHRwOi8vd2hp
Y2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMEludGVybWVkaWF0ZSUy
MFN1Ym9yZGluYXRlJTIwV2hpY2EyLmNybIaB3GxkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlh
dGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMixDTj13aGljYTIsQ049Q0RQLENOPVB1YmxpYyUyMEtl
eSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWlj
cm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9
Y1JMRGlzdHJpYnV0aW9uUG9pbnQwggFwBggrBgEFBQcBAQSCAWIwggFeMIGDBggrBgEFBQcwAoZ3
aHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2EyLm50ZGV2
Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBJbnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNh
Mi5jcnQwgdUGCCsGAQUFBzAChoHIbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1
Ym9yZGluYXRlJTIwV2hpY2EyLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1T
ZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FD
ZXJ0aWZpY2F0ZT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwCQYHKoZI
zjgEAwMwADAtAhUA5UHxWLBZ8zXgJgd7ecJ4BW5po4ICFCf3VEVyF7k5XJoMIVrDvDBHwVrbMIIF
oTCCBQqgAwIBAgIKGja7EgAAAAAAAjANBgkqhkiG9w0BAQUFADBMMQswCQYDVQQGEwJVUzESMBAG
A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD
QTAeFw0wMDA5MjUyMzI0MTZaFw0wMTA5MjUyMzM0MTZaMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUg
U3Vib3JkaW5hdGUgV2hpY2EyMIIBtjCCASsGByqGSM44BAEwggEeAoGBAM33k4tehmdxq/WAJjhP
tyAwpe/Xs2MX1Jhc2ShMrwnG1hkPkHiYHBfIR7QFKv+J3tlXp1ej93ofwXW9gD1jayyrtfjcNqHK
skGIrYJoVB9WT9BTAlmXEN3gBJgI1Tkh3KsbzpMPDmabhRtb+Ahmn0dUdaxmukabDOJW539YPj/9
AhUA76t5INGQllcDcGCPneHWb2MEDHUCgYA4+rooQzuD3Xf9zRqeEEH0MXR5q1ax9nBBlaE9XnVJ
EqqIUc7nqSWLh85Smp4zUEqaL3nIRPzgPAGl1g3HuEtG3IKQlbIbgg/AsLY6pQfu1oiP7NlH4NWL
kKRDrWbSueFKvBuwNmio0JG7r2MH5OO3QSUKua7Exgsg0RR+rkjfiwOBhAACgYAcJAh8mC7+Ha2b
GsznzWsQiBrcATowbZE2woOE5vLOzAILXRnC2n4Q+C0zDXp80KvPfUNPAGfgk741D/2U0gZEL488
3ASeR4IN3ETWSJHBUGU6l2EXoREy3WScNwo2gZchPPJq9uR7FLLCM9AKprz/Gd6ystAXtwhdZwrH
mawlJaOCAlswggJXMBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBR5II7epN8kVyKCvm3OC5j8
FM5BQjAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAcYwDwYDVR0TAQH/BAUw
AwEB/zAfBgNVHSMEGDAWgBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGl
oIGihk5odHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwv
TlRERVYlMjBTQSUyMFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYu
bWljcm9zb2Z0LmNvbVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMIIBDwYI
KwYBBQUHAQEEggEBMIH+MHwGCCsGAQUFBzAChnBodHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5t
aWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29t
X05UREVWJTIwU0ElMjBSb290JTIwQ0EuY3J0MH4GCCsGAQUFBzAChnJmaWxlOi8vXFx3aGljYXNh
cm9vdGNhLm50ZGV2Lm1pY3Jvc29mdC5jb21cQ2VydEVucm9sbFx3aGljYXNhcm9vdGNhLm50ZGV2
Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBTQSUyMFJvb3QlMjBDQS5jcnQwDQYJKoZIhvcNAQEFBQAD
gYEAL4HlyexkgagQx3sh6yj2kff49+Kpg2cNW+BmHoAEhjk/0A9knSiOsdKxpICFqAe62YJ5tntl
4LtnW8LMnGwt9pp1nDC66thpoAXl9Nw0iP9r+xNtZGZovKQ6ZBiM1ph9kLqHfCVYGmsrOYIM9X5h
MqVdm5OdWwTnZmh08TirPRwwggZpMIIF0qADAgECAgo+xCJqAAAAApu4MA0GCSqGSIb3DQEBBQUA
MEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYD
VQQDEw9OVERFViBJU1NVRTMgQ0EwHhcNMDEwNDI3MTgzMTI3WhcNMDEwOTI1MjMzNDE2WjCBrDET
MBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEVMBMGCgmSJomT
8ixkARkWBW50ZGV2MQwwCgYDVQQLEwNJVEcxDjAMBgNVBAsTBVVzZXJzMRcwFQYDVQQDEw5UcmV2
b3IgRnJlZW1hbjEsMCoGCSqGSIb3DQEJARYddHJldm9yZkB3aW5kb3dzLm1pY3Jvc29mdC5jb20w
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALMVg148IfruQrM0j5qas4ZbiYpKLglnKd3G2/TQ
SUGMkh4L06jyZJdnYD9V5okQTuvNeAiItg7AYOZYvEltA6fSP3e1GYqjZeJ5pXJjCECuebcbNb9c
qNQJjukjDGLYvlq8pT2c0I4R+olx9k4aowthS951IzkcTnl2APmWAY4zAgMBAAGjggPwMIID7DAL
BgNVHQ8EBAMCBLAwNgYJKoZIhvcNAQkPBCkwJzANBggqhkiG9w0DAgIBODANBggqhkiG9w0DBAIB
ODAHBgUrDgMCBzA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+m
FYenvuIJjrGt8U0CAW0CAQAwHQYDVR0OBBYEFG9xWGRt1a6bGtu2+SM1nyIeq+qTMB8GA1UdIwQY
MBaAFMlEVkqQE3yp8zMGa97QmbvnyM7pMIIBJgYDVR0fBIIBHTCCARkwggEVoIIBEaCCAQ2GRGh0
dHA6Ly93aGljYTMubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUz
JTIwQ0EuY3JshoHEbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENBLENOPXdoaWNhMyxDTj1D
RFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv
bixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/
YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAT8GCCsGAQUFBwEBBIIBMTCC
AS0wawYIKwYBBQUHMAKGX2h0dHA6Ly93aGljYTMubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5y
b2xsL3doaWNhMy5udGRldi5taWNyb3NvZnQuY29tX05UREVWJTIwSVNTVUUzJTIwQ0EuY3J0MIG9
BggrBgEFBQcwAoaBsGxkYXA6Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSxDTj1BSUEsQ049UHVi
bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRl
dixEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0
aWZpY2F0aW9uQXV0aG9yaXR5MBMGA1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcVCgQOMAww
CgYIKwYBBQUHAwQwVQYDVR0RBE4wTKArBgorBgEEAYI3FAIDoB0MG3RyZXZvcmZAbnRkZXYubWlj
cm9zb2Z0LmNvbYEddHJldm9yZkB3aW5kb3dzLm1pY3Jvc29mdC5jb20wLwYJKwYBBAGCNxQCBCIe
IABBAHUAdABvAEUAeABjAGgAYQBuAGcAZQBVAHMAZQByMA0GCSqGSIb3DQEBBQUAA4GBAHF2BsCe
UuP9UrqvEXcXRAex+Dze5RWoC3e6atdC0NyiJLSndI+uvD7xBdpxP7MOKtUmcBgzyvBJ9+Ls2eZy
M8U8tmXHwHzZ9l/HEY8xr/0G27A3H4CDAP4hHhsv2hVh5NMTg/t68iyRuupLQQJhmSAOUtrr73Mk
hbjMbAyxe3PaMYICnzCCApsCAQEwWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0
MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgo+xCJqAAAAApu4MAkG
BSsOAwIaBQCgggGcMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAx
MDcwNjE2MDkzNVowIwYJKoZIhvcNAQkEMRYEFKJfoiCD36ALPEkt2Ls1OAMly3yfMGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCSsGAQQBgjcQBDFbMFkw
SzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNV
BAMTD05UREVWIElTU1VFMyBDQQIKPsQiagAAAAKbuDBqBgsqhkiG9w0BCRACCzFboFkwSzELMAkG
A1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05U
REVWIElTU1VFMyBDQQIKPsQiagAAAAKbuDANBgkqhkiG9w0BAQEFAASBgKll9URyM8YzWsKxkhgW
v+mUsgkFo8DH5bwAivITjT6cgpIizxycq3FHNHOK2GNvrOMF80cAFVACt9jXgFtHWe6RKHuh4xrV
0uU1YB4BOcD4PJZiei5EQbZc1/R/bhO+rG70i1OaRafQ0NifyrDs+tqOFjObCAz4R/xuWw54HN5K
AAAAAAAA

------=_NextPart_000_0005_01C105FB.606A3D70--


Received: by above.proper.com (8.11.3/8.11.3) id f65LXYM25100 for ietf-pkix-bks; Thu, 5 Jul 2001 14:33:34 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65LXWm25096 for <[e-mail]>; Thu, 5 Jul 2001 14:33:32 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA05030 for <[e-mail]>; Thu, 5 Jul 2001 17:33:33 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 05 Jul 2001 17:33:15 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: mail from submission manager
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

FYI,

For those who are curious, some bone head (me) sent the message summarizing 
the changes in the 08 draft of son-of-2459 to the internet-drafts editors 
rather than the PKIX list.  Once I noted the problem, I sent a "please 
ignore" message to them.  The two email messages from the Internet Draft 
Submission Manager were auto replies to my messages.

I would like to point out that most Americans are on vacation.  My brain is 
simply asserting its right to celebrate the fourth by refusing to do 
*anything*.  Sigh.

Anyway, ignore those messages!

Thanks,

Tim




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f65KKZf23286 for ietf-pkix-bks; Thu, 5 Jul 2001 13:20:35 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65KKXm23282 for <[e-mail]>; Thu, 5 Jul 2001 13:20:33 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id QAA01250 for <[e-mail]>; Thu, 5 Jul 2001 16:20:34 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 05 Jul 2001 16:20:15 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new-part1-08.txt)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Folks,

You may have noticed a new draft of son-of-2459 is now available.  I 
strongly believe this draft represents rough consensus for the WG, and wish 
to forward this draft to the ADs.  I recognize that many people have some 
level of discomfort in different areas, but this document is the best we 
can do.

We have worked certain areas to death, such as delta CRLs, without reaching 
perfect consensus.  *It is my opinion that we never will reach perfect 
consensus in these areas.*  It is also my opinion that this draft reflects 
the thinking of a clear majority of the WG in the disputed areas.  In light 
of this, I believe we (the WG) should limit ours discussion of this draft 
to (1) errors introduced inadvertently in the last editing cycle or (2) 
areas where you believe the editors misrepresented the WG consensus.

As long as we stay at Internet-Draft we are encouraging developers to use 
the old spec.   I believe this document provides a significant enhancement 
over RFC 2459 in many areas, and the industry needs to move to this 
specification.  The path validation and CRL validation sections are far 
more comprehensive and complete than in 2459; the description of CRL s and 
CRL extensions is more complete as well.  This document is aligned with the 
current ISO X.509 and is compatible with the ETSI digital signature 
draft.  In short, there is no *compelling reason* to delay this document 
any further.

It's time to move on to the implementation phase.  Remember, we are cycling 
at Proposed Standard here.  After we perform our interoperability testing, 
we can refine this document as we go to draft standard.

I just completed a review of the diff of the 07 and 08 nroff files.  In my 
opinion, all the differences are minor.  I have summarized them all below:

The differences in technical content between drafts 07 and 08 are as follows:

(a) The text has been clarified regarding the difference between 
self-signed and self-issued certificates.  (various sections)

(b)  The text has been clarified regarding the conformance requirements for 
CRL support.  (section 5).

(c)  The text has been clarified encoding of DNS names in the issuer and 
issuer alternative name fields: both the domainComponent form in the issuer 
field and the DNS name in the issuer alternative name field are 
permitted.  (section 5.2.2, Issuer Alternative Name).

(d)  The text in Section 5.2.4 that describes when a certificate should be 
listed on a delta CRL has been rewritten for consistency with ISO 
X.509.  When a revocation reason is changed (e.g., from keyCompromise to 
affilitationChanged) and the new reason was outside the scope of the delta 
CRL, the 07 text listed the certificate with "removeFromCRL".  After 
discussion with the ISO X.509 editor, this was determined to be 
inappropriate; removeFromCRL is *only* used when a certificate is removed 
from hold.  A client might be confused into accepting the certificate as 
valid.  The 08 text maintains the revocation listing on a delta without a 
reason code as long as some valid base CRL lists the revocation with the 
incorrect reason code.  [check this one out.] (5.2.4)

(e) The text defines "current delta CRL" as a delta where current time is 
between this update and next update.  The text recommends that an 
application that encounters mutiple "current deltas should use the one with 
the latest this update.  (end of 5.2.4)

(f) The text for the freshest CRL extension adds semantics.  Previously, 
this text just pointed to 4.2.1.14 for syntax.  (5.2.6)

(g) The certification path validation algorithm assumes validation with 
respect to current time, just like the CRL text.  The text explicitly notes 
that the algorithm may be extended to handle times in the past. [This 
change was made so that path validation and CRL validation were 
parallel.  Validation with respect to a time in the past is not mandatory 
to implement, so we excluded it in both sections.] (section 6.1)

(h) We added examples for the processing of name constraints.  Intersection 
and union of name spaces isn't particularly intuitive. (6.1.4, steps (g) 
(1) and (g) (2))

(i) We added the requirement that implementations process noncritical 
extensions that they recognize in addition to all critical extensions. 
(6.1.4, step (o))

(j) We expanded the text describing matching the CRL to the certificate 
using the IDP in the CRL and the DP in the certificate. (6.3.3, step (b) 
(2) (i))

(j) We replaced the certificate and CRL examples, using the most recent 
version of the dumpasn1 program.  We had used an older version that did not 
parse the "encapsulated" ASN.1 found in certificate extensions, etc.

(k) We added new paragraphs to the ASN.1 implementers notes covering the 
following topics:  ampersand and underscore aren't in PrintableString; 
encoding of named bit lists; and DER encoding of components that have 
DEFAULT values.

There were also a number of editorial corrections:

(1) We changed the word "null" to "empty" in a few cases to eliminate 
confusion between the ASN.1 NULL and an empty sequence.

(2) We fixed a reference to X.660.

(3) Russ made a number of formatting changes for the sake of consistency, 
such as two spaces after a list number or letter (e.g., (a) or (1) ).

This seems like a long list, but as I said above, I believe all are minor!

It is my goal to forward this document to the ADs Tuesday the 10th at close 
of business.  (I am on vacation the 11th through the 13th.)  Please look at 
the changes noted above.  If the editors have misrepresented consensus, 
let's fix it.  Otherwise, it is time to move forward.

Thanks,

Tim Polk


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 
Certificate
                           and CRL Profile
         Author(s)       : R. Housley, W. Ford, W. Polk, D. Solo
         Filename        : draft-ietf-pkix-new-part1-08.txt
         Pages           : 128
         Date            : 02-Jul-01

This is the eighth draft of a specification based upon RFC 2459.
When complete, this specification will obsolete RFC 2459.
Please send comments on this document to the [e-mail] mail
list.
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
in the Internet.

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

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

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


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

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

NOTE:   The mail server at ietf.org can return the document in
         MIME-encoded form by using the "mpack" utility.  To use this
         feature, insert the command "ENCODING mime" before the "FILE"
         command.  To decode the response(s), you will need "munpack" or
         a MIME-compliant mail reader.  Different MIME-compliant mail readers
         exhibit different behavior, especially when dealing with
         "multipart" MIME messages (i.e. documents which have been split
         up into multiple messages), so check your local documentation on
         how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:     <[e-mail]>

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

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-08.txt>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63DlSC13841 for ietf-pkix-bks; Tue, 3 Jul 2001 06:47:28 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63DlRm13837 for <[e-mail]>; Tue, 3 Jul 2001 06:47:27 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 03 Jul 2001 09:43:24 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Tom,

It isn't a question of whether "X.509" does or does not rely on the security
of repositories and administrators.  The question I see is:  "I have to design
a secure system -- what is the minimal set of properties that that system must
have in order to meet the desired level of assurance?"

You always have to analyze the personnel and practices of the CA and CRL issuer.
But if you choose a design that requires repositories to have security
properties,
you also have to analyze the personnel and practices of all the repositories
that might be used by client applications.  If there's only one repository
controlled by the CA, that might not be too much of an extra burden.  But if
there are geographically distributed repositories then that is just N extra
security evaluations to be performed.  If you use HTTP for CRL caching and
distribution, as I believe is desirable, you would be required to evaluate
the security of independent service providers who provide reliable, available,
high capacity service but who may not even be able to spell PKI.

The easier way is to use writer-to-reader (CRL issuer-to-application) security.
Issue delta CRLs as often as the most critical application needs revocation
information - I don't think every 15 minutes is too extreme an issuance period
for high-risk applications.  Allow, but don't rely on guaranteed receipt of,
unscheduled CRLs and your assurance job will be much easier.

On this point I agree with Denis.

Dave




Tom Gindin wrote:
> 
>      Your first case is indeed certainly a security concern, but I'm not
> sure the second one is easily distinguishable from an LDAP problem - what
> attacker is suppressing the extra CRL's?  I am skeptical, as you may have
> seen from my discussion with Santosh, that X.509 does NOT rely on the
> security of the repositories or of their administrators.  This statement is
> true only insofar as the RP is expected to verify the signature of CRL's or
> certificates retrieved from the repositories so that data which was never
> valid cannot be imposed on the RP.  It does not really apply to the
> suppression of unscheduled CRL's (including most deltas, I think) - since
> an RP will not know that the unscheduled CRL is missing and will wrongly
> assume that the base CRL (or the earlier CRL if deltas are not used) is the
> current intended set of revocation information.
>      To rephrase my earlier statement to Santosh, while the primary
> reliance in a distributed PKI is on the key, I do not believe that this
> reliance should be exclusive.  This statement is not purely philosophical,
> as it can have direct impact on the set of inputs needed to represent a
> trust anchor, for example.
> 
>           Tom Gindin


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63DDQg13239 for ietf-pkix-bks; Tue, 3 Jul 2001 06:13:26 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63DDOm13234 for <[e-mail]>; Tue, 3 Jul 2001 06:13:24 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <3GB3BQKM>; Tue, 3 Jul 2001 09:13:18 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Tom Gindin <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: Marc Branchaud <[e-mail]>, [e-mail]
Subject: RE: caCompromise
Date: Tue, 3 Jul 2001 09:02:47 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C103C0.7532EB40"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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

------_=_NextPart_001_01C103C0.7532EB40
Content-Type: text/plain;
	charset="iso-8859-1"

Tom:

An unscheduled CRL can be hidden from RP even if the repository is trusted.
One can attack the network by suppressing the unscheduled CRL and replaying
the routine one.  Now, if you assume that you are running a trusted network
in addition to a trusted repository, you already have some of the security
services that PKI offers and in that case PKI may be an overkill.

These issues have been dealt with in 1988 time frame when distributed
authentication framework for PKI was developed.  We can have a discussion on
this one on one, but I think others on the list may find it not worthwhile.

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Monday, July 02, 2001 7:57 PM
To: Santosh Chokhani
Cc: Marc Branchaud; [e-mail]
Subject: RE: caCompromise



     I am certainly not questioning primary reliance on the key for
security in a distributed PKI, but I am questioning EXCLUSIVE reliance on
it.  In contradiction to one of your points, an unscheduled CRL can be
hidden from RP's (or from those OCSP servers which are fed by CRL's) by an
attack on the revocation repository, even without a key compromise, and the
result of that is more severe than just a denial of service.  My own view
is that a repository is better than nothing as a fallback for detecting a
key compromise, as well.

          Tom Gindin



Santosh Chokhani <[e-mail]> on 07/02/2001 08:39:31 AM

To:   Tom Gindin <[e-mail]>, Santosh Chokhani
      <[e-mail]>
cc:   Marc Branchaud <[e-mail]>, [e-mail]
Subject:  RE: caCompromise


Tom:


I suspected that is what you were driving at.  However, in distributed
authentication framework of PKI, we do not depend on the security of the
repository or the network.  Thus, the CA private keys are all that need to
be secured.  If the some one breaks those keys, we assume there is a
potential for compromise.  Absent, that all an adversary can cause is
denial of service.


-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Sunday, July 01, 2001 11:31 PM
To: Santosh Chokhani
Cc: Marc Branchaud; [e-mail]
Subject: RE: caCompromise






     If the publication site is known to the RP independently, someone
compromising a CA key needs to also take control of that site (or spoof the

paths to it) in order to effectively fool RP's into accepting certificates
issued by the compromiser.    Some of the improvements in flexibility in
specifying publication sites in a certificate (notably AIA's and CRL DP's)
allow an attacker to specify that revocation information will be published
at sites under his own control for certificates which he himself generates,

thus rendering a CA compromise even more catastrophic than it would
otherwise be.  This is similar to what Ambarish pointed out, I think.
     This effect can be lessened if the definition of a trust anchor
constrains the location of the revocation information sufficiently that an
attacker cannot do this, although CRL's without distribution points are
sufficiently constrained themselves.  This thread has been dealing with the

consequences of CA Compromise and means of ensuring that RP's are notified
of that condition.


          Tom Gindin





Santosh Chokhani <[e-mail]> on 06/30/2001 12:22:15 PM


To:   Tom Gindin/Watson/IBM@IBMUS, Marc Branchaud
      <[e-mail]>
cc:   [e-mail]
Subject:  RE: caCompromise





Tom:





I do not understand much of what you are saying.  It seems that you are
pointing to a class of problems which do not exist in terms of CRL DP
spoofing.  Can you clarify what you are saying?  Thanks in advance....








-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Friday, June 29, 2001 7:33 PM
To: Marc Branchaud
Cc: [e-mail]
Subject: Re: caCompromise










     One question which this discussion brings up is whether the principle
"Security resides solely in the key" really applies to trust anchors, or
whether a trust anchor is more appropriately expressed as the product of a
public key and a communications path (for CA's, some of the constraint
extensions are also potentially appropriate).  Ambarish's earlier point
about an attacker avoiding the detection of a compromise via OCSP by
issuing a certificate with an AIA pointing to a compromised system suggests


this direction, and the same thing can be done to a CRL user by abusing
named distribution points.  The original use of CRL's implied a fixed
directory name as a point of distribution instead - which happened to stop
this particular class of attack.
     After all, compromising a key does not always imply compromising the
physical server where it is used, although it often can.





          Tom Gindin








Marc Branchaud <[e-mail]>@mail.imc.org on 06/27/2001
07:41:17 PM





Sent by:  [e-mail]








To:   [e-mail]
cc:
Subject:  Re: caCompromise










Ambarish Malpani wrote:
>
> Compromise of a VA's key is *not* the same as compromise of the
> CA's key, in that the VA can't get you to trust new entities.
> However, if the VA's key is compromised, you might end up trusting
> certs previously revoked by one of the CAs.





Then Santosh Chokhani wrote:
>
> I agree with you that even if the VA compromise is not reported, exposure


> is less since you do not use VA to verify signatures on the certificates.





By "VA" I take it you both mean a status-serving, OCSP-type server.





If, however, you're talking about something that does delegated path
validation (DPV), then I disagree with you both.  A compromised DPV server
can lead you to accept anything that it wants you to accept.





                     Marc










------_=_NextPart_001_01C103C0.7532EB40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<P><FONT SIZE=3D2>Tom:</FONT>
</P>

<P><FONT SIZE=3D2>An unscheduled CRL can be hidden from RP even if the =
repository is trusted.&nbsp; One can attack the network by suppressing =
the unscheduled CRL and replaying the routine one.&nbsp; Now, if you =
assume that you are running a trusted network in addition to a trusted =
repository, you already have some of the security services that PKI =
offers and in that case PKI may be an overkill.</FONT></P>

<P><FONT SIZE=3D2>These issues have been dealt with in 1988 time frame =
when distributed authentication framework for PKI was developed.&nbsp; =
We can have a discussion on this one on one, but I think others on the =
list may find it not worthwhile.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Tom Gindin [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Monday, July 02, 2001 7:57 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: Marc Branchaud; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: caCompromise</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; I am certainly not =
questioning primary reliance on the key for</FONT>
<BR><FONT SIZE=3D2>security in a distributed PKI, but I am questioning =
EXCLUSIVE reliance on</FONT>
<BR><FONT SIZE=3D2>it.&nbsp; In contradiction to one of your points, an =
unscheduled CRL can be</FONT>
<BR><FONT SIZE=3D2>hidden from RP's (or from those OCSP servers which =
are fed by CRL's) by an</FONT>
<BR><FONT SIZE=3D2>attack on the revocation repository, even without a =
key compromise, and the</FONT>
<BR><FONT SIZE=3D2>result of that is more severe than just a denial of =
service.&nbsp; My own view</FONT>
<BR><FONT SIZE=3D2>is that a repository is better than nothing as a =
fallback for detecting a</FONT>
<BR><FONT SIZE=3D2>key compromise, as well.</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom =
Gindin</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Santosh Chokhani &lt;[e-mail]&gt; on =
07/02/2001 08:39:31 AM</FONT>
</P>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; Tom Gindin =
&lt;[e-mail]&gt;, Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp; Marc Branchaud =
&lt;[e-mail]&gt;, [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; RE: caCompromise</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Tom:</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I suspected that is what you were driving at.&nbsp; =
However, in distributed</FONT>
<BR><FONT SIZE=3D2>authentication framework of PKI, we do not depend on =
the security of the</FONT>
<BR><FONT SIZE=3D2>repository or the network.&nbsp; Thus, the CA =
private keys are all that need to</FONT>
<BR><FONT SIZE=3D2>be secured.&nbsp; If the some one breaks those keys, =
we assume there is a</FONT>
<BR><FONT SIZE=3D2>potential for compromise.&nbsp; Absent, that all an =
adversary can cause is</FONT>
<BR><FONT SIZE=3D2>denial of service.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Tom Gindin [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Sunday, July 01, 2001 11:31 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: Marc Branchaud; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: caCompromise</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; If the publication site is =
known to the RP independently, someone</FONT>
<BR><FONT SIZE=3D2>compromising a CA key needs to also take control of =
that site (or spoof the</FONT>
</P>

<P><FONT SIZE=3D2>paths to it) in order to effectively fool RP's into =
accepting certificates</FONT>
<BR><FONT SIZE=3D2>issued by the compromiser.&nbsp;&nbsp;&nbsp; Some of =
the improvements in flexibility in</FONT>
<BR><FONT SIZE=3D2>specifying publication sites in a certificate =
(notably AIA's and CRL DP's)</FONT>
<BR><FONT SIZE=3D2>allow an attacker to specify that revocation =
information will be published</FONT>
<BR><FONT SIZE=3D2>at sites under his own control for certificates =
which he himself generates,</FONT>
</P>

<P><FONT SIZE=3D2>thus rendering a CA compromise even more catastrophic =
than it would</FONT>
<BR><FONT SIZE=3D2>otherwise be.&nbsp; This is similar to what Ambarish =
pointed out, I think.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; This effect can be lessened =
if the definition of a trust anchor</FONT>
<BR><FONT SIZE=3D2>constrains the location of the revocation =
information sufficiently that an</FONT>
<BR><FONT SIZE=3D2>attacker cannot do this, although CRL's without =
distribution points are</FONT>
<BR><FONT SIZE=3D2>sufficiently constrained themselves.&nbsp; This =
thread has been dealing with the</FONT>
</P>

<P><FONT SIZE=3D2>consequences of CA Compromise and means of ensuring =
that RP's are notified</FONT>
<BR><FONT SIZE=3D2>of that condition.</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom =
Gindin</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Santosh Chokhani &lt;[e-mail]&gt; on =
06/30/2001 12:22:15 PM</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; Tom Gindin/Watson/IBM@IBMUS, Marc =
Branchaud</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; RE: caCompromise</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Tom:</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>I do not understand much of what you are =
saying.&nbsp; It seems that you are</FONT>
<BR><FONT SIZE=3D2>pointing to a class of problems which do not exist =
in terms of CRL DP</FONT>
<BR><FONT SIZE=3D2>spoofing.&nbsp; Can you clarify what you are =
saying?&nbsp; Thanks in advance....</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Tom Gindin [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Friday, June 29, 2001 7:33 PM</FONT>
<BR><FONT SIZE=3D2>To: Marc Branchaud</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: caCompromise</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; One question which this =
discussion brings up is whether the principle</FONT>
<BR><FONT SIZE=3D2>&quot;Security resides solely in the key&quot; =
really applies to trust anchors, or</FONT>
<BR><FONT SIZE=3D2>whether a trust anchor is more appropriately =
expressed as the product of a</FONT>
<BR><FONT SIZE=3D2>public key and a communications path (for CA's, some =
of the constraint</FONT>
<BR><FONT SIZE=3D2>extensions are also potentially appropriate).&nbsp; =
Ambarish's earlier point</FONT>
<BR><FONT SIZE=3D2>about an attacker avoiding the detection of a =
compromise via OCSP by</FONT>
<BR><FONT SIZE=3D2>issuing a certificate with an AIA pointing to a =
compromised system suggests</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>this direction, and the same thing can be done to a =
CRL user by abusing</FONT>
<BR><FONT SIZE=3D2>named distribution points.&nbsp; The original use of =
CRL's implied a fixed</FONT>
<BR><FONT SIZE=3D2>directory name as a point of distribution instead - =
which happened to stop</FONT>
<BR><FONT SIZE=3D2>this particular class of attack.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; After all, compromising a =
key does not always imply compromising the</FONT>
<BR><FONT SIZE=3D2>physical server where it is used, although it often =
can.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom =
Gindin</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Marc Branchaud =
&lt;[e-mail]&gt;@mail.imc.org on 06/27/2001</FONT>
<BR><FONT SIZE=3D2>07:41:17 PM</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Sent by:&nbsp; [e-mail]</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>cc:</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; Re: caCompromise</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Ambarish Malpani wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Compromise of a VA's key is *not* the same as =
compromise of the</FONT>
<BR><FONT SIZE=3D2>&gt; CA's key, in that the VA can't get you to trust =
new entities.</FONT>
<BR><FONT SIZE=3D2>&gt; However, if the VA's key is compromised, you =
might end up trusting</FONT>
<BR><FONT SIZE=3D2>&gt; certs previously revoked by one of the =
CAs.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Then Santosh Chokhani wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I agree with you that even if the VA compromise =
is not reported, exposure</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; is less since you do not use VA to verify =
signatures on the certificates.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>By &quot;VA&quot; I take it you both mean a =
status-serving, OCSP-type server.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>If, however, you're talking about something that does =
delegated path</FONT>
<BR><FONT SIZE=3D2>validation (DPV), then I disagree with you =
both.&nbsp; A compromised DPV server</FONT>
<BR><FONT SIZE=3D2>can lead you to accept anything that it wants you to =
accept.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Marc</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C103C0.7532EB40--


Received: by above.proper.com (8.11.3/8.11.3) id f63AxTs09269 for ietf-pkix-bks; Tue, 3 Jul 2001 03:59:29 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63AxSm09265 for <[e-mail]>; Tue, 3 Jul 2001 03:59:28 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24709; Tue, 3 Jul 2001 06:58:45 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-08.txt
Date: Tue, 03 Jul 2001 06:58:44 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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 Certificate 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-08.txt
	Pages		: 128
	Date		: 02-Jul-01
	
This is the eighth draft of a specification based upon RFC 2459.
When complete, this specification will obsolete RFC 2459.
Please send comments on this document to the [e-mail] mail
list.
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
in the Internet.

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f632dhT25812 for ietf-pkix-bks; Mon, 2 Jul 2001 19:39:43 -0700 (PDT)
Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f632dgm25808 for <[e-mail]>; Mon, 2 Jul 2001 19:39:42 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id WAA487552; Mon, 2 Jul 2001 22:37:47 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f632XZD195646; Mon, 2 Jul 2001 22:33:35 -0400
Importance: Normal
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt
To: Denis Pinkas <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, [e-mail], Tim Polk <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 2 Jul 2001 20:28:55 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.7a SPR #MIAS4UTJ8H, S/390 SPR #JHEG4V8UT5 & S/390 SPR #JHEG4WERGL |May 21, 2001) at 07/02/2001 10:39:38 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

     Your first case is indeed certainly a security concern, but I'm not
sure the second one is easily distinguishable from an LDAP problem - what
attacker is suppressing the extra CRL's?  I am skeptical, as you may have
seen from my discussion with Santosh, that X.509 does NOT rely on the
security of the repositories or of their administrators.  This statement is
true only insofar as the RP is expected to verify the signature of CRL's or
certificates retrieved from the repositories so that data which was never
valid cannot be imposed on the RP.  It does not really apply to the
suppression of unscheduled CRL's (including most deltas, I think) - since
an RP will not know that the unscheduled CRL is missing and will wrongly
assume that the base CRL (or the earlier CRL if deltas are not used) is the
current intended set of revocation information.
     To rephrase my earlier statement to Santosh, while the primary
reliance in a distributed PKI is on the key, I do not believe that this
reliance should be exclusive.  This statement is not purely philosophical,
as it can have direct impact on the set of inputs needed to represent a
trust anchor, for example.

          Tom Gindin


Denis Pinkas <[e-mail]> on 07/02/2001 05:07:18 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   "Housley, Russ" <[e-mail]>, [e-mail], Tim
      Polk <[e-mail]>
Subject:  Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt


Tom,

(snip)

> I have some problems with this text, first with "most current" and then
> with the two last MUST. I propose the following fix:

>  An application that supports delta CRLs MAY be able to construct a
>  complete CRL for a reference time T prior to the current time by
combining
>  a complete CRL issued no later than T and a delta CRL valid as of T.
>  A delta CRL is considered to be valid at a given time T if T is
>  between the times contained in the thisUpdate and nextUpdate fields.
>  If more than one current delta CRL for a given scope as of T is
>  encountered, the application SHOULD consider the one with the latest
value
>  in thisUpdate to be the most current one; while if only one current
delta
>  CRL for a given scope as of T is encountered, the application SHOULD
>  consider it to be the most current one. Note that if two delta CRLs,
valid
>  at time T, are placed in a repository, unless additional security
measures
>  are taken, there is no guarantee that both will necessarilly be seen.

 [Tom] I'll leave SHOULD vs. MUST for Russ, although I don't understand
what
 would lead a retrospective verifier to use the second or third most
current
 delta CRL rather than the most current, if he recognizes them as such.
 Your last sentence is helpful, although I don't think that the measures
 which guarantee both deltas being seen are security measures.  The most
 common reason to only see one would be an LDAP client implementation which
 only picked up one value of a multi-valued attribute.

The most common reason to only see one CRL has nothing to do with LDAP.
The reasons are among the following:

  a) the administrator of one of the repositories where the CRLs are
    replicated has purposely suppressed some CRLs. This is a suppression
    while in storage.

  b) during the replication process some CRLs have been removed. This is
     a suppression while in transit.

X509 does NOT rely on the security of the repositories (called Directories)
or of their administrators.


Denis

(snip)






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f632deW25807 for ietf-pkix-bks; Mon, 2 Jul 2001 19:39:40 -0700 (PDT)
Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f632dcm25803 for <[e-mail]>; Mon, 2 Jul 2001 19:39:38 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id WAA335686; Mon, 2 Jul 2001 22:37:44 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f632XVD159102; Mon, 2 Jul 2001 22:33:31 -0400
Importance: Normal
Subject: RE: caCompromise
To: Santosh Chokhani <[e-mail]>
Cc: Marc Branchaud <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 2 Jul 2001 19:57:10 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.7a SPR #MIAS4UTJ8H, S/390 SPR #JHEG4V8UT5 & S/390 SPR #JHEG4WERGL |May 21, 2001) at 07/02/2001 10:39:35 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

     I am certainly not questioning primary reliance on the key for
security in a distributed PKI, but I am questioning EXCLUSIVE reliance on
it.  In contradiction to one of your points, an unscheduled CRL can be
hidden from RP's (or from those OCSP servers which are fed by CRL's) by an
attack on the revocation repository, even without a key compromise, and the
result of that is more severe than just a denial of service.  My own view
is that a repository is better than nothing as a fallback for detecting a
key compromise, as well.

          Tom Gindin



Santosh Chokhani <[e-mail]> on 07/02/2001 08:39:31 AM

To:   Tom Gindin <[e-mail]>, Santosh Chokhani
      <[e-mail]>
cc:   Marc Branchaud <[e-mail]>, [e-mail]
Subject:  RE: caCompromise


Tom:


I suspected that is what you were driving at.  However, in distributed
authentication framework of PKI, we do not depend on the security of the
repository or the network.  Thus, the CA private keys are all that need to
be secured.  If the some one breaks those keys, we assume there is a
potential for compromise.  Absent, that all an adversary can cause is
denial of service.


-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Sunday, July 01, 2001 11:31 PM
To: Santosh Chokhani
Cc: Marc Branchaud; [e-mail]
Subject: RE: caCompromise






     If the publication site is known to the RP independently, someone
compromising a CA key needs to also take control of that site (or spoof the

paths to it) in order to effectively fool RP's into accepting certificates
issued by the compromiser.    Some of the improvements in flexibility in
specifying publication sites in a certificate (notably AIA's and CRL DP's)
allow an attacker to specify that revocation information will be published
at sites under his own control for certificates which he himself generates,

thus rendering a CA compromise even more catastrophic than it would
otherwise be.  This is similar to what Ambarish pointed out, I think.
     This effect can be lessened if the definition of a trust anchor
constrains the location of the revocation information sufficiently that an
attacker cannot do this, although CRL's without distribution points are
sufficiently constrained themselves.  This thread has been dealing with the

consequences of CA Compromise and means of ensuring that RP's are notified
of that condition.


          Tom Gindin





Santosh Chokhani <[e-mail]> on 06/30/2001 12:22:15 PM


To:   Tom Gindin/Watson/IBM@IBMUS, Marc Branchaud
      <[e-mail]>
cc:   [e-mail]
Subject:  RE: caCompromise





Tom:





I do not understand much of what you are saying.  It seems that you are
pointing to a class of problems which do not exist in terms of CRL DP
spoofing.  Can you clarify what you are saying?  Thanks in advance....








-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Friday, June 29, 2001 7:33 PM
To: Marc Branchaud
Cc: [e-mail]
Subject: Re: caCompromise










     One question which this discussion brings up is whether the principle
"Security resides solely in the key" really applies to trust anchors, or
whether a trust anchor is more appropriately expressed as the product of a
public key and a communications path (for CA's, some of the constraint
extensions are also potentially appropriate).  Ambarish's earlier point
about an attacker avoiding the detection of a compromise via OCSP by
issuing a certificate with an AIA pointing to a compromised system suggests


this direction, and the same thing can be done to a CRL user by abusing
named distribution points.  The original use of CRL's implied a fixed
directory name as a point of distribution instead - which happened to stop
this particular class of attack.
     After all, compromising a key does not always imply compromising the
physical server where it is used, although it often can.





          Tom Gindin








Marc Branchaud <[e-mail]>@mail.imc.org on 06/27/2001
07:41:17 PM





Sent by:  [e-mail]








To:   [e-mail]
cc:
Subject:  Re: caCompromise










Ambarish Malpani wrote:
>
> Compromise of a VA's key is *not* the same as compromise of the
> CA's key, in that the VA can't get you to trust new entities.
> However, if the VA's key is compromised, you might end up trusting
> certs previously revoked by one of the CAs.





Then Santosh Chokhani wrote:
>
> I agree with you that even if the VA compromise is not reported, exposure


> is less since you do not use VA to verify signatures on the certificates.





By "VA" I take it you both mean a status-serving, OCSP-type server.





If, however, you're talking about something that does delegated path
validation (DPV), then I disagree with you both.  A compromised DPV server
can lead you to accept anything that it wants you to accept.





                     Marc












Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62LLIq18612 for ietf-pkix-bks; Mon, 2 Jul 2001 14:21:18 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62LLHm18606 for <[e-mail]>; Mon, 2 Jul 2001 14:21:17 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 02 Jul 2001 17:17:21 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Should a CRL number be unique or not ?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Trevor Freeman wrote:
> 
> Sorry to be a heretic, but why do we need a CRL number in the delta CRL?
> The "This Update" time seems far less ambiguous as a mechanism for
> determining succession of delta CRLs - without resorting so linguistic
> gymnastics. Having determined the delta CRL is of the same scope which
> the CRL numner plays no pary, a simple comparison of the This update
> time tells me which came last. Just keep the CRL number in the base
> since you need that for the delta CRL indecator extension.


Trevor,

That would be correct if a delta (call it "delta B") were
applied only to a complete CRL downloaded by the application.

But it is possible to save bandwidth by locally constructing the base
CRL instead of downloading a complete CRL.  Since the constructed base
needs a CRL number, the delta ("delta A") used to construct it must have
a CRL number.

   Complete CRL: ->  Delta A:
    CRL# = 1          baseCRL# = 1
                      CRL# = 2

                       |
                       V

                     locally-constructed   ->  Delta B:
                     complete CRL:              baseCRL# = 2
                      CRL# = 2

An application that supports delta CRLs is not required to support local
construction.  But an application that performs local construction
requires the CRL number extension to be present in delta CRLs - the
application cannot function without that extension regardless of
whether constructed CRLs are "numbered".

Denis argues that although the constructed CRL is built from Delta A
and Delta A must have a CRL number, the constructed CRL need not be
assigned a number.  That line of reasoning strikes me as pure sophistry.
But regardless of its merits, the identical argument can be made against
propogating thisUpdate and nextUpdate from Delta A to the constructed CRL.
Not propogating CRL number does not make the algorithm any more general,
it merely forces the algorithm description to be more verbose.


Denis says:
> This would lead to option D:
> 
>    The CRL number is a non-critical CRL extension which conveys a
>    unique number for a given CRL scope and CRL issuer. CRL issuers 
>    conforming to this profile MUST include this extension in all CRLs.
> 
> Only for reasons of backward compatibility, I will not push this proposal,
> but we have to understand that CRL numbers have an unneeded and overloaded
> semantics. So why we should make clear that local CRL numbers are no more
> than ONE way to implement an algorithm that could also be implemented using
> thisUpdate. Saying that using an algorithm that exhibits the same properties
> would be equally valid is not enough, because the reader will understand
> that the algorithm has to use CRL numbers. It would help to say that an
> algorithm using thisUpdate could also be constructed.

The reader will understand correctly that any algorithm for constructed CRLs
requires delta CRLs to contain the CRL number extension.  An algorithm using
thisUpdate and CRL number is possible; an algorithm using thisUpdate alone is
not.

Moreover, if as in option D CRL numbers are merely unique and not time-ordered,
then an application cannot use a base CRL more recent than that specified in
the deltaCRLIndicator extension.  You were previously happy when Russ
changed "greater than or equal to" to "equal to or greater than". Option D
would force it to be exactly "equal to" and would make thisUpdate
irrelevant when matching a delta to its base.  You can't have it both
ways; either you want a construction algorithm which permits the use of
thisUpdate, or you want CRL numbers to be unique but unordered thereby
excluding the use of thisUpdate.

If a new delta CRL extension were defined which contained a "baseThisUpdate"
time,
then an alternate algorithm which does not use CRL numbers would be possible.
But PKIX requires delta CRLs to contain the deltaCRLIndicator extension and
PKIX does not profile the X.509 crlScope extension, therefore an algorithm
using thisUpdate alone to link a delta to its base cannot be defined within
this edition of Part 1.  Perhaps in grandson-of-2459.

Regards,
Dave


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62Jww511441 for ietf-pkix-bks; Mon, 2 Jul 2001 12:58:58 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62Jwum11434 for <[e-mail]>; Mon, 2 Jul 2001 12:58:57 -0700 (PDT)
Received: from cdc22.cdc.informatik.tu-darmstadt.de (cdc22 [130.83.23.31]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id D973D2C85 for <[e-mail]>; Mon,  2 Jul 2001 21:58:57 +0200 (MET DST)
Received: from cdc.informatik.tu-darmstadt.de by cdc22.cdc.informatik.tu-darmstadt.de (8.8.8+Sun/SMI-SVR4) id VAA20707; Mon, 2 Jul 2001 21:58:56 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 02 Jul 2001 21:58:55 +0200
From: Maud Schneider <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: reply to error message?
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id f62Jwvm11437
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hello!

Should an entity that receives an error message send a reply message?

Thanks Maud


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62Co6P16220 for ietf-pkix-bks; Mon, 2 Jul 2001 05:50:06 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62Co5m16215 for <[e-mail]>; Mon, 2 Jul 2001 05:50:05 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <3D0QZC6W>; Mon, 2 Jul 2001 08:50:01 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Tom Gindin <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: Marc Branchaud <[e-mail]>, [e-mail]
Subject: RE: caCompromise
Date: Mon, 2 Jul 2001 08:39:31 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C102F4.0A84DDC0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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

------_=_NextPart_001_01C102F4.0A84DDC0
Content-Type: text/plain;
	charset="iso-8859-1"

Tom:

I suspected that is what you were driving at.  However, in distributed
authentication framework of PKI, we do not depend on the security of the
repository or the network.  Thus, the CA private keys are all that need to
be secured.  If the some one breaks those keys, we assume there is a
potential for compromise.  Absent, that all an adversary can cause is denial
of service.

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Sunday, July 01, 2001 11:31 PM
To: Santosh Chokhani
Cc: Marc Branchaud; [e-mail]
Subject: RE: caCompromise



     If the publication site is known to the RP independently, someone
compromising a CA key needs to also take control of that site (or spoof the
paths to it) in order to effectively fool RP's into accepting certificates
issued by the compromiser.    Some of the improvements in flexibility in
specifying publication sites in a certificate (notably AIA's and CRL DP's)
allow an attacker to specify that revocation information will be published
at sites under his own control for certificates which he himself generates,
thus rendering a CA compromise even more catastrophic than it would
otherwise be.  This is similar to what Ambarish pointed out, I think.
     This effect can be lessened if the definition of a trust anchor
constrains the location of the revocation information sufficiently that an
attacker cannot do this, although CRL's without distribution points are
sufficiently constrained themselves.  This thread has been dealing with the
consequences of CA Compromise and means of ensuring that RP's are notified
of that condition.

          Tom Gindin


Santosh Chokhani <[e-mail]> on 06/30/2001 12:22:15 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Marc Branchaud
      <[e-mail]>
cc:   [e-mail]
Subject:  RE: caCompromise


Tom:


I do not understand much of what you are saying.  It seems that you are
pointing to a class of problems which do not exist in terms of CRL DP
spoofing.  Can you clarify what you are saying?  Thanks in advance....





-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Friday, June 29, 2001 7:33 PM
To: Marc Branchaud
Cc: [e-mail]
Subject: Re: caCompromise







     One question which this discussion brings up is whether the principle
"Security resides solely in the key" really applies to trust anchors, or
whether a trust anchor is more appropriately expressed as the product of a
public key and a communications path (for CA's, some of the constraint
extensions are also potentially appropriate).  Ambarish's earlier point
about an attacker avoiding the detection of a compromise via OCSP by
issuing a certificate with an AIA pointing to a compromised system suggests

this direction, and the same thing can be done to a CRL user by abusing
named distribution points.  The original use of CRL's implied a fixed
directory name as a point of distribution instead - which happened to stop
this particular class of attack.
     After all, compromising a key does not always imply compromising the
physical server where it is used, although it often can.


          Tom Gindin





Marc Branchaud <[e-mail]>@mail.imc.org on 06/27/2001
07:41:17 PM


Sent by:  [e-mail]





To:   [e-mail]
cc:
Subject:  Re: caCompromise







Ambarish Malpani wrote:
>
> Compromise of a VA's key is *not* the same as compromise of the
> CA's key, in that the VA can't get you to trust new entities.
> However, if the VA's key is compromised, you might end up trusting
> certs previously revoked by one of the CAs.


Then Santosh Chokhani wrote:
>
> I agree with you that even if the VA compromise is not reported, exposure

> is less since you do not use VA to verify signatures on the certificates.


By "VA" I take it you both mean a status-serving, OCSP-type server.


If, however, you're talking about something that does delegated path
validation (DPV), then I disagree with you both.  A compromised DPV server
can lead you to accept anything that it wants you to accept.


                     Marc







------_=_NextPart_001_01C102F4.0A84DDC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<P><FONT SIZE=3D2>Tom:</FONT>
</P>

<P><FONT SIZE=3D2>I suspected that is what you were driving at.&nbsp; =
However, in distributed authentication framework of PKI, we do not =
depend on the security of the repository or the network.&nbsp; Thus, =
the CA private keys are all that need to be secured.&nbsp; If the some =
one breaks those keys, we assume there is a potential for =
compromise.&nbsp; Absent, that all an adversary can cause is denial of =
service.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Tom Gindin [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Sunday, July 01, 2001 11:31 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: Marc Branchaud; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: caCompromise</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; If the publication site is =
known to the RP independently, someone</FONT>
<BR><FONT SIZE=3D2>compromising a CA key needs to also take control of =
that site (or spoof the</FONT>
<BR><FONT SIZE=3D2>paths to it) in order to effectively fool RP's into =
accepting certificates</FONT>
<BR><FONT SIZE=3D2>issued by the compromiser.&nbsp;&nbsp;&nbsp; Some of =
the improvements in flexibility in</FONT>
<BR><FONT SIZE=3D2>specifying publication sites in a certificate =
(notably AIA's and CRL DP's)</FONT>
<BR><FONT SIZE=3D2>allow an attacker to specify that revocation =
information will be published</FONT>
<BR><FONT SIZE=3D2>at sites under his own control for certificates =
which he himself generates,</FONT>
<BR><FONT SIZE=3D2>thus rendering a CA compromise even more =
catastrophic than it would</FONT>
<BR><FONT SIZE=3D2>otherwise be.&nbsp; This is similar to what Ambarish =
pointed out, I think.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; This effect can be lessened =
if the definition of a trust anchor</FONT>
<BR><FONT SIZE=3D2>constrains the location of the revocation =
information sufficiently that an</FONT>
<BR><FONT SIZE=3D2>attacker cannot do this, although CRL's without =
distribution points are</FONT>
<BR><FONT SIZE=3D2>sufficiently constrained themselves.&nbsp; This =
thread has been dealing with the</FONT>
<BR><FONT SIZE=3D2>consequences of CA Compromise and means of ensuring =
that RP's are notified</FONT>
<BR><FONT SIZE=3D2>of that condition.</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom =
Gindin</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Santosh Chokhani &lt;[e-mail]&gt; on =
06/30/2001 12:22:15 PM</FONT>
</P>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; Tom Gindin/Watson/IBM@IBMUS, Marc =
Branchaud</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; RE: caCompromise</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Tom:</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I do not understand much of what you are =
saying.&nbsp; It seems that you are</FONT>
<BR><FONT SIZE=3D2>pointing to a class of problems which do not exist =
in terms of CRL DP</FONT>
<BR><FONT SIZE=3D2>spoofing.&nbsp; Can you clarify what you are =
saying?&nbsp; Thanks in advance....</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Tom Gindin [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Friday, June 29, 2001 7:33 PM</FONT>
<BR><FONT SIZE=3D2>To: Marc Branchaud</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: caCompromise</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; One question which this =
discussion brings up is whether the principle</FONT>
<BR><FONT SIZE=3D2>&quot;Security resides solely in the key&quot; =
really applies to trust anchors, or</FONT>
<BR><FONT SIZE=3D2>whether a trust anchor is more appropriately =
expressed as the product of a</FONT>
<BR><FONT SIZE=3D2>public key and a communications path (for CA's, some =
of the constraint</FONT>
<BR><FONT SIZE=3D2>extensions are also potentially appropriate).&nbsp; =
Ambarish's earlier point</FONT>
<BR><FONT SIZE=3D2>about an attacker avoiding the detection of a =
compromise via OCSP by</FONT>
<BR><FONT SIZE=3D2>issuing a certificate with an AIA pointing to a =
compromised system suggests</FONT>
</P>

<P><FONT SIZE=3D2>this direction, and the same thing can be done to a =
CRL user by abusing</FONT>
<BR><FONT SIZE=3D2>named distribution points.&nbsp; The original use of =
CRL's implied a fixed</FONT>
<BR><FONT SIZE=3D2>directory name as a point of distribution instead - =
which happened to stop</FONT>
<BR><FONT SIZE=3D2>this particular class of attack.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; After all, compromising a =
key does not always imply compromising the</FONT>
<BR><FONT SIZE=3D2>physical server where it is used, although it often =
can.</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom =
Gindin</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Marc Branchaud =
&lt;[e-mail]&gt;@mail.imc.org on 06/27/2001</FONT>
<BR><FONT SIZE=3D2>07:41:17 PM</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Sent by:&nbsp; [e-mail]</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>cc:</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; Re: caCompromise</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Ambarish Malpani wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Compromise of a VA's key is *not* the same as =
compromise of the</FONT>
<BR><FONT SIZE=3D2>&gt; CA's key, in that the VA can't get you to trust =
new entities.</FONT>
<BR><FONT SIZE=3D2>&gt; However, if the VA's key is compromised, you =
might end up trusting</FONT>
<BR><FONT SIZE=3D2>&gt; certs previously revoked by one of the =
CAs.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Then Santosh Chokhani wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I agree with you that even if the VA compromise =
is not reported, exposure</FONT>
</P>

<P><FONT SIZE=3D2>&gt; is less since you do not use VA to verify =
signatures on the certificates.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>By &quot;VA&quot; I take it you both mean a =
status-serving, OCSP-type server.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>If, however, you're talking about something that does =
delegated path</FONT>
<BR><FONT SIZE=3D2>validation (DPV), then I disagree with you =
both.&nbsp; A compromised DPV server</FONT>
<BR><FONT SIZE=3D2>can lead you to accept anything that it wants you to =
accept.</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Marc</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C102F4.0A84DDC0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f629A5Z09873 for ietf-pkix-bks; Mon, 2 Jul 2001 02:10:05 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f629A2m09865 for <[e-mail]>; Mon, 2 Jul 2001 02:10:02 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA32292; Mon, 2 Jul 2001 11:10:50 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA19634; Mon, 2 Jul 2001 11:09:23 +0200
Message-ID: <[e-mail]>
Date: Mon, 02 Jul 2001 11:09:21 +0200
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail], Tim Polk <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ,

> Denis:
> 
> I have discussed my response with Tim Polk.  While he has not reviewed the
> text of this message, he did agree with my verbal outline of this message.
> 
> I believe that your note is about two issues.  The first issue is the a
> requirement that a locally constructed CRL be assigned a specific CRL
> number.  The second issue is the rules for combining a delta CRL and a
> complete CRL.  These two are interwoven, and they cannot be addresses
> separately.
> 
> We want there to me a single mechanism for determining whether or not a
> delta CRL can be combined with a given complete CRL.  In order for these
> rules to be the same for complete CRLs issued by CRL issuers and for
> locally constructed complete CRLs, then applications must know what CRL
> number to associate with locally constructed complete CRLs.  This is the
> reason that we have a MUST statement regarding these numbers.

On page 56 of draft-ietf-pkix-new-part1-07.txt, the text uses MAY: 

   A complete CRL and a delta CRL MAY be combined if the following four
   conditions are satisfied:

I have also used MAY to be as close as possible with that text.
If you refer to a different statement, please clarify.
 
> Your proposal includes two separate rule sets, one to determine if it is
> appropriate to combine a delta CRL with a complete CRLs issued by the CRL
> issuer, and one to determine if it is appropriate to combine a delta CRL
> with a locally constructed complete CRL.  This complexity is avoided by
> telling applications how to number a locally constructed complete CRL.  In
> this way, one rule does the job for both situations.

I do not believe that two lines of text add complexity. These two lines are:

  (d)  The local CRL number of the locally constructed CRL is equal
       to or greater than the BaseCRLNumber specified in the delta CRL.

Local CRL numbers are purely artificial and even Trevor Freeman is quite
validly questioning the real interest to have a CRL number for a delta-CRL.
As he said, thisUpdate is quite sufficient. A different algorithm could be
constructed by locally remembering the "thisUpdate" from the CRLs and the
delta.

In this way we could even have a CRL number that is purely unique (as the
certificate number is), without having any monotonocally increasing or
strictly increasing property.

This would lead to option D:

   The CRL number is a non-critical CRL extension which conveys a
   unique number for a given CRL scope and CRL issuer. CRL issuers 
   conforming to this profile MUST include this extension in all CRLs.

Only for reasons of backward compatibility, I will not push this proposal,
but we have to understand that CRL numbers have an unneeded and overloaded
semantics. So why we should make clear that local CRL numbers are no more
than ONE way to implement an algorithm that could also be implemented using
thisUpdate. Saying that using an algorithm that exhibits the same properties
would be equally valid is not enough, because the reader will understand
that the algorithm has to use CRL numbers. It would help to say that an
algorithm using thisUpdate could also be constructed.

> Tim working on an update to Appendix C.  Once he completes this update, he
> will post an updated Internet-Draft.  

Before he does this, I would really appreciate that he sends to the list a
revised text for sections 5.2.3 and 5.2.4 taking into account what has been
posted on this thread.

> We hope that we have captured
> consensus of the working group with our words.  We hope that everyone can
> live with the content of the updated document, even if they are not
> completely happy with every sentence.  (Standards occur when everyone is
> equally unhappy, not when everyone is equally happy.)

Now, let me say once again a point: the issue of identical CRL numbers
could also be nicely solved by not allowing to issue a base CRL and a delta
CRL exactly at the *very same* second. 

This is option C, and not option B, as I wrongly mentioned in my last
e-mail.

Denis

> Russ
> 
> At 06:27 PM 6/29/2001 +0200, Denis Pinkas wrote:
> 
> >Tom and Russ,
> >
> > >      I don't know if this will be considered helpful or not.
> >
> >Yes, it is helpful and thank you for your explanations. This allows me to
> >respond to the second part of the e-mail from Russ as well.
> >
> >We all agree that the construction of a CRL using a delta CRL in the past is
> >only an option and thus the text has to use MAY and not MUST.
> >
> >Having said that, when the application wants to do such a construction in
> >the past, we should give some guidance, and this is what you have done
> >below, using a MAY.
> >
> > > While
> > > retrospective verification is certainly not a mandatory feature of RP
> > > software, there is a method for retrospective validation which is
> > > compatible with the proposed wording in part1.  (Please note that there's a
> > > typo in that paragraph: 'compete' should be 'complete').  In the proposed
> > > paragraph below, the terms 'current' and 'most current' are given meanings
> > > fully compatible with those in the proposed paragraph in part1 - a
> > > 'current' delta CRL in the sense of that proposal is a 'current' one as of
> > > the present time in the sense of this.  I have not included the internal
> > > CRL possibility for retrospective validation, as it seems pointless in such
> > > a case.
> >
> > > An application that supports delta CRLs MAY be able to construct a complete
> > > CRL for a reference time T prior to the current time by combining a
> > > complete CRL issued no later than T and the most current delta CRL as of T.
> > > A delta CRL is considered to be a current one as of a given time T if T is
> > > between the times contained in the thisUpdate and nextUpdate fields. If
> > > more than one current delta CRL for a given scope as of T is encountered,
> > > the application MUST consider the one with the latest value in thisUpdate
> > > to be the most current one; while if only one current delta CRL for a given
> > > scope as of T is encountered, the application MUST consider it to be the
> > > most current one.
> >
> >I have some problems with this text, first with "most current" and then with
> >the two last MUST. I propose the following fix:
> >
> >  An application that supports delta CRLs MAY be able to construct a complete
> >  CRL for a reference time T prior to the current time by combining a
> >  complete CRL issued no later than T and a delta CRL valid as of T.
> >  A delta CRL is considered to be valid at a given time T if T is
> >  between the times contained in the thisUpdate and nextUpdate fields.
> >  If more than one current delta CRL for a given scope as of T is
> >  encountered, the application SHOULD consider the one with the latest value
> >  in thisUpdate to be the most current one; while if only one current delta
> >  CRL for a given scope as of T is encountered, the application SHOULD
> >  consider it to be the most current one. Note that if two delta CRLs, valid
> >  at time T, are placed in a repository, unless additional security measures
> >  are taken, there is no guarantee that both will necessarilly be seen.
> >
> >Note that in order to close this issue, we still need to agree on the
> >set of conditions to use the full CRL or the locally constructed
> >CRL to be used with the delta CRL.
> >
> >Russ said: "Denis, I think you missed my point.  And, maybe I am missing
> >yours too." I think we can both agree on this statement. :-)
> >
> >So using the text from draft-ietf-pkix-new-part1-07.txt I have tried to show
> >which wording could be used:
> >
> >Making a small fix to section 5.2.4, we could say:
> >
> >    When a delta CRL is combined with a complete CRL or a locally
> >    constructed CRL, the resulting locally constructed CRL is equivalent
> >    to a full CRL which would have a local CRL number equal to the CRL
> >    number specified in the CRL number extension found in the delta CRL
> >    used in its construction. In addition, the resulting locally constructed
> >    CRL has the thisUpdate and nextUpdate times specified in the
> >    corresponding fields of the delta CRL used in its construction.
> >    In addition, the locally constructed CRL inherits the issuing
> >    distribution point from the delta CRL.
> >
> >This means that we could solve the issue by saying:
> >
> >A complete CRL or a locally constructed CRL and a delta CRL MAY be combined
> >if:
> >
> >       (a)  The complete or locally constructed CRL and delta CRL have the
> >            same issuer.
> >
> >       (b)  The complete or locally constructed CRL and delta CRL have the
> >            same scope.  The two CRLs have the same scope if either of the
> >            following conditions are met:
> >
> >          (1)  The issuingDistributionPoint extension is omitted from
> >               both CRLs.
> >
> >          (2)  The issuingDistributionPoint extension is present in both
> >               CRLs, and the values for each of the fields in the
> >               extensions are the same in both CRLs.
> >
> >       (c)  The CRL number of the complete CRL is equal to or greater
> >            than the BaseCRLNumber specified in the delta CRL; or
> >
> >       (d)  The local CRL number of the locally constructed CRL is equal
> >            to or greater than the BaseCRLNumber specified in the delta CRL.
> >
> >
> >One sentence should be moved from 5.2.3 to 5.2.4, since this is specific
> >with deltas, i.e:
> >
> >    If a CRL issuer generates delta CRLs in addition to complete CRLs for
> >    a given scope, the complete CRLs and delta CRLs MUST share one
> >    numbering sequence.
> >
> >... while the issue of identical CRL numbers could also be nicely solved but
> >not allowing to issue a base CRL and a delta CRL exactly at the very same
> >second. This is, if I remember correctly, one option with which Tim Polk
> >could live with. This is implied by option B.
> >
> >Denis
> >
> >
> >Annex for Russ only: Hereunder some text that I have been using before
> >making the above proposal. This shows that we do not need to use a local CRL
> >numbering. I also believe that clause (f) is clearer than the current text,
> >but in order to try to close the discussion, I have as close as possible to
> >the text from draft 07.
> >
> >A complete CRL or a locally constructed CRL and a delta CRL MAY be combined
> >if, first, the following two conditions are satisfied:
> >
> >       (a)  The complete or locally constructed CRL and delta CRL have the
> >            same issuer.
> >
> >       (b)  The complete or locally constructed CRL and delta CRL have the
> >            same scope.  The two CRLs have the same scope if either of the
> >            following conditions are met:
> >
> >          (1)  The issuingDistributionPoint extension is omitted from
> >               both the complete CRL and the delta CRL.
> >
> >          (2)  The issuingDistributionPoint extension is present in both
> >               the complete CRL and the delta CRL, and the values for each
> >               of the fields in the extensions are the same in both CRLs.
> >
> >In addition, a complete CRL and a delta CRL MAY be combined if, the
> >following two other conditions are satisfied:
> >
> >       (c)  The CRL number of the complete CRL is equal to or greater
> >       than the BaseCRLNumber specified in the delta CRL.  That is,
> >       the complete CRL contains (at a minimum) all the revocation
> >       information held by the referenced base CRL.
> >
> >       (d)  The CRL number of the complete CRL is less than the CRL
> >       number of the delta CRL.  That is, the delta CRL follows the
> >       complete CRL in the numbering sequence.
> >
> >       [If we now place the new text to say how to pick the right
> >       delta-CRL, and unless the CA is not conformant with section 5.2.3 !,
> >       the text under (d) is unnecessary, but I left it for the time being]
> >
> >In addition, a locally constructed CRL and a delta CRL MAY be combined if,
> >the locally constructed CRL has been build using a full CRL that has a
> >cRLNumber either:
> >
> >       (e)  equal to or greater than the base CRL number referenced
> >       in the delta CRL; or
> >
> >       (f) lower than the base CRL number referenced in the delta CRL,
> >       provided that the delta CRL that has been used to make the
> >       construction has a CRL number greater than the base CRL number
> >       referenced in the delta CRL.
> >
> >===================================================================
> >
> > >      Please note that I am NOT suggesting any particular handling for
> > > certificateHold or removeFromCRL.
> > >
> > >           Tom Gindin
> > >
> > > "Housley, Russ" <[e-mail]>@mail.imc.org on 06/28/2001
> > > 05:18:33 PM
> > >
> > > Sent by:  [e-mail]
> > >
> > > To:   Denis Pinkas <[e-mail]>
> > > cc:   [e-mail]
> > > Subject:  Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt
> > >
> > > Denis:
> > >
> > > > >> I do think it is a major advantage to be able to use unique numbers so
> > > > that
> > > > >> if I say "CRL 12345", only one CRL can be retrieved for a given CRL
> > > scope
> > > > >> and CRL Issuer. In this way references to CRLs can easily be used and
> > > only
> > > > >> the right CRLs may be stored or fetched in some repositories.
> > > >
> > > > > We have achieved this goal.  CRL 12345 represents a specific set of
> > > revoked
> > > > > certificates.  The relying party might determine the membership of that
> > > > > list in more than one way (complete CRL, delta CRL combined with a
> > > previous
> > > > > complete, or delta CRL combined with a locally constructed complete),
> > > but
> > > > > in each case the membership of the list will be identical.
> > > >
> > > >I do not think so. You are not looking at the problem in the same way. I
> > > >looked at it in terms of objects stored, whatever their content is. If I
> > > ask
> > > >to retrieve CRL 12345 from a repository, with your approach, I could
> > > >retrieve TWO CRLs and not a single one. Thus If I want to make sure that
> > > CRL
> > > >12345 is stored, with your approach, the answer could be yes, but without
> > > >additional information it would be impossible to know whether it is the
> > > full
> > > >CRL or the delta-CRL with the same number.
> > > >
> > > >I do understand that you want this property, but I do insist to say that
> > > >this not necessary. See later for additional explanations.
> > >
> > > This point has already been discussed.  If there are two CRLs with the same
> > > number, then they contain the same list of revoked certificates
> > > (potentially with different nextUpdate information).  This point has been
> > > beat to death, and I do not hear anyone besides you that thinks this is an
> > > issue.
> > >
> > > If others agree with Denis and have kept quiet because they feel that he is
> > > a good spokesman, now is the time to speak up.  To me, and the PKIX WG
> > > chairmen, it seems that Denis is a lone voice on this issue.  If it is not
> > > so, yell now!
> > >
> > > > > > > >    An application that supports delta CRLs MUST be able to
> > > construct
> > > > > > > >    a CRL that is complete for a given scope, at a given time T,
> > > by
> > > > > > > >    retrieving a delta CRL for that scope where the time T is
> > > between
> > > > > > > >    thisUpdate and nextUpdate, and combining it with a CRL that is
> > > > > > > >    complete for that scope and that has a cRLNumber equal or
> > > greater
> > > > > > > >    than to the base CRL number referenced in the current delta
> > > CRL.
> > > > > > >
> > > > > > > I believe that this paragraph says the same thing as:
> > > > > > >
> > > > > > >     An application that supports delta CRLs MUST be able to
> > > construct a
> > > > > > >     current complete CRL by combining a previously issued complete
> > > CRL
> > > > > > >     and the most current delta CRL.
> > > >
> > > >Equivalent, ... except that one sentence is only applicable for the
> > > current
> > > >time t, while the other is applicable at time t and a time T in the past.
> > > >So, this is not equivalent.
> > >
> > > I do not believe that an application that supports delta CRLs MUST be able
> > > to combine historical complete CRLs with historical delta CRLs.  In my
> > > mind, this is clearly optional.
> > >
> > > > > >This is the issue about "most current".
> > > >
> > > >[snip]
> > > >
> > > > > Fine.  I changed it to "... equal to or greater than ..."
> > > >
> > > >Thank you.
> > >
> > > You are welcome.
> > >
> > > > > > >        (d)  The CRL number of the complete CRL is less than the CRL
> > > > > > >        number of the delta CRL.  That is, the delta CRL follows the
> > > > > > >        complete CRL in the numbering sequence.
> > > > > >
> > > > > >This is not wrong, but I am not sure this condition is needed. If you
> > > pick
> > > > > >the "right" delta, then clause (c) is self-sufficient.
> > > > >
> > > > > Tim and I discussed this point.  We recognize that it might be a bit
> > > > > tutorial.  We felt that it might help to avoid errors in
> > > implementations
> > > > > done by people less involved in the PKI standards community than you.
> > > >
> > > >I still think this text is unnecessary.
> > >
> > > Unless you can show that it is incorrect, I suggest that we move on.
> > >
> > > > > > > The second context involves applications.  Here we say: "construct
> > > a
> > > > > > > current complete CRL."  Again, I think that the dictionary
> > > > definition is
> > > > > > > fine.  However, we also say that applications use the "most current
> > > > delta
> > > > > > > CRL."  Perhaps we could help the reader here.  To this end, I
> > > > propose the
> > > > > > > addition of a sentence:
> > > > > >
> > > > > > >     A delta CRL is considered to be the most current one, if and
> > > > only if
> > > > > > >     the current time is between the times contained in the
> > > thisUpdate
> > > > > > >     and nextUpdate fields.
> > > > > >
> > > > > >I believe this is fine for real-time transactions. However, for NR,
> > > > reading
> > > > > >again the arguments raised by Tom Guidin and James Manger, we might
> > > > come to
> > > > > >different conclusions. I prefer to think a little bit more about it.
> > > >
> > > > > In Section 6, we do not offer any details about retrospective
> > > > > algorithms.  Rather, we say that the algorithm can be adjusted by the
> > > > > implementor to handle more than just the current time.  I do not see
> > > any
> > > > > reason to do otherwise in this section.
> > > >
> > > >The current text is as follows:
> > > >
> > > >6.1.1  Inputs
> > > >
> > > >    This algorithm assumes the following seven inputs are provided to the
> > > >    path processing logic:
> > > >
> > > >       (a) a prospective certification path of length n;
> > > >
> > > >       (b) the time, T, for which the validity of the path should be
> > > >       determined.  This may be the current date/time, or some point in
> > > >       the past.
> > > >
> > > > >From that text, it is clear that some point in the past is equally
> > > adressed.
> > > >If this is not the case, then this text is misleading and thus we should
> > > >have something like:
> > > >
> > > >       (b) the time, T, for which the validity of the path should be
> > > >       determined.  This must be the current date/time. The case of
> > > >       some point in the past is not addressed in this section.
> > >
> > > It is my belief that implementations MUST be able to validate certificates
> > > based on the current time, but that support for historic time values is
> > > optional.  Tim and I need to collaborate on some text to make this point
> > > clear.
> > >
> > > > > > > >    It MAY also construct a CRL that is complete for a given
> > > scope,
> > > > > > > >    at a given time T, in either of the two following ways:
> > > > > > > >
> > > > > > > >       (a)  by retrieving a delta CRL for that scope where the
> > > time T
> > > > > > > >       is between thisUpdate and nextUpdate and combining it with
> > > a
> > > > > > > >       locally constructed CRL that has been constructed using a
> > > > > > > >       full CRL that has a cRLNumber equal or greater than the
> > > > > > > >       base CRL number referenced in the current delta CRL; or
> > > > > > >
> > > > > > > I must point out that you use the word current, and the dictionary
> > > > meaning
> > > > > > > is quite sufficient.
> > > > > > >
> > > > > > > This is covered by the following, with the above definition of
> > > > "most current":
> > > > > > >
> > > > > > >     An application that supports delta
> > > > > > >     CRLs MAY also be able to construct a current complete CRL by
> > > > > > >     combining a previously locally constructed compete CRL and the
> > > most
> > > > > > >     current delta CRL.
> > > > > > >
> > > > > > > >       (b)  by retrieving a delta CRL for that scope where the
> > > time T
> > > > > > > >       is between thisUpdate and nextUpdate and combining it with
> > > a
> > > > > > > >       locally constructed CRL that has been constructed using a
> > > > > > > >       full CRL that has a cRLNumber lower than the base CRL
> > > > > > > >       number referenced in the current delta CRL, provided that
> > > > > > > >       the last delta CRL used to construct that local CRL has a
> > > CRL
> > > > > > > >       number greater than the base CRL number referenced in the
> > > > > > > >       current delta CRL.
> > > > > > >
> > > > > > > This is covered by the same sentence.  I do not see any reason to
> > > > separate
> > > > > > > these cases.  We clearly tell the implementor how to number locally
> > > > > > > constructed CRLs:
> > > > > >
> > > > > >Numbering locally CRLs is a local feature that should not be
> > > mentioned. It
> > > > > >is important to say how to use external information. If, it ends up
> > > > that the
> > > > > >local numbering does the same job, that's fine, but it is certainly
> > > > not the
> > > > > >single way to do it. So I would use the equivalence in the reverse
> > > > > >direction: we should define an algorithm that says how to use external
> > > > > >elements independant of any local convention. If it happens that the
> > > > > >algorithm using local numbers provides the same result, that's fine,
> > > but
> > > > > >should not be part of the standard.
> > > >
> > > > > I disagree.  When a delta CRL is used to update a complete CRL (whether
> > > > > that complete CRL was obtained directly from the CRL issuer or it was
> > > > > locally constructed) the resulting CRL number MUST be known for that
> > > > > locally constructed CRL to be further updated by subsequent delta CRLs.
> > > >
> > > >No. Take a look again at the wording I have used, where you can avoid this
> > > >local numbering. Instead of saying the locally constructed CRL has number
> > > X,
> > > >it tells you exactly what king of information shall be maintained whith
> > > each
> > > >locally constructed CRL so that it is possible to make sure whether it
> > > fits
> > > >or not.
> > > >
> > > >"... combining it with a locally constructed CRL that has been constructed
> > > >using a full CRL that has a cRLNumber equal or greater than the
> > > >base CRL number referenced in the current delta CRL; or
> > > >
> > > >... combining it with a locally constructed CRL that has been constructed
> > > >using a full CRL that has a cRLNumber lower than the base CRL number
> > > >referenced in the current delta CRL, provided that the last delta CRL used
> > > >to construct that local CRL has a CRL number greater than the base CRL
> > > >number referenced in the current delta CRL."
> > >
> > > Denis, I think you missed my point.  And, maybe I am missing yours too.
> > >
> > > A delta CRL identifies the associated base with a CRL number.  This is the
> > > only mechanism, there are no others.  Therefore, for a locally constructed
> > > complete CRL to be subsequently updated by a later delta CRL, we must know
> > > what CRL number to assign it.
> > >
> > > > > >Now the reason to separate the two cases is that before using a
> > > locally
> > > > > >constructed CRL you have to build it, this is covered by the MUST
> > > > statement.
> > > > > >Using locally constructed CRLs is an optimization that does not need
> > > to be
> > > > > >supported. Hence why it is covered under a MAY statement. In other
> > > > words, an
> > > > > >implementation may be conformant without the need to implement the
> > > > > >optimization case.
> > > >
> > > > > We agree.  That is handled in a different paragraph.  With the sentence
> > > > > that I agreed to add, the paragraph that I am referring to reads:
> > > > >
> > > > >     An application that supports delta CRLs MUST be able to construct a
> > > > >     current complete CRL by combining a previously issued complete CRL
> > > > >     and the most current delta CRL.  An application that supports delta
> > > > >     CRLs MAY also be able to construct a current complete CRL by
> > > > >     combining a previously locally constructed compete CRL and the most
> > > > >     current delta CRL.  A delta CRL is considered to be the most
> > > current
> > > > >     one, if and only if the current time is between the times contained
> > > > >     in the thisUpdate and nextUpdate fields.
> > > >
> > > >If I include the modifications proposed by Dave and Tom, this should now
> > > >lead to the following:
> > > >
> > > >    An application that supports delta CRLs MUST be able to construct a
> > > >    current complete CRL by combining a previously issued complete CRL
> > > >    and the most current delta CRL. An application that supports delta
> > > >    CRLs MAY also be able to construct a current complete CRL by
> > > >    combining a previously locally constructed compete CRL and the most
> > > >    current delta CRL. A delta CRL is considered to be a current one if
> > > >    the current time is between the time contained in the thisUpdate and
> > > >    nextUpdate fields. If more than one current delta CRL for a given
> > > scope
> > > >    is encountered, the application MUST consider the one with the latest
> > > >    value in thisUpdate to be the most current one; while if only one
> > > >    current delta CRL for a given scope is encountered, the application
> > > >    MUST consider it to be the most current one.
> > > >
> > > >However, this text is not sufficient and only valid for a current time and
> > > >not a time in the past, ... while the text I am still proposing is valid
> > > for
> > > >the current time and a time T in the past. See above.
> > >
> > > Again, it is my belief that implementations MUST be able to validate
> > > certificates based on the current time, but that support for historic time
> > > values is optional.  Thus, support for the validation of historical delta
> > > CRLs with historical certificates is also optional.  There are many
> > > applications of certificates and CRLs where such features will never come
> > > into play, so they should not be mandated by this profile.
> > >
> > > > > > >     When a delta CRL is combined with a complete CRL or a locally
> > > > > > >     constructed CRL, the resulting locally constructed CRL has the
> > > CRL
> > > > > > >     number specified in the CRL number extension found in the delta
> > > CRL
> > > > > > >     used in its construction.
> > > > > >
> > > > > >We do not need to locally number the CRLs. The "equivalent" algorithm
> > > > I have
> > > > > >provided does not need that local numbering. It is a local matter
> > > issue,
> > > > > >that is *not* needed by the algorithm. This explains you the reason of
> > > the
> > > > > >wording I have used under the MAY statement.
> > > >
> > > > > I have already addressed this above.  We already say that any algorithm
> > > > > that provides the same results is sufficient.  However, this is needed
> > > if
> > > > > subsequent delta CRLs are going to be applied to the resulting locally
> > > > > constructed complete CRL.
> > > >
> > > >I believe that I have demonstrated that this is not needed.
> > >
> > > I disagree.
> > >
> > > Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62980e09800 for ietf-pkix-bks; Mon, 2 Jul 2001 02:08:00 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6297wm09795 for <[e-mail]>; Mon, 2 Jul 2001 02:07:58 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA39444; Mon, 2 Jul 2001 11:08:49 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA15394; Mon, 2 Jul 2001 11:07:20 +0200
Message-ID: <[e-mail]>
Date: Mon, 02 Jul 2001 11:07:18 +0200
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail], Tim Polk <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Tom,

(snip)

> I have some problems with this text, first with "most current" and then
> with the two last MUST. I propose the following fix:
 
>  An application that supports delta CRLs MAY be able to construct a
>  complete CRL for a reference time T prior to the current time by combining 
>  a complete CRL issued no later than T and a delta CRL valid as of T.
>  A delta CRL is considered to be valid at a given time T if T is
>  between the times contained in the thisUpdate and nextUpdate fields.
>  If more than one current delta CRL for a given scope as of T is
>  encountered, the application SHOULD consider the one with the latest value
>  in thisUpdate to be the most current one; while if only one current delta
>  CRL for a given scope as of T is encountered, the application SHOULD
>  consider it to be the most current one. Note that if two delta CRLs, valid
>  at time T, are placed in a repository, unless additional security measures
>  are taken, there is no guarantee that both will necessarilly be seen.
 
 [Tom] I'll leave SHOULD vs. MUST for Russ, although I don't understand what
 would lead a retrospective verifier to use the second or third most current
 delta CRL rather than the most current, if he recognizes them as such.
 Your last sentence is helpful, although I don't think that the measures
 which guarantee both deltas being seen are security measures.  The most
 common reason to only see one would be an LDAP client implementation which
 only picked up one value of a multi-valued attribute.

The most common reason to only see one CRL has nothing to do with LDAP.
The reasons are among the following:

  a) the administrator of one of the repositories where the CRLs are
    replicated has purposely suppressed some CRLs. This is a suppression 
    while in storage.

  b) during the replication process some CRLs have been removed. This is
     a suppression while in transit.

X509 does NOT rely on the security of the repositories (called Directories)
or of their administrators. 


Denis

(snip)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f623Vbo09419 for ietf-pkix-bks; Sun, 1 Jul 2001 20:31:37 -0700 (PDT)
Received: from e1.ny.us.ibm.com ([32.97.182.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f623VZm09413 for <[e-mail]>; Sun, 1 Jul 2001 20:31:35 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA233734; Sun, 1 Jul 2001 23:29:40 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f623PTb154052; Sun, 1 Jul 2001 23:25:29 -0400
Importance: Normal
Subject: RE: caCompromise
To: Santosh Chokhani <[e-mail]>
Cc: Marc Branchaud <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Sun, 1 Jul 2001 23:31:01 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.7a SPR #MIAS4UTJ8H, S/390 SPR #JHEG4V8UT5 & S/390 SPR #JHEG4WERGL |May 21, 2001) at 07/01/2001 11:31:31 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

     If the publication site is known to the RP independently, someone
compromising a CA key needs to also take control of that site (or spoof the
paths to it) in order to effectively fool RP's into accepting certificates
issued by the compromiser.    Some of the improvements in flexibility in
specifying publication sites in a certificate (notably AIA's and CRL DP's)
allow an attacker to specify that revocation information will be published
at sites under his own control for certificates which he himself generates,
thus rendering a CA compromise even more catastrophic than it would
otherwise be.  This is similar to what Ambarish pointed out, I think.
     This effect can be lessened if the definition of a trust anchor
constrains the location of the revocation information sufficiently that an
attacker cannot do this, although CRL's without distribution points are
sufficiently constrained themselves.  This thread has been dealing with the
consequences of CA Compromise and means of ensuring that RP's are notified
of that condition.

          Tom Gindin


Santosh Chokhani <[e-mail]> on 06/30/2001 12:22:15 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Marc Branchaud
      <[e-mail]>
cc:   [e-mail]
Subject:  RE: caCompromise


Tom:


I do not understand much of what you are saying.  It seems that you are
pointing to a class of problems which do not exist in terms of CRL DP
spoofing.  Can you clarify what you are saying?  Thanks in advance....





-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Friday, June 29, 2001 7:33 PM
To: Marc Branchaud
Cc: [e-mail]
Subject: Re: caCompromise







     One question which this discussion brings up is whether the principle
"Security resides solely in the key" really applies to trust anchors, or
whether a trust anchor is more appropriately expressed as the product of a
public key and a communications path (for CA's, some of the constraint
extensions are also potentially appropriate).  Ambarish's earlier point
about an attacker avoiding the detection of a compromise via OCSP by
issuing a certificate with an AIA pointing to a compromised system suggests

this direction, and the same thing can be done to a CRL user by abusing
named distribution points.  The original use of CRL's implied a fixed
directory name as a point of distribution instead - which happened to stop
this particular class of attack.
     After all, compromising a key does not always imply compromising the
physical server where it is used, although it often can.


          Tom Gindin





Marc Branchaud <[e-mail]>@mail.imc.org on 06/27/2001
07:41:17 PM


Sent by:  [e-mail]





To:   [e-mail]
cc:
Subject:  Re: caCompromise







Ambarish Malpani wrote:
>
> Compromise of a VA's key is *not* the same as compromise of the
> CA's key, in that the VA can't get you to trust new entities.
> However, if the VA's key is compromised, you might end up trusting
> certs previously revoked by one of the CAs.


Then Santosh Chokhani wrote:
>
> I agree with you that even if the VA compromise is not reported, exposure

> is less since you do not use VA to verify signatures on the certificates.


By "VA" I take it you both mean a status-serving, OCSP-type server.


If, however, you're talking about something that does delegated path
validation (DPV), then I disagree with you both.  A compromised DPV server
can lead you to accept anything that it wants you to accept.


                     Marc