RE: I-D ACTION:draft-ietf-pkix-sonof3039-01.txt

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

All,

As reminder for you who were in Vienna, and as info for those who
weren't, here is what is changed from draft 0.

1) postalAddress has been removed from the list of subject naming
attributes that must be understood as part of the subjects identity.

The reasons are mainly to align with RFC 3280 who doesn't support
postalAddress. To my knowledge there are further no use of this
attribute in the context of RFC 3039 that would motivate its presence
there despite its structure and non-support by RFC 3280.

2) Text concerning key usage has been further clarified. The old RFC
3039 requirement on having NR exclusive when set (SHOULD requirement)
was removed in draft 00. Even though that requirement may be reasonable
in many cases, there is no context in RFC 3039 where this could be
generally stated. The ongoing profiling work in ETSI aims at including
this requirement in the ETSI Qualified Certificates profile where there
IS a context for its definition.

3) text describing the scope of the qcStatements extension has been
updated with a more generic wording.

If anyone needs, I can send a comparison document, showing the exact
changes.

Open issues (except feedback on changes above):
Should the removal of postalAddress from the listed attributes (MUST
implement) in the subject filed could motivate a version number update
in the predefined compliance declaration in the qcStatements extension.

I have not done that update because a) I'm not sure it is needed, and b)
I'm not sure whether that declaration is even used by anyone.


This work is synchronized with the ongoing efforts in ETSI. In order to
keep the time table in ETSI (ready by febr 04) I would stress that the
ambition is to be ready for WG last call by Minneapolis. So please,
those who care about this work, be active now and don't wait until WG
last call :-)


/Stefan



-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Internet-Drafts@xxxxxxxx
Sent: den 25 juli 2003 21:29
Cc: ietf-pkix@xxxxxxx
Subject: I-D ACTION:draft-ietf-pkix-sonof3039-01.txt

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:Qualified 
                          Certificates Profile
	Author(s)	: S. Santesson, M. Nystrom
	Filename	: draft-ietf-pkix-sonof3039-01.txt
	Pages		: 35
	Date		: 2003-7-25
	
This document forms a certificate profile, based on RFC 3280, for
dentity certificates issued to physical persons.
The goal of this document is to define a general syntax independent
of local legal requirements.  The profile is however designed to
allow further profiling in order to meet specific local needs.
The profile defines specific conventions for certificates that are
qualified within a defined legal framework, named Qualified
Certificates. The profile does however not define any legal
requirements for such Qualified Certificates.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

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-sonof3039-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:
	mailserv@xxxxxxxxx
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-sonof3039-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.