Subject: Agenda for 53rd IETF

From: Tim Polk <[email-masked]>
Date: Wed, 13 Mar 2002 09:12:23 -0500

Folks,

For those who will be in Minneapolis, I have appended our agenda to this 
message.  As usual, we have a full agenda.  *If* we run on time, we will 
run five minutes over... I forgot to allot five minutes to myself for 
document status.

As a result, I hope to start our session promptly at 1:00 on Wednesday.  I 
figured that deserved a warning message to the list!  I look forward to 
seeing you all there.

Thanks,

Tim Polk

----------------- PKIX WG agenda, 53rd IETF ----------------------

PKIX WG (pkix-wg)

WEDNESDAY, March 20 at 1300-1500
=================================

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

AGENDA:

I. Document Status Review (5 min.)              Tim Polk (NIST)

II. DPD/DPV Requirements and Protocol

	a. DPV Requirements Status (10 min.)    Denis Pinkas (Bull)	

	b. SCVP (20 min.)                       Ambarish Malpani (ValiCert)

III. OCSP update (5 Min.)                       Ambarish Malpani (ValiCert)	

IV. New Specifications

	a. ACRMF and ACMC (15 min.)             Peter Yee (RSA)

	b. OCKID (10 min.)                      Paul Hoffman (IMC/VPNC)

c. Policy requirements for TSAs (5 min.)        Denis Pinkas (Bull)		
	
V. Ongoing Specifications

	a. TSP interoperability testing update  Denis Pinkas (Bull)
	and anticipated to TSP (10 min.)	

	b. Permanent Identifiers (10 min.)      Denis Pinkas (Bull)	

	c. Proxy Certificates (10 min.)         Steve Tuecke (ANL)

	d. Logotypes (5 min.)                   Stefan Santesson (AddTrust)

VI. Personal drafts

	a. DNS as X.509 PKIX Certificate        Jakob Schlyter (Carlstedt R&T)
	Storage (10 min.)		

	b. An LDAPv3 Schema for X.509           Peter Gietz (DAASI)
	Certificates (10 min.)

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 15 Mar 2002 11:25:40 +0100

As author and implementer of RFC 3039 and in the light of practical 
experience with RFC 3039, I think we should be ready to revise this RFC and 
handle some defects.

The defects I have recorded so far are:

1) Key usage
The key usage bit non-repudiation SHOULD NOT be set together with any other 
key usage according to RFC 3039. This has caused a lot of confusion and 
this "SHOULD NOT" statement is not compatible with existing reality.

2) Attribute semantics
This function to define semantics for attributes included in the subject 
field is very useful and it covers almost everything that the current PI 
draft wants to solve. The problem is that this function is part of the 
qcStatements extension which it should not be. Firstly due to the fact that 
this statement has nothing to do with the intent of this extension and 
secondly because criticality setting for this function get mixed up with 
completely unrelated stuff in its current form.

3) Usage and purpose
RFC 3039 is the only RFC defining structure of a personal ID certificate. 
This should not be limited just to Qualified certificates. It should be 
more clear that this RFC is useful for any personal ID certificate. Also 
non-qualified ones.

Finally I believe that a revision of RFC 3039 should include considerations 
to avoid the need for a PI extension according to the PI draft.

I can't see that the PI draft accomplish anything that RFC 3039 doesn't 
already solve, or at least would solve after revision. The only exception 
is the function to define an identifier completely independent of the 
subject name. I would tough argue that the total case with all aspects on 
the table probably doesn't justify another feature for that and that there 
are other ways to solve this within the realm of X.509 and PKIX standards.

I still believe that a creative revision of RFC 3039 could be made to cover 
what we need in this area. And I also recall this as an initially defined 
possibility laid down for the PI work.

/Stefan

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 15 Mar 2002 15:03:56 +0100

Stefan,

See some comments below:
 
> experience with RFC 3039, I think we should be ready to revise this RFC
> and handle some defects.
> 
> The key usage bit non-repudiation SHOULD NOT be set together with any
> other key usage according to RFC 3039. This has caused a lot of confusion
> and this "SHOULD NOT" statement is not compatible with existing reality.

Could you be more explicit about a suggested text replacement ?

> draft wants to solve. 

Could you be more specific ?

> The problem is that this function is part of the
> qcStatements extension which it should not be. Firstly due to the fact
> that this statement has nothing to do with the intent of this extension
> and secondly because criticality setting for this function get mixed up
> with completely unrelated stuff in its current form.
 
