Subject: I-D ACTION:draft-ietf-pkix-qc-05.txt

From: [email-masked]
Date: Mon, 24 Jul 2000 06:37:57 -0400

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, T. Polk, P. Barzin, M. Nystrom
	Filename	: draft-ietf-pkix-qc-05.txt
	Pages		: 34
	Date		: 21-Jul-00
	
This document forms a certificate profile for Qualified Certificates,
based on RFC 2459, for use in the Internet. The term Qualified
Certificate is used to describe a certificate with a certain
qualified status within applicable governing law. Further, Qualified
Certificates are issued exclusively 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-05.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-qc-05.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-qc-05.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.

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 25 Jul 2000 09:54:35 +0200

Stefan,
some comments¨

>May I draw your attention to the updated QC 05 where the uniqueness 
>requirement stated in RFC 2459 (and son of) has been clarified to count for 
>the whole lifetime of the CA.

Congratulations!
To me it seems that it is now actually possible to express a software algorithm
for comparing certificates for *equality*.  I.e. removing "handled with care"
to case A: do this (if you like).  cases B: don't try this at home kids!

From the same section (security considerations)

"This implies that the CA must perform proof-of-possession of the
private key. In addition, it implies that the CA have some knowledge
about the subject's cryptographic module."

Why is there not a pre-defined policy attribute for specifying something
about the key container?  The Germans have it already AFIK.  It seems possible
that a single QC CA could allow different container types but some RPs may
not accept soft containers.  A commercial CA is highly likely to have to do
some compromizes like that and let "the market decide".   Then this "market"
needs a way to qualify products in a *simple* way.   It would probably work in such a way that
*if* a user ever got a soft certificate the "account" as a whole will be treated
as "soft" due to lowered security standards.  

Anders