Subject: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt

From: [email-masked]
Date: Tue, 20 Jan 2004 15:44:50 -0500

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-03.txt
	Pages		: 35
	Date		: 2004-1-20
	
This document forms a certificate profile, based on RFC 3280, for
   identity certificates issued to natural persons.

   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.

   The goal of this document is to define a certificate profile that
   supports issuance of Qualified Certificates independent of local
   legal requirements.  The profile is however not limited to Qualified
   Certificates and further profiling may facilitate specific local
   needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-03.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-03.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-sonof3039-03.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: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Jan 2004 19:25:16 -0800

Comments on this draft.

1.  Section 2, para 2:   
 	The text "where the certificate meet some qualification
requirements" should be changed to either "certificates meet" or
"certificate meets"  (grammer)

2.  You need to update your example certificate, the DOB is no longer
formed correctly.

3.  I suggest not including a nameRegistrationAuthority in the example
certificate to illistrate how a certificate complient to this document
is created.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Tuesday, January 20, 2004 12:45 PM
> To: IETF-Announce:
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-pkix-sonof3039-03.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
> http://www.ietf.org/internet-drafts/draft-> ietf-pkix-sonof3039-03.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

Send a message to:
	[email-masked].
In the body type:
	
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 26 Jan 2004 10:05:05 +0100

Stefan, Magnus and Tim,

Please find 38 comments on <draft-ietf-pkix-sonof3039-03.txt>

1. The text states:

    "The profile defines specific conventions for certificates that are
    qualified within a defined legal framework, named Qualified
    Certificates."

It is unclear what the topic of this document is about. This sentence does 
not explain. To illustrate the concern if we had the following sentence, it 
would be the same problem :

   "The profile defines specific conventions for certificates that are
    certified within a defined legal framework, named Certified
    Certificates."

What means qualified ? What would mean certified ?

Since the definition of a legal framework is outside the scope, it could be 
any kind of certificate as long as it is issued for a natural person, which 
is the only restriction advertised. Then why is it under a "legal framework" 
? It would be appropriate under any kind of certificate policy. The text 
should not place any emphasis on a "legal framework".

This document simply defines a profile of a certificate for natural persons.

The technical content of this document should be clearly advertised. 
Hereafter is a proposal, intended to be a full replacement of the second 
paragraph :

    “This document provides a profile for two fields: issuer and
    subject and for three certificate extensions: subject alternate
    name, subject directory attributes, and key usage. It also defines
    two extensions: biometric information and qualified certificate
    statements”.

2. The use of the wording "Qualified Certificate" is unfortunate since it 
creates a confusion with the same wording used in the European Directive on 
Electronic Signatures.

If the wording "qualified certificate" needs to be kept, a warning should be 
given in the abstract. In order to avoid readers to misunderstand what is a 
qualified certificate in the context of this document, the following 
sentence should be added:

"It should be noticed that the meaning of "Qualified Certificate" as used in 
this document is different from the same wording used in the European 
Directive on Electronic Signatures."

The European Directive on Electronic Signatures should be referenced in the 
informative reference section.

3. In section 1, 6 th paragraph, the text states:

    "It should be noted that this specification does not define the
    specific semantics of Qualified Certificates, and does not define the
    policies that should be used with them.  That is, this document
    defines what information should go into Qualified Certificates, but
    not what that information means.  A system that uses Qualified
    Certificates must define its own semantics for the information in
    Qualified Certificates.  It is expected that laws and corporate
    policies will make these definitions."

This is not true. The only semantics which is undefined is the semantics of 
specific Qualified Certificate Statements. Please delete.

4. The text states:

"This specification differs from RFC 3039 in the following basic areas:

       * Some editorial clarifications has been made to introductory
       sections to clarify that this profile is generally applicable to a
       broad type of certificates even if its prime purpose is to
       facilitate issuance of Qualified Certificates."

The abstract states :

" The profile is however not limited to Qualified Certificates and
   further profiling may facilitate specific local needs."

