Subject: ETSI Draft CA Policy Requirements - Comments Requested

From: "Nick Pope" <[email-masked]>
Date: Mon, 30 Jul 2001 18:04:02 +0100

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 [email-masked], with copy to the editor
on [email-masked].   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
[email-masked]

and

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

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 [email-masked], with copy to the editor
on [email-masked].   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
[email-masked]

and

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

From: "Nick Pope" <[email-masked]>
To: <[email-masked]>
Subject: ETSI Draft CA Policy Requirements - Comments Requested
Date: Mon, 30 Jul 2001 18:04:02 +0100
Importance: Normal
Sender: [email-masked]

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 [email-masked], with copy to the editor
on [email-masked].   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
[email-masked]

and

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

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 [email-masked], with copy to the editor
on [email-masked].   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
[email-masked]

and

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-00.txt
Date: Fri, 27 Jul 2001 07:22:49 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

From: Peter Sylvester <[email-masked]>
Date: Thu, 26 Jul 2001 16:41:32 +0200 (MET DST)
To: [email-masked]
Subject: DPD DPV comparison
Sender: [email-masked]

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

From: "Pawling, John" <[email-masked]>
To: "ietf-pkix@imc. org (E-mail)" <[email-masked]>
Subject: v1.9.2 Certificate Management Library Now Available
Date: Wed, 25 Jul 2001 09:59:42 -0400
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

Date: Tue, 24 Jul 2001 12:21:04 -0700
To: OSI Directory List <[email-masked]>, "X.509":;
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: Defect resolution for X.509
Sender: [email-masked]

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

From: "Nick Pope" <[email-masked]>
To: <[email-masked]>
Subject: Draft ETSI TS "XML Advanced Electronic Signatures"
Date: Tue, 24 Jul 2001 17:58:00 +0100
Importance: Normal
Sender: [email-masked]

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 [email-masked], with copy to the editor on
[email-masked] .   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)
[email-masked]

and

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-new-rfc2527-00.txt
Date: Tue, 24 Jul 2001 06:33:15 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-cmc-trans-00.txt
Date: Tue, 24 Jul 2001 06:33:10 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-cmc-archive-00.txt
Date: Tue, 24 Jul 2001 06:33:04 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-cmc-compl-00.txt
Date: Tue, 24 Jul 2001 06:32:59 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Subject: draft-ietf-pkix-new-part1-08.txt
From: "Rob G Weemhoff" <[email-masked]>
Date: Tue, 24 Jul 2001 09:43:36 +0200
Sender: [email-masked]

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:        +31(0)20 513  9102 
Mobile: +31(0)653263269

E-mail: [email-masked] 
Fax: +31(0)33 247057
Computerweg 8
3821 AB  Amersfoort
The Netherlands

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, IANA <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Protocol Action: An Internet Attribute Certificate Profile for Authorization to Proposed Standard
Date: Fri, 20 Jul 2001 10:25:20 -0400
Sender: [email-masked]

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.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-06.txt
Date: Fri, 20 Jul 2001 05:37:23 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc2797-bis-01.txt
Date: Thu, 19 Jul 2001 07:06:08 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

From: "Nick Pope" <[email-masked]>
To: <[email-masked]>
Subject: ETSI Draft Time-stamping Policy - comments requested
Date: Tue, 17 Jul 2001 21:56:04 +0100
Importance: Normal
Sender: [email-masked]

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 [email-masked], with copy to the editor on
[email-masked].   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
[email-masked]

and

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
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)
Sender: [email-masked]

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, [email-masked] 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: [email-masked] [mailto:[email-masked]]
> > > Sent: 11 July 2001 15:20
> > > To: Housley, Russ
> > > Cc: [email-masked]
> > > 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, [email-masked] 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, [email-masked] 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.
> > _______________________________________________________________________

From: Peter Sylvester <[email-masked]>
Date: Mon, 16 Jul 2001 19:00:20 +0200 (MET DST)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: New draft of son-of-2459
Cc: [email-masked]
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Mon, 16 Jul 2001 18:12:35 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: New draft of son-of-2459
Cc: [email-masked]
Sender: [email-masked]

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