> more clear that this RFC is useful for any personal ID certificate. Also

Fine.
 
> Finally I believe that a revision of RFC 3039 should include
> considerations to avoid the need for a PI extension according to the PI
> draft.
> 
> already solve, or at least would solve after revision. 

The revised document will not be able to solve what the PI document covers
since the PI document applies to *any entity* whereas the revised RFC 3039
document is planned to apply only to *personal ID certificates*. Maybe the
revised RFC 3039 could take advantage and refer to the PI document.

> The only exception is the function to define an identifier completely 
> independent of the subject name. 

Thank you for noticing this difference.

Regards,

Denis

> I would tough argue that the total case with all aspects on
 
> I still believe that a creative revision of RFC 3039 could be made to
> cover what we need in this area. And I also recall this as an initially
> defined possibility laid down for the PI work.

---

From: "Roberto Opazo Gazmuri" <[email-masked]>
Date: Fri, 15 Mar 2002 17:36:17 -0400

> revised RFC 3039 could take advantage and refer to the PI document.

I agree.

The PI purpose is important enough to be in an independent discussion and
RFC, even considering than QC could be modified to apply to any entity.

Best regards,

Roberto

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 16 Mar 2002 00:52:54 +0100

Denis,

I will be more specific but I didn't want to take up to much space in the 
start of the discussion

I'm not ready to suggest text replacement right now but the key usage 
restriction should go and at least allow, without any restriction, 
combination of digital signature AND non-repudiation.

For attribute semantics I think today that any such declaration has nothing 
to do with any legal statements concerning qualified certificates. Having 
that function in its current extension is to me a defect. If you want me to 
be more specific I have to owe you but I wont' have trouble to come up with 
examples and reasons.

I will also rise these problems with ETSI.

This was just an initiation of the discussion and I expect to discuss more 
with you and others at Minneapolis.

Especially concerning assassination of PI :-)

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 19 Mar 2002 17:26:41 +0100

Maybe I should clarify myself.

I believe that many of the functionality aspects, that PI was design to 
meet, is achieved by defining semantics of data stored in DN attributes.

I just want to invite people who think they need the PI solution to see 
what they can do with attribute semantics and open the discussion to 
suggestions that would further improve this solution.

Maybe this would reduce the need for a separate PI solution to the extent 
where its just not justified to make YAP. But I remain open to that issue.

/Stefan

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 19 Mar 2002 19:26:26 +0100

Stefan,
As you probably know well, I have advocated (for about 2 years),
that a PI extension should indeed contain an OID or similar to point
out what DN attributes (usually one) contain the unique data.  This
means that existing DN schemes (containing the PI-data) can be kept
and the extension added "silently".  This so called "migration solution"
has been banned by [*censored*], who claim that this "habit" creates
bad DNs (DITs?) and must be stopped, in the same way as rcf822 names,
that still are deprecated by son-of-2459 authors in spite of being de-facto
standard.  So I give you little chance to get support for existing practices
and market.  I have already tried that route...

Regarding 3039, I think whatever mechanism PKIX may come up with,
it is rather a son-of-2459 or independent topic we are dealing with as
PIs has uses outside of personal certificates.

/anders

----- Original Message ----- 
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 19, 2002 17:26
Subject: RE: Updating RFC 3039 - and its impact on PI

/Stefan

---

From: "Roberto Opazo Gazmuri" <[email-masked]>
Date: Tue, 19 Mar 2002 20:35:01 -0400

Stefan,

I see 2 different points here:

1.- In witch context should we discuss a PI solution?
I believe the PI document is well justified and this discussion is proving
that.

2.- Should we use DN or GN to codify PIs?
This point was analysed previously. I my opinion there are good reasons to
prefer GN:
  a)	DNs are overloaded enough and especially de subject field, this field
should be as international as it is possible. A PI is typically a locally
assigned value, so it is not a good idea to put it in the subject.
  b)	One person could have many PIs of different type, like passport number,
security number, client number and another passport number (double
nationality or a passport number assigned for commercial purposes).
  c)	One PI value identifies an entity by it self, so it not natural to put
this value in a Directory Information Tree, because this will be always a 2
levels tree.
  d)	In essence, a PI is another way to call an entity, so it is very
natural to use OtherName in SubjectAltName extension.

Best regards,

Roberto Opazo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Stefan Santesson
> Enviado el: martes, 19 de marzo de 2002 12:27
> Para: [email-masked]
> Asunto: RE: Updating RFC 3039 - and its impact on PI
>
>
>