Since a Qualified Certificate is a profile limited to natural person, it is 
unclear to understand what this sentence means. Please delete.

5. The text states:

       * To better facilitate broad applicability of this profile some
       constraints on key usage settings in the key usage extension has
       been removed.

This "constraints" were a recommendation that is still true and is currently 
proposed to be included to answer to a "defect report" raised on key usage 
on X.509 / IS0 9594-8. It is likely that this constraint will be accepted. 
This explanation should be removed and the recommendation that is present in 
RFC 3039 should remain.

6. The text states:

       * A new qc-Statement reflecting this second version of the profile
       has been defined in Section 3.2.5.1

What about backwards compatibility ?
Has anybody used the predefined qcStatement-1 ? Until we got a confirmed no 
response, it is not possible to suppress the document (i.e. RFC 3039) which 
tells what it means. Otherwise, implementations based on RFC3039 will 
suddenly become invalid. If nobody has ever implemented the predefined 
qcStatement-1, then there would be no reason to support it in 3039bis.

7. The text states in section 2 , Requirements and Assumptions.

    "The term "Qualified Certificate" has been used by the European
    Commission to describe a certain type of certificates with specific
    relevance for European legislation.  This specification is intended
    to support this class of certificates, but its scope is not limited
    to this application.

    Within this standard the term "Qualified Certificate" is used
    generally, describing a certificate whose primary purpose is to
    identify a person with high level of assurance, where the certificate
    meet some qualification requirements defined by an applicable legal
    framework. The actual mechanisms that decide whether a certificate
    should or should not be considered to be a "Qualified Certificate" in
    regard to any legislation are outside the scope of this standard."

Full text proposal replacement:

    "The term "Qualified Certificate" is used by the European Directive
    on Electronic Signature to refer to specific type of certificate.
    The same term is used in this document with a different meaning,
    i.e. to define a profile of a certificate issued to natural persons,
    and which imposes constraints on the structure of the name of the
    subject and of the issuer."

8. The text states in section 2 , Requirements and Assumptions.

    "Harmonization in the field of identity certificates issued to natural
    persons, in particular Qualified Certificates, is essential within
    several aspects that fall outside the scope of RFC 3280."

This sentence is using the term "identity certificate" instead of "Qualified 
certificate". This is in fact much better and it is unfortunate to use the 
term "Qualified Certificate" everywhere within this document instead of 
"Identity certificate". This sentence should be deleted, since it is 
difficult to argue that harmonisation is essential without providing any reason.

9. The text states in section 2 , Requirements and Assumptions.

"The most important aspects that affect the scope of this specification
are:

    -  Definition of names and identity information in order to identify
       the associated subject in a uniform way."

What is the difference between a "name" and an "identity information" ?
Can a name identify a subject ? Not always.

Proposed rewording:

The most important aspects that affect the scope of this specification
are:

    -  Definition of attributes of the subject DN in order to name
       the associated subject in a uniform way."

10. The text states in section 2 , Requirements and Assumptions.

"The most important aspects that affect the scope of this specification
are:

    -  Definition of information which identifies the CA and the
       jurisdiction under which the CA operates when issuing a particular
       certificate.

Qualified certificates (as meant by this document) are supposed to be 
applicable for a "defined legal framework". What is the relationship with 
the "jurisdiction under which the CA operates" ?

Qualified certificates (as meant by the EU Directive) identify the country 
where the CA operates. While this has a well defined meaning, it seems 
rather difficult to give a meaning to this statement outside the EU Directive.

Proposed rewording:

"The most important aspects that affect the scope of this specification
are:

    -  Definition of information which identifies the country where
       the CA operates when issuing a certificate."

11. The text states in section 2 , Requirements and Assumptions.

"The most important aspects that affect the scope of this specification
are:

    -  Definition of a standardized way to store predefined statements
       with relevance for Qualified Certificates."

Delete: "with relevance for Qualified Certificates".

