Subject: Finalizing sonOfRFC3039

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 28 Oct 2003 12:23:10 -0000

All,

It is time to close the son of RFC 3039 work item and move on.

A new draft was submitted before the cut-off 09.00 yesterday and will
hopefully appear on the IETF PKIX web soon.

In this mail I will summarize the edits that has been done to this
document since RFC 3039.

It is my hope that any issues that anyone may have with this update can
be resolved during IETF in Minneapolis by either direct discussions or
e-mail.

/Stefan

Background:

RFC 3039 is widely adopted and referenced throughout Europe as RFC 3039
together with the ETSI standard TS 101 862 is the common profile for
issuing Qualified Certificates (QC).

TS 101862 defines how to comply with the European electronic signature
directive and RFC 3039 forms the base profile on which TS 101862 is
based.

RFC 3039, however is widely used also for non-QC where TS 101862 doesn't
apply.

This year ETSI initiated a work item (STF 220 Task 3) to further
harmonize public certificates issued to physical persons in Europe. The
deliverables are to:

-          Contribute to the update of RFC 3039

-          Update TS 101862

-          Generate new Technical Specification (TS 102 280) based on
the updated standards above.

The new standard TS 102280 is intended as a generic ID-certificate
profile recognized throughout EU CA:s and service providers.

A first draft of TS 102280 has been produced and can be obtained by me
upon request.

Updates to RFC 3039

As stated above, it is important to finalize son of RFC 3039 in order to
finalize TS 102280 within its time frame (publication in April 04)

STF 220 Task 3 has produced, as part of its work, input to the update of
RFC 3039 (included below) that has been circulated among CA:s and
application providers mainly in Europe.

Summary of updates are:

-          Various editorial updates of document scope and introductory
sections

-          Reference updates (e.g. changed RFC 2459 to RFC 3280)

-          domainComponent attribute added to subject field attribute
list

-          title attribute added to subject field attribute list

-          postalAddress removed from subject field attribute list

-          title removed from subjectDirectoryAttribute extension
attribute list

-          Key usage: Recommendation that NR SHOULD be exclusive if set
has been removed

-          Scope update of qcStatements extension

It is important to note that NO syntax changes has been made to the
document.

Further actions before producing RFC:

- finalize reference updates (X.509 is still old reference)

- Finalize ASN.1 parts (get new assigned numbers)

Recommendations from ETSI STF 220 Task 3

Following is the section 2 from the STF 220 Task 3 requirements
document. The whole document can be obtained from me upon request.

2   Recommendations on RFC 3039 updates 

As part of this task, STF will seek to influence the update of RFC 3039
to adapt the following changes:

2.1 Scope

RFC 3039 defines a number of aspects that are generic for both Qualified
Certificates as well as certificates to physical persons that are not
"Qualified". Examples are defined attributes, biometricInfo extension,
and aspects of the qcStatements extension. The scope of RFC 3039 should
be updated to more clearly reflect this reality, as well as other
proposed changes to the profile.

2.2 References

References need to be updated. E.g. from RFC 2459 to RFC 3280

2.3 Key usage

As a result of generalizing RFC 3039, the current requirement of having
non-repudiation exclusive if set, becomes too specific and cause
confusion in term of for which cases this applies and which cases it
does not. This has shown to diminish the use of other functions of RFC
3039 in certificates where RFC 3039 in general applies, but this
paragraph does not.

2.4 Subject field

The set of attributes should be updated.

postalAddress should be removed from the list of attributes in the
subject field and title attribute should be included and removed from
the subjectDirectoryAttributes extension.

PostalAddress is not supported by RFC 3280 for use in the subject field
and no records of its use in the subject field in public certificates,
as a distinguishing attribute, has been encountered. It is also a
structured attribute and therefore not appropriate for use as an RDN. 

Title on the other hand is frequently used. The common place to put this
attribute is in the subject field. Since we recommend against use of the
subjectDirectoryAttribute extension, the recommended location of the
title attribute should be in the subject field.

domainComponent attribute should be added to the list of distingushing
subject attributes. This attribute is commonly used in Subject field,
primary as alternative to Country and Organization.

2.5 qcStatements extension

The defined scope of this extension should be considered for update and
adaptation to its current and potential use.

The important thing is thus to preserve the syntax of the qcStatements
extension in order to secure backwards compatibility.