Subject: PKIX WG agenda for 54th IETF

From: Tim Polk <[email-masked]>
Date: Wed, 10 Jul 2002 10:55:24 -0400

The current agenda for the PKIX WG at the 54th IETF meeting is attached.

Thanks,

Tim Polk

---

From: "Roberto Opazo" <[email-masked]>
Date: Fri, 12 Jul 2002 10:38:42 -0400

Hello:

I am trying to get some support to promote the use of Permanent Identifiers
in my country. In particular, it would be very useful if you send me the
following information:

1.- Who is working on that. I mean witch providers are going to support PI
codifying?

2.- If someone has emitted a certificate with a PI I would be pleased to
have a copy of that. In fact I would like to have a set of certificates with
PI.

3.- Does anyone know about the browser support. Microsoft, Netscape or Opera
are going to support that?

Thanks a lot,

Roberto Opazo

---

From: "Roberto Opazo" <[email-masked]>
Date: Fri, 12 Jul 2002 10:38:42 -0400

Hello:

Thanks a lot,

Roberto Opazo

---

From: "Roberto Opazo" <[email-masked]>
Date: Fri, 12 Jul 2002 10:38:42 -0400

Hello:

Thanks a lot,

Roberto Opazo

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 15 Jul 2002 09:10:14 +0200

Hi Roberto,

Due to the fact that the coming PI RFC neither supports [1], nor
exploits [2], current well-established practices of commercial
CAs and SW, there is an obvious risk that it will not get proper
attention in spite of good intentions by the authors.

1] Using DNs as the primary place-holder for identity elements.

This practice is already in extensive use since years back (including
holding permanent identifiers), and it is probably a bit too late to
change this now.  Mostly people are comfortable with this system
as well, and certificate mapping software like Microsoft's IIS only
supports DN-based operations.  As the PI-extension does not
support DN-based PI-data at all, it effectively requires such data to
be _duplicated_ to support current mapping techniques.

2] For reasons like simplicity, fear of getting sued due to customer err,
   and technical support concerns, practically all serious CAs limit
   their issuance of certificates to one entity-type per CA-cert/key.

This fact rather make _CA-certs_ the prime candidate for holding
PI-declarations, which associated entity-certificates using path-
validation-like syntax-checking algorithms would have to obey.
Such schemes would in many cases also allow CA-certs to be re-
generated using existing keys, to support _migration_ to explicit
PI-usage without recalling existing entity-certificates (typically
using serialnumber etc. for storing IDs), which would subsequently
become fully PI-compliant by the "reborn" CA.

As an example of how [badly] an entity-cert.-only scheme works,
I can mention that VeriSign have defined a private DUNS-extension
in their web-server certificates.  Now assume that an RP is building
support for that in their applications.   As the DUNS-extension in
similarity to the PI-extension is optional, the RP software must

- look for the extension and if available extract DUNS-data

- fail gracefully or fail hard if a received certificate does not have
  the wanted extension, in spite of coming from an accepted CA,
  and vouching for the requested entity type (implicit in the case
  of VeriSign)

- using PIs you would also have to look for matching identifierType
  so you don't end-up accepting an invalid entity type (what an
  unspecified identifierType as allowed by the PI-draft means in
  terms of entity-type, you cannot have really _any_ idea about).

By using a single, CA-specified PI-declarator, you limit hassles
to an absolute minimum as you at the moment of CA-acceptance
know _exactly_, and _in_advance_, what to expect and have
decided to "digest" or not, and all the gory stuff can be handled
automatically by an enhanced standard certificate processing
subsystem (at least if assuming that a specific RP is unlikely to
support more than a single PI-scheme).  This is particularly
desirable in non-programmatic situations like in the afore-
mentioned IIS mapping setup.

Robustness and rigidity, the cornerstones of real interoperability. :-)

Using the PI-draft extension OTOH, you know essentially nothing
what to expect in terms of entity-certificates.

The reason I am a bit concerned is that I can hardly find a _single_
entity-certificate-type that would not benefit from PI-support, ranging
from e-mail certificates (as an e-mail address may be used as a PI
belonging to the Internet naming domain), to web-server certificates
containing DUNS, and to national and organization-wide ID-schemes
using citizen- and employee-codes.
Can you?

The "rough consensus" that has been achieved for the PI draft, is
IMHO mainly based on a general lack of interest in the subject.

cheers,
Anders

----- Original Message ----- 
From: "Roberto Opazo" <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 12, 2002 16:38
Subject: PI support 

Hello:

Thanks a lot,

Roberto Opazo