Date: Mon, 16 Jul 2001 10:08:06 -0400
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: New draft of son-of-2459
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Sun, 15 Jul 2001 16:25:13 -0700
To: "X.509":;, IETF LDAP <[email-masked]>
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: announcement of X.500 meeting 24-28 September in Flagstaff Arizona
Sender: [email-masked]

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

From: Michael Zolotarev <[email-masked]>
To: Denis Pinkas <[email-masked]>, pkix <[email-masked]>
Subject: RE: DPV and DPD
Date: Sat, 14 Jul 2001 14:15:21 +1000
Sender: [email-masked]

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

From: [email-masked]
To: "Graham Bland" <[email-masked]>
Cc: <[email-masked]>
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
Sender: [email-masked]

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: <[email-masked]>
> To: "Bland, Graham" <[email-masked]>
> Cc: <[email-masked]>
> 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: [email-masked][SMTP:[email-masked]]
> > > Sent: Thursday, July 12, 2001 11:28:07 PM
> > > To: Bland, Graham
> > > Cc: [email-masked]
> > > 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: [email-masked] [mailto:[email-masked]]
> > > > Sent: 11 July 2001 15:20
> > > > To: Housley, Russ
> > > > Cc: [email-masked]
> > > > 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, [email-masked] 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, [email-masked] 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.
> > _______________________________________________________________________
> >
> 

From: "todd glassey" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: New draft of son-of-2459 
Date: Thu, 12 Jul 2001 20:02:52 -0700
Sender: [email-masked]

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

From: [email-masked]
To: "Bland, Graham" <[email-masked]>
Cc: [email-masked]
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
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
> > Sent: 11 July 2001 15:20
> > To: Housley, Russ
> > Cc: [email-masked]
> > 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, [email-masked] 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, [email-masked] 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.
> _______________________________________________________________________

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRI Profile to Proposed Standard
Reply-to: [email-masked]
Date: Thu, 12 Jul 2001 16:16:01 -0400
Sender: [email-masked]

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

Date: Thu, 12 Jul 2001 17:51:58 +0200
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: pkix <[email-masked]>
Subject: DPV and DPD
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
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)
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
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)
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-proxy-00.txt
Date: Thu, 12 Jul 2001 07:07:07 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dpv-dpd-00.txt
Date: Thu, 12 Jul 2001 07:07:03 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

From: "Stefan Kraxberger" <[email-masked]>
To: <[email-masked]>
Subject: Experimental TSA (IAIK Graz)
Date: Thu, 12 Jul 2001 11:52:28 +0200
Sender: [email-masked]

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

Date: Thu, 12 Jul 2001 11:19:21 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
Cc: [email-masked]
Subject: Re: New draft of son-of-2459 (Was: I-D  ACTION:draft-ietf-pkix-new-part1-08.txt)
Sender: [email-masked]

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

From: "Bland, Graham" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
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
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
> Sent: 11 July 2001 15:20
> To: Housley, Russ
> Cc: [email-masked]
> 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, [email-masked] 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, [email-masked] 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.
_______________________________________________________________________

From: "Scott, Greg" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: 2797-bis confirm cert control attribute
Date: Wed, 11 Jul 2001 16:06:41 -0400
Sender: [email-masked]

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/

Date: Wed, 11 Jul 2001 18:05:57 +0200
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Logotypes in Certificates - Report and proposal to work on new standard
Sender: [email-masked]

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

Date: Wed, 11 Jul 2001 11:43:28 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new-part1-08.txt)
Cc: [email-masked]
Sender: [email-masked]

At 3:19 PM +0000 7/11/01, [email-masked] 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

From: [email-masked]
To: "Housley, Russ" <[email-masked]>
Cc: [email-masked]
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
Sender: [email-masked]

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

From: [email-masked]
To: "Bland, Graham" <[email-masked]>
Cc: [email-masked]
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
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
> > Sent: 10 July 2001 16:17
> > To: Anders Rundgren
> > Cc: [email-masked]; 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.
> _______________________________________________________________________

From: [email-masked]
To: "Bland, Graham" <[email-masked]>
Cc: [email-masked]
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
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
> > Sent: 10 July 2001 16:17
> > To: Anders Rundgren
> > Cc: [email-masked]; 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.
> _______________________________________________________________________

From: [email-masked]
To: "Housley, Russ" <[email-masked]>
Cc: [email-masked]
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
Sender: [email-masked]

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

