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

From: Denis Pinkas <[email-masked]>
Date: Mon, 23 Feb 2004 14:45:09 +0100

Stefan,

Let us go for the good news first. Out of the 38 initial comments,
14 are solved, accepted or agreed. They have the following numbers:
3, 8, 11, 12, 14, 17, 18, 19, 20, 21, 23, 29, 31, 38.

The bad news is that 24 are not yet solved.

I will prepare responses to these 23 comments.

Denis

> Denis,
> 
>  
> 
> Excuse me for taking a while to respond but you gave me quite a piece to 
> work on :-).
> 
>  
> 
> So, here is the response and suggested resolutions (in-line below).
> 
> Quite a few of your comments have resulted in change proposals, while 
> others haven?t (as it usually is).
> 
>  
> 
> But I hope you will find the response below reasonable.
> 
>  
> 
> Thanks for your extensive efforts in challenging the document.
> 
>  
> 
> /Stefan
> 
>  
> 
>  
> 
> -----Original Message-----
> 
> From: Denis Pinkas [mailto:[email-masked]]
> 
> Sent: den 26 januari 2004 10:05
> 
> To: Stefan Santesson; Tim Polk; Magnus Nystrom
> 
> Cc: [email-masked]
> 
> Subject: Re: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
> 
>  
> 
> 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?.
> 
>  
> 
>  
> 
> Reply
> 
> This has been debated before and the conclusion for this standard is 
> that this standard should remain its name and connection to the 
> Qualified Certificate concept. This is a technical standard and not a 
> legal standard. The term Qualified Certificates and the way it is used 
> in this standard gives a reasonable background and justification for the 
> provided technical specifications in section 3.
> 
>  
> 
> This standard does not make legal definitions and does not reference any 
> specific legal framework as source of requirements but it is the 
> editors? conclusion that it is appropriate to informatively talk about 
> legal frameworks as a general source or requirements that effects 
> practical implementations. This was also done in RFC 3039 with your consent.
> 
>  
> 
> The text you provide is handled in Comment 24.
> 
>  
> 
> Proposed resolution:
> 
> No action in the abstract. Proposed text is handled under comment 24
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> The WG has discussed and decided to keep the term ?Qualified Certificate?.
> 
> I agree with the inclusion of the reference; however, the rest would 
> seem to mislead the reader.  The Directive is used as an example of 
> local legal documentation
> 
>  
> 
> Proposed resolution:
> 
> Include Reference to Directive in the 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.
> 
>  
> 
> Reply
> 
> This is an old text from RFC 3039 that I don?t mind deleting. It was 
> formulated by Paul Hoffman who strongly believed that this clarification 
> was needed. This was done in an early state of the RFC 3039 process and 
> I don?t think it is relevant anymore given its current form. Unless Paul 
> comes forth and objects strenuously, I agree to delete.
> 
>  
> 
> Proposed resolution:
> 
> Delete sentence
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> This is just informative text and not part of any normative definitions. 
> As such it is a relevant description of changes made to the document.
> 
>  
> 
> Proposed resolution:
> 
> No action
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> This particular issue has been discussed and concluded in the WG. The 
> statement made in RFC 3039 is good practice in many situations but it 
> isn?t a general truth. There is no context in RFC 3039 to make such 
> statement and therefore it has been moved to ETSI TS 102 280 where there 
> is an applicable context for this recommendation. AFAIK you have never 
> argued against this, just maintained your position out of principles.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> This has been fixed in draft 04 where it is clearly defined that 
> reference to RFC 3039 is deprecated for new certificates.
> 
>  
> 
> Proposed resolution:
> 
> No change (fixed in draft 04)
> 
>  
> 
>  
> 
> 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."
> 
>  
> 
> Reply
> 
> The first part of your replacement text is good, the rest is misleading. 
> The use of Qualified Certificate is used to describe the same thing in 
> both documents, just in different contexts, not with different meaning.
> 
>  
> 
> Proposed resolution:
> 
> Change first section to:
> 
> "The term "Qualified Certificate" is used by the European Directive
> 
>  on Electronic Signature [EU-SIGDIR] to refer to a specific type of
> 
>  certificates, with appliance in European electronic signature
> 
>  legislation. This specification is intended to support this class of
> 
>  certificates, but its scope is not limited to this application.?
> 
>  
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> This text formulates a valid assumption that help defines the scope of 
> the standard. No reason to delete.
> 
>  
> 
> Proposed resolution:
> 
> No action
> 
>  
> 
>  
> 
> 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."
> 
>  
> 
> Reply
> 
> Your clarification does not help. ?Denis Pinkas? is a name. Your place 
> of birth is not a name but still identity information. Some attributes 
> does not need to be part of the Subject DN.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 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."
> 
>  
> 
> Reply
> 
> This is wrong. Country is not the only relevant denominator. State in US 
> can be equally relevant. The definitions in the context of the EU 
> context of this is handled in TS 101 862 where your issues already is 
> addressed. This standard gives the generic framework and is correct as 
> it is.
> 
>  
> 
> Proposed resolution:
> 
> No change.
> 
>  
> 
>  
> 
> 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".
> 
>  
> 
> Reply
> 
> No, this has relevance for Qualified Certificates. This approach is also 
> used in the EU profile TS 101 862.
> 
>  
> 
> Proposed resolution:
> 
> No change.
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> This is not stated as a requirement. This is stated as an assumption. 
> However I agree to remove the term ?public?.
> 
>  
> 
> Proposed resolution:
> 
> Keep text but remove ?public?.
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> This standard provides directions of the use of certificate policies in 
> relation to qcStatement extension. This text is listed as one of the 
> justifying assumptions and is this relevant.
> 
>  
> 
> Proposed resolution:
> 
> No action
> 
>  
> 
>  
> 
> 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."
> 
>  
> 
> Reply
> 
> Yes this is a good suggestion.
> 
>  
> 
> Proposed resolution:
> 
> Change text as proposed.
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> You are wrong here. The ways defined in TS 101 862 are complementary. 
> They are definitely not mutually exclusive. In fact the latest draft 
> strongly recommends both to be used at the same time since they serve 
> different purposes. Policy is the only mechanism that serves path 
> validation while the qcStatement supports programmatic detection of a QC 
> regardless of policy.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> This is a relevant part of the informative section 2. It is correct and 
> deleting it does not improve the standard. Note also that you previously 
> have agreed to this text in the RFC 3039 process.
> 
>  
> 
> Proposed resolution:
> 
> No change.
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> Agree to delete ?publicly available?, but the rest is relevant. Again 
> this is not a requirement section, just a list of scoping assumptions 
> justifying the profiling work in this standard.
> 
>  
> 
> Proposed resolution:
> 
> Remove ?publicly available?.
> 
>  
> 
>  
> 
> 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.?
> 
>  
> 
> Reply
> 
> This was one of those texts that when through a lot of discussion and 
> changes in RFC 3039 before it ended up this way. This is why I didn?t 
> touch it. However, I agree to the change unless someone comes fourth and 
> motivates why the old text should be kept.
> 
>  
> 
> Proposed resolution:
> 
> Change as proposed.
> 
>  
> 
>  
> 
> 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?.
> 
>  
> 
> Reply
> 
> OK
> 
>  
> 
> Proposed resolution:
> 
> Change as proposed.
> 
>  
> 
>  
> 
> 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.?
> 
>  
> 
> Reply
> 
> Agree with your concern but not your proposed change. This statement is 
> redundant and handled in regional profiling where legal context can be 
> defined and referenced.
> 
>  
> 
> Proposed resolution:
> 
> Delete this sentence.
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> OK
> 
>  
> 
> Proposed resolution:
> 
> Delete as proposed
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> The sentence still defines an important requirement that name uniqueness 
> must be maintained through these attributes. All relevant identity 
> matching scenarios aren?t limited to matching rules. However, 
> improvement suggested.
> 
>  
> 
> Proposed resolution:
> 
> New text.
> 
> ?Other attributes MAY also be present; however, the use of other
> 
> attributes MUST NOT be necessary to distinguish one subject
> 
> name from another subject names.  That is, the attributes listed
> 
> above are sufficient to ensure unique subject names.?
> 
>  
> 
>  
> 
> 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.?
> 
>  
> 
> Reply
> 
> Yes, your text is better. However there is an old error here that is 
> see, which you don?t address. givenName SHALL be used if neither 
> commonName nor PSEUDONYM is present. Update your text with that
> 
>  
> 
> Proposed resolution:
> 
> Change to:
> 
> ?The surname and givenName attribute types SHALL be used in the
> 
> subject field if neither the commonName attribute nor the pseudonym
> 
> attribute is 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.?
> 
>  
> 
> Reply
> 
> The current text is not wrong but it can be made better.
> 
> You proposed text is however wrong because the new extensions are also 
> extensions. A new text is proposed also in response to comment 1.
> 
>  
> 
> We are not in agreement about deleting the policy extension but we are 
> in agreement with adding a subjectAltName extension section (see next 
> comment)
> 
>  
> 
> Proposed resolution:
> 
> ?This specification provides profiles for two certificate fields:
> 
> issuer and subject; it also provides profiles for four certificate
> 
> extensions defined in RFC 3280: subject alternate name, subject 
> directory attributes, certificate policies and key usage. This 
> specification defines two additional 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.
> 
>  
> 
> Reply
> 
> Yes there should be a section for subjectAltName but not stating 
> anything about e-mail address. That is all handled in RFC 3280 and there 
> is no context defined in this standard where it is applicable to state 
> any further requirements. It is however relevant to make a short note 
> that placement of a DN in directoryName must follow the rules defined in 
> section 3.1.2.
> 
>  
> 
> Proposed resolution:
> 
> New section inserted.
> 
>  
> 
> ?3.2.1  Subject Alternative Name
> 
>  
> 
>     If the subjectAltName extension is present and it contains a
> 
>     directoryName name, then the directoryName MUST follow the
> 
>     conventions specified in section 3.1.2 of this profile.?
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> Since section 2.2 should be kept this should be kept as well. An OID 
> defines unambiguously a policy. If you know the policy then it is 
> evident from the OID what the policy is about.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> The text is true but unclear. Propose new text rather than deletion. The 
> text is relevant to understand the relation between policy and use of 
> qcStatement.
> 
>  
> 
> Proposed resolution:
> 
> The certificate policies extension MUST include all policy information 
> needed for certification path validation.
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> This text is relevant. It has previously proved to be relevant in the 
> update of TS 101 862 where we conclude that making qcStatements does not 
> free you from the obligatin to have a suitable policy that is sufficient 
> in its own. This also clarifies that qcStatement is NOT another form of 
> policy qualifier.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> No, as described in previous comments.
> 
>  
> 
> Proposed resolution:
> 
> No change.
> 
>  
> 
>  
> 
> 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).
> 
>  
> 
> Reply
> 
> We have been through this in the WG and also in previous comments. No 
> change.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 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.?
> 
>  
> 
> Reply
> 
> Correct.
> 
>  
> 
> Proposed resolution:
> 
> Change as proposed.
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> These are appropriate examples, reflecting real profiling work in ETSI 
> TS 101 862.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> These are appropriate examples, reflecting real profiling work in ETSI 
> TS 101 862.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 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.?
> 
>  
> 
> Reply
> 
> OK to add as ASN.1 comment
> 
>  
> 
> Proposed resolution:
> 
> Add Comment as ASN.1 comment text
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> If changed it?s then easier to just state compliance with section 3. 
> Section 3 contains all requirements.
> 
>  
> 
> Otherwise text regarding this is clarified in 04. It is relevant to 
> remain definition of the v1 OID but it is not to be included in new 
> certificates according to this profile.
> 
>  
> 
> Proposed resolution:
> 
> Replace ?syntax and semantics? with ?section 3?
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> Same reply as comment 35
> 
>  
> 
> Proposed resolution:
> 
> Fixed in accordance with comment 35
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> Reply
> 
> Fixed in draft 04
> 
>  
> 
> Proposed resolution:
> 
> No change to draft 04
> 
>  
> 
>  
> 
> 38. The European Directive on Electronic Signatures should be referenced in
> 
> the informative references section (section 5.2).
> 
>  
> 
> Reply
> 
> Agree
> 
>  
> 
> Proposed resolution:
> 
> Add Reference to directive (also stated in comment 2)
> 
>  
> 
>  
> 
>  
>