12. The text states in section 2.1 Properties:

    "This profile accommodates profiling needs for Qualified Certificates
    based on the assumptions that:

    -  Qualified Certificates are issued by a CA that makes a public
       statement that the certificate serves the purpose of a Qualified
       Certificate, as discussed in Section 2.2."

It is quite strange to mandate to make a public statement here.
Do we require a public statement when RFC 3280 compliant certificates
are issued ? To which of the sections would it mean compliance ?

Delete this item.

13. The text states in section 2.1 Properties:

    -  The Qualified Certificate indicates a certificate policy
       consistent with liabilities, practices and procedures undertaken
       by the CA, as discussed in Section 2.3."

There is no precise definition of such a certificate policy and precise 
definitions are outside the scope of the PKIX WG.

Delete this item.

14. The text states in section 2.1 Properties:

    -  The Qualified Certificate contains an identity based on a
       pseudonym or a real name of the subject.

No identity is ever contained in a certificate.

Proposed rewording:

    -  The Qualified Certificate contains a name which may be either
       based on the real name of the subject or a pseudonym."

15. The text states in section 2.2  Statement of Purpose

    "This profile defines two complementary ways to include this
    information:

    -  As information defined by a certificate policy included in the
       certificate policies extension, and

    -  As a statement included in the Qualified Certificates Statements
       extension."

As far as "EU Qualified Certificates" are concerned, the ways are not 
"complementary", but "alternative".

Since no CP OID is being defined in the document to indicate this "property" 
(which is quite vague), this cannot be supported.

Since no statement is being defined in the document to indicate this 
"property" (which is quite vague), this cannot be supported.

Please delete the whole section 2.2.

16. The text states in section 2.3  Policy Issues

    "Certain policy aspects define the context in which this profile is to
    be understood and used.  It is however outside the scope of this
    profile to specify any policies or legal aspects that will govern
    services that issue or utilize certificates according to this
    profile."

