Son of RFC 3039 draft available

[Stefan Santesson <stefan.retrospekt@xxxxxxxx>]

All,

It seams that I mixed up the cut-off dates for Internet drafts submission 
and submitted the 00 draft on son of RFC 3039 (Qualified Certificates 
Profile) to late.

So I do the second best thing and make the draft available from my own web 
site until it hits the PKIX charter page.

You can get the preliminary draft from:
http://216.219.254.34/retrospekt.com/pages/2/index.htm

The only changes from RFC 3039 is:
 - Clarification of scope
 - Title attribute is moved from subjectDirectoryAttribute to the Subject 
field
 - Requirement to set non-repudiation exclusively if set is removed as a 
SHOULD requirement and left to local profiling.
 - Old references to RFC 2459 are updated to RFC 3280

The intention so far is to limit changes to editorial changes.

The rationale behind these updates are:

1) Clarification of scope
There are numerous if implementations that use RFC 3039 without issuing the 
certificates as Qualified Certificates. Especially the conventions 
regarding use of attributes in the subject field are of general value. The 
clarification of scope express more clearly than before that this standard 
can be used for any ID-certificate issued to humans and further includes 
mechanisms related to Qualified Certificates. This was true also with RFC 
3039 but not so clearly expressed.

2) Title attribute
Suggesting that this attribute should be placed in subject Directory 
attributes was a bad choice that no implementation that I know of has 
followed. Likewise, many applications that need to use the title attribute 
do not support use of subjectDirectoryAttributes. Use of the title 
attribute is common and use of subjectDirectoryAttributes is rare: This is 
a bad mix.

3) Non-repudiation.
This change does not make any contribution to the meaning of this key usage 
declaration, but it suggest that this profile is the wrong place to have 
any opinion on whether this key usage bit should be set exclusively or not. 
The draft suggest that national legislation and local policies have to 
decide this as long as the meaning of the bits are consistent with RFC 3280.

It should also be noted that Tim and Magnus has agreed to co-edit this 
document but they have not yet had the time to fully review this first 
draft so don't hit on them yet for things you don't like.

Any comments and suggestions are welcome

I'll be in San Francisco as well.

/Stefan