From: "Bland, Graham" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
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
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
> Sent: 10 July 2001 16:17
> To: Anders Rundgren
> Cc: [email-masked]; 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.
_______________________________________________________________________

From: [email-masked]
To: "Housley, Russ" <[email-masked]>
Cc: [email-masked]
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
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
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)
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Anders Rundgren <[email-masked]>
Cc: [email-masked], Tim Polk <[email-masked]>
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)
Sender: [email-masked]

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

From: [email-masked]
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>, "Tim Polk" <[email-masked]>
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
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-03.txt
Date: Tue, 10 Jul 2001 10:27:19 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, "Tim Polk" <[email-masked]>
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
Sender: [email-masked]

"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

From: Olle Larsson <[email-masked]>
To: Olle Larsson <[email-masked]>, "'Trevor Freeman'" <[email-masked]>, Ambarish Malpani <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Should a CRL number be unique or not ?
Date: Sat, 7 Jul 2001 16:28:49 +0200 
Sender: [email-masked]

My apologies: scrap that. Mental meltdown...

/Olle

-----Original Message-----
From: Olle Larsson [mailto:[email-masked]]
Sent: Saturday, July 07, 2001 12:11 PM
To: 'Trevor Freeman'; Ambarish Malpani
Cc: [email-masked]'
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:[email-masked]]
Sent: Friday, July 06, 2001 11:43 PM
To: Ambarish Malpani
Cc: [email-masked]
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:[email-masked]] 
Sent: Friday, July 06, 2001 11:52 AM
To: Trevor Freeman
Cc: [email-masked]
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, July 06, 2001 11:44 AM
> To: Ambarish Malpani; David P. Kemp
> Cc: [email-masked]
> 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:[email-masked]]
> Sent: Friday, July 06, 2001 10:53 AM
> To: Trevor Freeman; David P. Kemp
> Cc: [email-masked]
> 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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> 
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[email-masked]]
> > Sent: Friday, July 06, 2001 9:09 AM
> > To: David P. Kemp
> > Cc: [email-masked]
> > 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]
>  
> 

From: Santosh Chokhani <[email-masked]>
To: Trevor Freeman <[email-masked]>, Ambarish Malpani <[email-masked]>
Cc: [email-masked]
Subject: RE: Should a CRL number be unique or not ?
Date: Sat, 7 Jul 2001 09:36:57 -0400 
Sender: [email-masked]

From: Olle Larsson <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, Ambarish Malpani <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Should a CRL number be unique or not ?
Date: Sat, 7 Jul 2001 12:10:52 +0200 
Sender: [email-masked]

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:[email-masked]]
Sent: Friday, July 06, 2001 11:43 PM
To: Ambarish Malpani
Cc: [email-masked]
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:[email-masked]] 
Sent: Friday, July 06, 2001 11:52 AM
To: Trevor Freeman
Cc: [email-masked]
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, July 06, 2001 11:44 AM
> To: Ambarish Malpani; David P. Kemp
> Cc: [email-masked]
> 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:[email-masked]]
> Sent: Friday, July 06, 2001 10:53 AM
> To: Trevor Freeman; David P. Kemp
> Cc: [email-masked]
> 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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> 
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[email-masked]]
> > Sent: Friday, July 06, 2001 9:09 AM
> > To: David P. Kemp
> > Cc: [email-masked]
> > 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]
>  
> 

content-class: urn:content-classes:message
Subject: RE: Should a CRL number be unique or not ?
Date: Fri, 6 Jul 2001 14:43:28 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Ambarish Malpani" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Friday, July 06, 2001 11:52 AM
To: Trevor Freeman
Cc: [email-masked]
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, July 06, 2001 11:44 AM
> To: Ambarish Malpani; David P. Kemp
> Cc: [email-masked]
> 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:[email-masked]]
> Sent: Friday, July 06, 2001 10:53 AM
> To: Trevor Freeman; David P. Kemp
> Cc: [email-masked]
> 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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> 
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[email-masked]]
> > Sent: Friday, July 06, 2001 9:09 AM
> > To: David P. Kemp
> > Cc: [email-masked]
> > 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"

AAAAAAAA

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

