[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on Qualified Certificates draft
Sorry for the delay.
Comments in line,
Stefan Santesson wrote:
>
> Thank you for your comments,
>
> I have been busy for a while so forgive my late reply.
>
> I give some short comments in-line.
>
> At 06:32 PM 2/11/99 +0100, Juergen Walter wrote:
> >I would like to add some comments to the QC draft. The topics are the
> >following
> >
> >1) Properties of Qualified certificates,
> >2) CPS and the semantics of name fields,
> >3) countryName usage,
> >4) commonName
> >5) Security Considerations.
> >
> >Comments 1),2),4) are more or less editorial, while comments 3), 5) are
> >more general.
> >
> >1) Properties of Qualified Certificates
> >
> >"2.1 Properties
> >
> > A Qualified Certificate as defined in this standard is assumed to
> > have the following properties:
> >
> > - Issued by a CA that makes a public statement that the certificate
> > serves the purpose of a Qualified Certificate, as discussed in sec-
> > tion 2.3
> > - Indicate a certificate policy consistent with liabilities, prac-
> > tices and procedures undertaken by the CA, as discussed in 2.4
> > - Be issued to a natural person (living human being).
> > - Contain an unmistakable identity based on a pseudonym name or a
> > real name of the subject.
> > - Exclusively indicates non-repudiation key usage for the certified
> > public key.
> > - Fully complies with the certificate profile defined in RFC 2459"
> >[PKIX-QC]
> >
> >The last three properties should be replaced by
> > - Fully complies with the certificate profile defined in RFC 2459 and
> >chapter 3 of this document.
> >
>
> Actually it should be the other way around. The reference to rfc 2459
> should not be here. The meaning of this section is to say something about
> what makes a certificate a "Qualified Certificate". rfc 2459 and this
> profile does not make a certificate a "Qualified certificate" they are just
> a usable format for expressing them.
I beg to differ. This draft is part of PKIX work. Therefore, the
reference to rfc 2459 is necessary. In the context of PKIX the draft
should address when a PKIX profiled certificate becomes a qualified
certificate. The extensions in chapter 3 may be meaningless in the
context of other certificate profiles or definitions (eg EDIFACT).
Sure, you are free to define a qualified certificate independently of
the profile. But personally, I think this "abstract" definition has to
be tailored by the draft for PKIX purposes.
>
> >The profile of Qualified Certificates is defined in chapter 3 of
> >[PKIX-QC]. The fourth and fifth property do not cover the profile given
> >in chapter 3 completely.
> >
> >The security requirements defined in chapter 4 should be linked
> >explicitly. Therefore the following property should be added:
> >
> > - Issued by a CA in compliance with reasonable securitity measures
> >following the security considerations in chapter 4.
> >
> >
> >
> >2) CPS and the semantics of name fields
> >(subsection 3.1.1, last paragraph)
> >
> >"It should be noted, however, that a relying party MAY have to consult
> >identified certificate policies and/or the issuer's CPS, in order to
> >determine semantics of name fields and legal jurisdiction." [PKIX-QC]
> >
> >This paragraph should be moved to the introduction of chapter 3. Not
> >only the Issuer field (subsection 3.1.1) contains name fields but also
> >some of the remaining sections of chapter 3 contain name fields (e. g.
> >3.2.1. Subject Alternative Name). Then in addition, "name field" may be
> >replaced by "a particullary field" because this note applies to other
> >fields like placeOfBirth as well. So, "The manner in which the date of
> >birth is associated with the subject is outside the scope of this
> >document." may be avoidable. Such phrases can be found in various
> >sections.
> >
>
> I will think about this. I'm not so sure that your change does it more
> clear but you have a point.
>
> >
> >
> >3) countryName usage
> >
> >The field countryName is defined in subsection 3.1.2 and 3.2.1
> >respectively. At a first glance, it is a field associated to the
> >subject. But [PKIX-QC] says about usage in both subsections:
> >
> >"The countryName attribute value specifies a general context in which
> >other attributes are to be understood. The country attribute does not
> >necessarily match the subject's country of citizenship or country of
> >residence, nor does it have to match the country of issuance." (*)
> >
> >I am confused. [PKIX-QC] says "The givenName and surname attribute types
> >SHALL, if present, contain the registered name of the subject, depending
> >on the laws under which the CA prepares the certificate." Either this
> >contradicts the countryName usage specification (*) or the draft allows
> >that the general context (whatever this means) of other subject´s
> >attributes differ from which of the givenName and surname attribute. By
> >the way, there is a difference in meaning between "prepare" and "issue",
> >isn´t it?
> >
> >The countryName usage (*) should be replaced by the following:
> >
> >- The countryName attribute value contained in the ISSUER field
> >specifies a general context in which other attributes are to be
> >understood. It should be noted that, the optional attributeSemantics
> >value may specify variations for attributes contained in the
> >PersonalData field.
> >
> >- The countryName attribute value contained in the SUBJECT field SHALL
> >match one of subject´s countryOfCitizenship or countryOfResidence. The
> >value may be chosen by subject´s or CA´s preference.
> >
> >- The countryName attribute contained in the PersonalData field SHALL if
> >present coincide with the value in the SUBJECT field.
> >
> >Have I overseen some discussion about the countryName usage? Why should
> >a countryName different from subject´s countryOfCitizenship or
> >countryOfResidence have any relevance in Qualified Certificates?
> >
>
> Yes, this could be written more clear and you have some good suggestions.
> But I don't want to require that country SHALL match either citizenship or
> residence. I can't give a simple exact case right now but I'm sure there is
> one.
There should be at least one meaningful case within the PKIX framework.
If there is one then they may use the attributeSemantics.
> The idea is to let the country attribute be a dynamic country specifier
> used by any attributeSemantics value to give the context for various name
> properties. It could also give the country value for any specified
> registrationAuthority.
Provided that the general context of an attribute is not clear (ie it
differs from issuer´s countryName) I see the following cases
1) the attributeSemantics defines it,
2) the certificate policy/CPS gives guidance,
3) registration of new OIDs for the concerned attributes.
Just a thought. Is attributeSemantics really necessary? I tend to the
second case if applicable. Nevertheless, the combination of issuer´s
countryName and subject´s countryName should be sufficient in most
examples.
>
> We will look into this.
>
> >
> >
> >3) commonName
> >
> >In the 7th paragraph of subsection 3.1.2 [PKIX-QC]
> >
> >"To understand the nature of the name presented in commonName, complying
> >applications may have to examine present values of the givenName and
> >surname attributes and if necessary, the personal data field in the
> >subjectAltName extension."
> >
> >should be replaced by
> >
> >"To understand the nature of the name presented in commonName, complying
> >applications may have to examine present values of the givenName and
> >surname attributes contained in the personal data field of the
> >subjectAltName extension if necessary."
> >
> >The phrase applies to "Choice I" of subject field definition. Then the
> >fields givenName and surname are absent in the subject field even if
> >they may present in the PersonalData record of the subjectAltName field.
> >The conjunction "and if ..." is therefore misleading in the original
> >phrase.
> >
>
> There is nothing that says that givenName and surname are absent when
> commonName is present. The Choice I and II are only choices of mandatory
> attribute. All other attributes are optionally present.
Sorry, you are right. CHOICE was misleading :-). So, besides the surname
and givenName we have optionally commonName. Thanks for clarification.
>
> >4) Security Considerations
> >
> >[PKIX-QC, chapter 4] "Both the private key
> > holder as well as the relying party should make sure that the private
> > key is used only with the consent of the legitimate key holder and
> > only after the key holders conscious acceptance of the signed message
> > content."
> >
> >How could the relying party do this? This topic should be reformulated
> >in the following sense. On the one hand there are security requirements
> >according to the personal security environment; on the other hand there
> >are security requirements for certificate path validation.
> >
>
> Yes you are right. The relying party can never be "SURE". But he will have
> to have an opinion, consciously or not. By trusting the certificate in a
> non-repudiation service, the relying party also chooses to trust the
> signers signing system. This is what has to be made clear. We will rephrase
> it.
I beg to differ. I focus on the signing component of signer´s
cryptographic module. The signer must be sure he signs the data that he
wants to sign. The signer has to be responsible for this not the relying
party. On the other hand, the relying party must be sure that he gets
the correct signature verification result. In order to do this, he
trusts a CA. Other modells need clarification in my opinion.
Juergen
>
> >
> >I hope it helps.
> >
>
> It does. Thank you.
>
> >Juergen
> >
> >
>
> /Stefan
> -------------------------------------------------------------------
> Stefan Santesson <stefan@accurata.se>
> Accurata Systemsäkerhet AB
> Lotsgatan 27 D Tel. +46-40 152211
> 216 42 Malmö Fax. +46-40 150790
> Sweden Mobile +46-70 5247799
>
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------