Is it necessary to say that some other documents (please keep away "policy 
aspects") whatever they are may use this document ? Isn't it the primary 
goal of any standard ?

Please delete this paragraph.

17. The text states in section 2.3  Policy Issues:

    "It is however an underlying assumption in this profile that a
    responsible issuing CA will undertake to follow a publicly available
    certificate policy that is consistent with its liabilities, practices
    and procedures."

This assumption is not valid. Nothing will force a CA to adopt a publicly 
available policy. Please delete this paragraph.

18. The text states in section 2.4  Uniqueness of names

    “ An
    object can be assigned a distinguished name without being represented
    by an entry in the Directory, but this name is then the name its
    object entry could have had if it were represented in the Directory.
    In the context of qualified certificates, a distinguished name
    denotes a set of attribute values [X.501] which forms a name that is
    unambiguous within a certain domain that forms either a real or a
    virtual DIT (Directory Information Tree)[X.501].  In the case of
    subject names the domain is assumed to be at least the issuing domain
    of the CA.

These sentences do not help to understand the issue of uniqueness of names. 
The fact that there is a real DIT or not is irrelevant. The notion of “a 
certain domain” and “at least the issuing domain” is hazardous. Please 
delete these sentences and keep the last sentence which is correct:

    “The distinguished name MUST be unique for each subject
    entity certified by the one CA as defined by the issuer name field,
    during the whole life time of the CA.”

19. The text states in section 3.1.1  Issuer

    “The identity of the issuer SHALL be specified using an appropriate
    subset of the following attributes:”

Please change “identity” by “DN”.

20. The text states in section 3.1.1 Issuer :

“Attributes present in the issuer field SHOULD be consistent with the laws 
under which the issuer operates.”

We do not reference laws in other documents, but Certificate Policies 
instead. Please refer to Certificate policies, and replace with:

“Attributes present in the issuer field SHOULD be consistent with the 
certificate policy of the certificate.”

21. The text states in section 3.1.1 Issuer :

    “A relying party MAY have to consult associated certificate policies
    and/or the issuer's CPS, in order to determine the semantics of name
    fields and the laws under which the issuer operates.”

Please delete the end of the sentence, i.e. “and the laws under which the 
issuer operates”. There is no reason to refer to laws.

22. The text states in section 3.1.2  Subject (page 8):

“   Other attributes may be present but MUST NOT be necessary to
    distinguish the subject name from other subject names within the
    issuer domain.”

This sentence is wrong. The DN is uniquely global with all the attributes 
present. Matching rules do not exclude some attributes. This sentence could 
be interpreted as if a name matching rule could be constructed using only 
these attributes and ignoring the additional ones. Please delete that sentence.

23. The text states in section 3.1.2  Subject (pages 8 and 9):

       “The surname and givenName attribute types SHALL, if present,
       contain the name of the subject, in accordance with the
       laws under which the CA prepares the certificate. These
       attributes SHALL be used in the subject field if the commonName
       attribute is not present. In cases where the subject only has a
       single name registered, the givenName attribute SHALL be used and
       the surname attribute SHALL be omitted.”

What is the “registered name” of the subject ? Who is registering the name ?
Which laws is it ? Is it the laws where the CA operates ? Do all countries 
have a law to say what is a registered name ? Please to not refer to 
“registered names” and national laws.

       “The surname and givenName attribute types SHALL be used in the
       subject field if the commonName attribute is not present. In
       cases where the subject only has a givenName the surname attribute
       SHALL be omitted.”

24. The text states in section 3.2  Certificate Extensions:

    “This specification provides additional details regarding the contents
    of five certificate extensions: Subject directory attributes,
    Certificate policies, Key usage, Biometric information and Qualified
    Certificate statements.”

This is not correct. It is not “details regarding the content of five 
certificate extensions”, but a profile for two basic fields, three existing 
extensions and the definition of two new extensions.

Change with:

    “This specification provides profiles for two fields: issuer and
    subject and for three certificate extensions: subject alternate
    name, subject directory attributes, and key usage. It also defines
    two extensions: biometric information and qualified certificate
    statements.”

25. The text defines in section 3.2.1  Subject Directory Attributes. Why is 
there no specification at all for the Subject Alternative Name ?

There should be a section saying that Internet electronic mail addresses 
SHALL be placed there, if e-mail addresses need to be present.

26. The text states in section 3.2.2 Certificate Policies:

    “Information provided by the issuer stating the purpose of the
    certificate as discussed in Section 2.2 SHOULD be evident through
    indicated policies.”

It is not evident from an OID to know what the certificate policy is about.
Since section 2.2 should be deleted, this sentence should be deleted as well.

27. The text states in section 3.2.2 Certificate Policies:

    “The certificate policies extension SHOULD include all policy
    information needed for validation of the certificate.”

The Certificate Policies extensions defines everything that is needed. There 
is nothing to be added here. Please delete that sentence.

28. The text states in section 3.2.2 Certificate Policies:

    “If policy information is included in the QCStatements extension
    (see 3.2.5), then this information SHOULD also be defined by
    indicated policies.”

QCStatements extension is still not described at this place when reading the 
document in sequence. This sentence is not relevant and could even be 
misleading: QCStatements is not a direct alternative to a certificate 
policy. It may indicate a conformity with a document where some parts of it 
may be translated into a certificate policy. Please delete that sentence.

29. It is very questionable why there should be a section 3.2.2 at all. 
There is no additional specific constraints beyond what already exists in 
RFC 3280. Please delete the whole section 3.2.2.

30. The text states in section 3.2.3  Key Usage:

    “The key usage extension SHALL be present. Key usage settings SHALL be
    set in accordance with RFC 3280 definitions. Further requirements on
    key usage settings MAY be defined by local policy and/or local legal
    requirements.”

The security consideration section states:

    “Combining the nonRepudiation bit in the keyUsage certificate
    extension with other keyUsage bits may have security implications and
    this specification therefore recommends against such practices.”

This is quite true. However the main body of the document is lacking this 
recommendation. The text that is currently in RFC 3039 should stay. It 
should be adapted to avoid naming bit 1 as nonRepudiation since it is likely 
that the name of that bit will be changed by ISO. So speaking of bit 1 is 
neutral and will be valid whatever the final name will be.

Please replace with:

    The key usage extension SHALL be present.  If the key usage bit 1
    is asserted then it SHOULD NOT be combined with any other key usage,
    i.e., if set, it SHOULD be set exclusively (see the security
    considerations section).

31. The text states in section 3.2.3  Key Usage:

    “The key usage extension MAY be marked critical.”

However, RFC 3280 states:

    “When this extension appears, it SHOULD be marked critical.”

The “MAY” should be changed into “SHOULD”.

This leads to:

    “The key usage extension SHOULD be marked critical.”

32. The text states in section 3.2.5  Qualified Certificate Statements:

    “A statement suitable for inclusion in this extension MAY be a
    statement by the issuer that the certificate is issued as a Qualified
    Certificate in accordance with a particular legal system (as
    discussed in Section 2.2).”

Providing examples before the actual definition of what is this extension is 
not appropriate. It should also be avoided to speak about “legal systems”. 
Please delete.

33. The text states in section 3.2.5  Qualified Certificate Statements:

    “Other statements suitable for inclusion in this extension MAY be
    statements related to the applicable legal jurisdiction within which
    the certificate is issued.  As an example this MAY include a maximum
    reliance limit for the certificate indicating restrictions on CA's
    liability.”

Providing examples before the actual definition of what is this extension is 
not appropriate. It should also be avoided to speak about “legal 
jurisdiction”. Please delete.

34. The text states in section 3.2.5  Qualified Certificate Statements:

    “This extension may be critical or non-critical.  If the extension is
    critical, this means that all statements included in the extension
    are regarded as critical.”

A note should be added after the ASN.1 description :

“NOTE: This extension does not allow to mix critical and non-critical 
Qualified Certificate Statements. Either all statements must be critical or 
all statements must be non-critical.”

35. The text states in section 3.2.5.1 Predefined Statements:

    “RFC 3039 defined one qualified certificate statement (id-qcs-
    pkixQCSyntax-v1), identifying conformance with syntax and semantics
    defined in RFC 3039.”

What means conformance with syntax and semantics ? Conformance clauses means 
that the SHALL statements have to be observed by the CA. From which sections 
should the SHALL statements be observed ? The document provides a profile 
for two fields: issuer and subject, for one mandatory certificate 
extensions: key usage and for two optional certificate extensions: subject 
alternate name and subject directory attributes.

It means conformance with sections 3.1.1. Issuer, 3.1.2 subject, 3.2.3
key usage; if subject directory attributes is present, with section
3.2.1.; and if subject alternate name attribute is present, with
section 3.2.X.

There is however a major problem: if RFC3039 is withdrawn, then there would 
be no text to say what it means. So RFC 3039 cannot be withdrawn without 
knowing first if someone as ever implemented id-qcs-pkixQCSyntax-v1.

36. The text states in section 3.2.5.1 Predefined Statements:

    “This profile includes a new qualified certificate statement
    (identified by the OID id-qcs-pkixQCSyntax-v2), identifying
    conformance with syntax and semantics defined in this profile.”

The sentence should be corrected in the following way:

    “This profile includes a qualified certificate statement
    (identified by the OID id-qcs-pkixQCSyntax-v2), identifying
    conformance with sections 3.1.1. Issuer, 3.1.2 subject, 3.2.3 key
    usage ; if subject directory attributes is present, with section
    3.2.1.; and if subject alternate name attribute is present, with
    section 3.2.X.

37. The text states in section 3.2.5.1 Predefined Statements:

    “This Qualified Certificate profile is referred to as version 2
    while RFC 3039 is referred to as version 1.”

This sentence cannot stay and will need to be fixed. See comment 35.

38. The European Directive on Electronic Signatures should be referenced in 
the informative references section (section 5.2).

END OF COMMENTS

Denis

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Jan 2004 11:34:03 -0500

Denis:

I have just requested IETF Last Call on this document.  I will treat these 
comments as the first Last Call comments.

Russ

At 10:05 AM 1/26/2004 +0100, Denis Pinkas wrote:

>not explain. To illustrate the concern if we had the following sentence, 
>it would be the same problem :
>
>Since the definition of a legal framework is outside the scope, it could 
>be any kind of certificate as long as it is issued for a natural person, 
>which is the only restriction advertised. Then why is it under a "legal 
>framework" ? It would be appropriate under any kind of certificate policy. 
>The text should not place any emphasis on a "legal framework".
>
>    "This document provides a profile for two fields: issuer and
>    statements".
>creates a confusion with the same wording used in the European Directive 
>on Electronic Signatures.
>
>If the wording "qualified certificate" needs to be kept, a warning should 
>be given in the abstract. In order to avoid readers to misunderstand what 
>is a qualified certificate in the context of this document, the following 
>"It should be noticed that the meaning of "Qualified Certificate" as used 
>in this document is different from the same wording used in the European 
>The European Directive on Electronic Signatures should be referenced in 
>the informative reference section.
>
>
>This is not true. The only semantics which is undefined is the semantics 
>of specific Qualified Certificate Statements. Please delete.
>
>
>4. The text states:
>
>Since a Qualified Certificate is a profile limited to natural person, it 
>is unclear to understand what this sentence means. Please delete.
>
>
>5. The text states:
>
>This "constraints" were a recommendation that is still true and is 
>currently proposed to be included to answer to a "defect report" raised on 
>key usage on X.509 / IS0 9594-8. It is likely that this constraint will be 
>accepted. This explanation should be removed and the recommendation that 
>is present in RFC 3039 should remain.
>
>
>6. The text states:
>
>Has anybody used the predefined qcStatement-1 ? Until we got a confirmed 
>no response, it is not possible to suppress the document (i.e. RFC 3039) 
>which tells what it means. Otherwise, implementations based on RFC3039 
>will suddenly become invalid. If nobody has ever implemented the 
>predefined qcStatement-1, then there would be no reason to support it in 
>3039bis.
>
>
>This sentence is using the term "identity certificate" instead of 
>"Qualified certificate". This is in fact much better and it is unfortunate 
>to use the term "Qualified Certificate" everywhere within this document 
>instead of "Identity certificate". This sentence should be deleted, since 
>it is difficult to argue that harmonisation is essential without providing 
>any reason.
>
>
>Since no CP OID is being defined in the document to indicate this 
>    " An
>These sentences do not help to understand the issue of uniqueness of 
>names. The fact that there is a real DIT or not is irrelevant. The notion 
>of "a certain domain" and "at least the issuing domain" is hazardous. 
>Please delete these sentences and keep the last sentence which is correct:
>
>    "The distinguished name MUST be unique for each subject
>    during the whole life time of the CA."
>
>
>    "The identity of the issuer SHALL be specified using an appropriate
>    subset of the following attributes:"
>
>Please change "identity" by "DN".
>
>
>"Attributes present in the issuer field SHOULD be consistent with the laws 
>under which the issuer operates."
>
>"Attributes present in the issuer field SHOULD be consistent with the 
>certificate policy of the certificate."
>
>
>    "A relying party MAY have to consult associated certificate policies
>    fields and the laws under which the issuer operates."
>
>Please delete the end of the sentence, i.e. "and the laws under which the 
>issuer operates". There is no reason to refer to laws.
>
>
>"   Other attributes may be present but MUST NOT be necessary to
>    issuer domain."
>present. Matching rules do not exclude some attributes. This sentence 
>could be interpreted as if a name matching rule could be constructed using 
>only these attributes and ignoring the additional ones. Please delete that 
>sentence.
>
>
>       "The surname and givenName attribute types SHALL, if present,
>       the surname attribute SHALL be omitted."
>
>What is the "registered name" of the subject ? Who is registering the name ?
>"registered names" and national laws.
>
>       "The surname and givenName attribute types SHALL be used in the
>       SHALL be omitted."
>    "This specification provides additional details regarding the contents
>    Certificate statements."
>This is not correct. It is not "details regarding the content of five 
>certificate extensions", but a profile for two basic fields, three 
>existing extensions and the definition of two new extensions.
>
>Change with:
>
>    "This specification provides profiles for two fields: issuer and
>    statements."
>25. The text defines in section 3.2.1  Subject Directory Attributes. Why 
>is there no specification at all for the Subject Alternative Name ?
>
>    "Information provided by the issuer stating the purpose of the
>    indicated policies."
>    "The certificate policies extension SHOULD include all policy
>    information needed for validation of the certificate."
>
>The Certificate Policies extensions defines everything that is needed. 
>There is nothing to be added here. Please delete that sentence.
>
>    "If policy information is included in the QCStatements extension
>    indicated policies."
>QCStatements extension is still not described at this place when reading 
>the document in sequence. This sentence is not relevant and could even be 
>policy. It may indicate a conformity with a document where some parts of 
>it may be translated into a certificate policy. Please delete that sentence.
>
>
>    "The key usage extension SHALL be present. Key usage settings SHALL be
>    requirements."
>    "Combining the nonRepudiation bit in the keyUsage certificate
>    this specification therefore recommends against such practices."
>
>should be adapted to avoid naming bit 1 as nonRepudiation since it is 
>likely that the name of that bit will be changed by ISO. So speaking of 
>bit 1 is neutral and will be valid whatever the final name will be.
>
>Please replace with:
>
>    "The key usage extension MAY be marked critical."
>
>    "When this extension appears, it SHOULD be marked critical."
>
>The "MAY" should be changed into "SHOULD".
>
>This leads to:
>
>    "The key usage extension SHOULD be marked critical."
>
>
>    "A statement suitable for inclusion in this extension MAY be a
>    discussed in Section 2.2)."
>
>Providing examples before the actual definition of what is this extension 
>is not appropriate. It should also be avoided to speak about "legal 
>systems". Please delete.
>
>
>    "Other statements suitable for inclusion in this extension MAY be
>    liability."
>Providing examples before the actual definition of what is this extension 
>is not appropriate. It should also be avoided to speak about "legal 
>jurisdiction". Please delete.
>
>
>    "This extension may be critical or non-critical.  If the extension is
>    are regarded as critical."
>
>"NOTE: This extension does not allow to mix critical and non-critical 
>Qualified Certificate Statements. Either all statements must be critical 
>or all statements must be non-critical."
>
>
>    "RFC 3039 defined one qualified certificate statement (id-qcs-
>    defined in RFC 3039."
>What means conformance with syntax and semantics ? Conformance clauses 
>means that the SHALL statements have to be observed by the CA. From which 
>sections should the SHALL statements be observed ? The document provides a 
>profile for two fields: issuer and subject, for one mandatory certificate 
>There is however a major problem: if RFC3039 is withdrawn, then there 
>would be no text to say what it means. So RFC 3039 cannot be withdrawn 
>without knowing first if someone as ever implemented id-qcs-pkixQCSyntax-v1.
>
>
>    "This profile includes a new qualified certificate statement
>    conformance with syntax and semantics defined in this profile."
>
>    "This profile includes a qualified certificate statement
>    "This Qualified Certificate profile is referred to as version 2
>    while RFC 3039 is referred to as version 1."
>
>38. The European Directive on Electronic Signatures should be referenced 
>in the informative references section (section 5.2).
>
>END OF COMMENTS
>
>Denis
>
>
>>http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>