Content-return: allowed
Date: Fri, 06 Jul 2001 11:52:19 -0700
From: Ambarish Malpani <[email-masked]>
Subject: RE: Should a CRL number be unique or not ?
To: "'Trevor Freeman'" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, July 06, 2001 11:44 AM
> To: Ambarish Malpani; David P. Kemp
> Cc: [email-masked]
> 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:[email-masked]] 
> Sent: Friday, July 06, 2001 10:53 AM
> To: Trevor Freeman; David P. Kemp
> Cc: [email-masked]
> 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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> 
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[email-masked]]
> > Sent: Friday, July 06, 2001 9:09 AM
> > To: David P. Kemp
> > Cc: [email-masked]
> > 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]
>  
> 

content-class: urn:content-classes:message
Subject: RE: Should a CRL number be unique or not ?
Date: Fri, 6 Jul 2001 11:43:55 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Ambarish Malpani" <[email-masked]>, "David P. Kemp" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Friday, July 06, 2001 10:53 AM
To: Trevor Freeman; David P. Kemp
Cc: [email-masked]
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, July 06, 2001 9:09 AM
> To: David P. Kemp
> Cc: [email-masked]
> 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"

AAAAAAAA

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

Content-return: allowed
Date: Fri, 06 Jul 2001 10:53:13 -0700
From: Ambarish Malpani <[email-masked]>
Subject: RE: Should a CRL number be unique or not ?
To: "'Trevor Freeman'" <[email-masked]>, "David P. Kemp" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, July 06, 2001 9:09 AM
> To: David P. Kemp
> Cc: [email-masked]
> 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]

content-class: urn:content-classes:message
Subject: RE: Should a CRL number be unique or not ?
Date: Fri, 6 Jul 2001 09:08:45 -0700
From: "Trevor Freeman" <[email-masked]>
To: "David P. Kemp" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Monday, July 02, 2001 2:17 PM
Cc: [email-masked]
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"

AAAAAAAA

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

Date: Thu, 05 Jul 2001 17:33:15 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: mail from submission manager
Sender: [email-masked]

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

Date: Thu, 05 Jul 2001 16:20:15 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: New draft of son-of-2459 (Was: I-D ACTION:draft-ietf-pkix-new-part1-08.txt)
Sender: [email-masked]

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

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>

Date: Tue, 03 Jul 2001 09:43:24 -0400
From: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt
Sender: [email-masked]

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

From: Santosh Chokhani <[email-masked]>
To: Tom Gindin <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: Marc Branchaud <[email-masked]>, [email-masked]
Subject: RE: caCompromise
Date: Tue, 3 Jul 2001 09:02:47 -0400 
Sender: [email-masked]

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:[email-masked]]
Sent: Monday, July 02, 2001 7:57 PM
To: Santosh Chokhani
Cc: Marc Branchaud; [email-masked]
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 <[email-masked]> on 07/02/2001 08:39:31 AM

To:   Tom Gindin <[email-masked]>, Santosh Chokhani
      <[email-masked]>
cc:   Marc Branchaud <[email-masked]>, [email-masked]
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:[email-masked]]
Sent: Sunday, July 01, 2001 11:31 PM
To: Santosh Chokhani
Cc: Marc Branchaud; [email-masked]
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 <[email-masked]> on 06/30/2001 12:22:15 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Marc Branchaud
      <[email-masked]>
cc:   [email-masked]
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:[email-masked]]
Sent: Friday, June 29, 2001 7:33 PM
To: Marc Branchaud
Cc: [email-masked]
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 <[email-masked]>@mail.imc.org on 06/27/2001
07:41:17 PM

Sent by:  [email-masked]

To:   [email-masked]
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:[email-masked]">mailto:[email-masked]</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; [email-masked]</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;[email-masked]&gt; on =
07/02/2001 08:39:31 AM</FONT>
</P>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; Tom Gindin =
&lt;[email-masked]&gt;, Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp; Marc Branchaud =
&lt;[email-masked]&gt;, [email-masked]</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:[email-masked]">mailto:[email-masked]</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; [email-masked]</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;[email-masked]&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;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp; [email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked]</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;[email-masked]&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; [email-masked]</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; [email-masked]</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--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-08.txt
Date: Tue, 03 Jul 2001 06:58:44 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 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 [email-masked] 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Importance: Normal
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt
To: Denis Pinkas <[email-masked]>
Cc: "Housley, Russ" <[email-masked]>, [email-masked], Tim Polk <[email-masked]>
From: "Tom Gindin" <[email-masked]>
Date: Mon, 2 Jul 2001 20:28:55 -0400
Sender: [email-masked]

     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 <[email-masked]> on 07/02/2001 05:07:18 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   "Housley, Russ" <[email-masked]>, [email-masked], Tim
      Polk <[email-masked]>
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)

Importance: Normal
Subject: RE: caCompromise
To: Santosh Chokhani <[email-masked]>
Cc: Marc Branchaud <[email-masked]>, [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Mon, 2 Jul 2001 19:57:10 -0400
Sender: [email-masked]

     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 <[email-masked]> on 07/02/2001 08:39:31 AM

To:   Tom Gindin <[email-masked]>, Santosh Chokhani
      <[email-masked]>
cc:   Marc Branchaud <[email-masked]>, [email-masked]
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:[email-masked]]
Sent: Sunday, July 01, 2001 11:31 PM
To: Santosh Chokhani
Cc: Marc Branchaud; [email-masked]
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 <[email-masked]> on 06/30/2001 12:22:15 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Marc Branchaud
      <[email-masked]>
cc:   [email-masked]
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:[email-masked]]
Sent: Friday, June 29, 2001 7:33 PM
To: Marc Branchaud
Cc: [email-masked]
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 <[email-masked]>@mail.imc.org on 06/27/2001
07:41:17 PM

Sent by:  [email-masked]

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

Date: Mon, 02 Jul 2001 17:17:21 -0400
From: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Should a CRL number be unique or not ?
Sender: [email-masked]

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

Date: Mon, 02 Jul 2001 21:58:55 +0200
From: Maud Schneider <[email-masked]>
To: [email-masked]
Subject: reply to error message?
Sender: [email-masked]

Hello!

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

Thanks Maud

From: Santosh Chokhani <[email-masked]>
To: Tom Gindin <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: Marc Branchaud <[email-masked]>, [email-masked]
Subject: RE: caCompromise
Date: Mon, 2 Jul 2001 08:39:31 -0400 
Sender: [email-masked]

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:[email-masked]]
Sent: Sunday, July 01, 2001 11:31 PM
To: Santosh Chokhani
Cc: Marc Branchaud; [email-masked]
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 <[email-masked]> on 06/30/2001 12:22:15 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Marc Branchaud
      <[email-masked]>
cc:   [email-masked]
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:[email-masked]]
Sent: Friday, June 29, 2001 7:33 PM
To: Marc Branchaud
Cc: [email-masked]
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 <[email-masked]>@mail.imc.org on 06/27/2001
07:41:17 PM

Sent by:  [email-masked]

To:   [email-masked]
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:[email-masked]">mailto:[email-masked]</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; [email-masked]</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;[email-masked]&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;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp; [email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked]</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;[email-masked]&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; [email-masked]</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; [email-masked]</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--

Date: Mon, 02 Jul 2001 11:09:21 +0200
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: "Housley, Russ" <[email-masked]>
CC: [email-masked], Tim Polk <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt
Sender: [email-masked]

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" <[email-masked]>@mail.imc.org on 06/28/2001
> > > 05:18:33 PM
> > >
> > > Sent by:  [email-masked]
> > >
> > > To:   Denis Pinkas <[email-masked]>
> > > cc:   [email-masked]
> > > 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

Date: Mon, 02 Jul 2001 11:07:18 +0200
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Tom Gindin <[email-masked]>
CC: "Housley, Russ" <[email-masked]>, [email-masked], Tim Polk <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt
Sender: [email-masked]

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)

Importance: Normal
Subject: RE: caCompromise
To: Santosh Chokhani <[email-masked]>
Cc: Marc Branchaud <[email-masked]>, [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Sun, 1 Jul 2001 23:31:01 -0400
Sender: [email-masked]

     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 <[email-masked]> on 06/30/2001 12:22:15 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Marc Branchaud
      <[email-masked]>
cc:   [email-masked]
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:[email-masked]]
Sent: Friday, June 29, 2001 7:33 PM
To: Marc Branchaud
Cc: [email-masked]
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 <[email-masked]>@mail.imc.org on 06/27/2001
07:41:17 PM

Sent by:  [email-masked]

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