RE: Qualified Certificates and the 43:d IETF Meeting

[Stefan Santesson <stefan@xxxxxxxxxxx>]

Nick,

Thank you for the review.

I'll provide some comments in line.

At 07:58 PM 12/2/98 -0000, secstan wrote:
>Stefan,
>
>I still have major concerns over this draft in that the naming attributes
>used in the subject and issuer are not those used in conventional directory
>"distinguished names".  Whilst I recognise that LDAP / X.500 directories are
>only one possible means of distributing certificates, the use of qualified
>certificates should not make it difficult to use directories for
>distributing certificates.
>
>The changes made has moved in the right direction but more could be done to
>facilitate a common approach.
>
>More specifically:
>
>1) In 3.1.2, instead of Choice II using surname and firstname, conventions
>could be defined for carrying this information in Common Name
>(e.g. CommonName =<firstname> <surname>)

This is allready the case. There is full freedom to put your complete name
in the commonName. There is however no restrictions on how the names are
stored, in what order or if nicknames or pseudonym names are used. To
understand the common name fully, one have to consult other information
objects.

>
>2)The standard attribute dnQualifier could be used instead of serialNumber
>(Th attribute "serialNumber is defined in RFC 2256 as being the serial
>number of a device).
>

Yes, the SN is not in complete harmony regarding its definition and its
use. However several other standardisation proposal has choosen SN for
personal identifiers. The rationale behind that choice have been that most
applications support and displays this attribute in a correct way.

Is there an installed base using "dnQualifier" ?

This matter should be discussed further before settled.

>3) postalAddress is more appropriate as an additional subjectAttribute (see
>next comment) rather than a naming attribute.

It wouldn't hurt me personally to remove it but I'm not sure that it should
be removed. The thought behind this is that in some countries and
situations it could be considered valid to construct an unmistakable
identity from either;

name, organisation, adress  or;
name, adress

I would like to keep it for some more time until we are convinced that it
is not used in any valid circumstance.

>
>4) In 3.2.1 it is suggested that the structure PersonalData is added to
>SubjectAltName.
>This doesn't fit in with the standard syntax which defines this as being
>GeneralName
>(see PKIX part 1).

I don't see the problem. GeneralName includes otherName of the type
AnotherName which in turn has the following definition:

AnotherName ::= SEQUENCE {
     type-id    OBJECT IDENTIFIER,
     value      [0] EXPLICIT ANY DEFINED BY type-id }


>
>The Subject Directory Attributes provides a structure which can be used to
>carry the additional information about the subject in a way which fits in
>with existing standards.

I disagree.

I personally find the subjectAltName extension to be mor in line with part
1. An further, these information elements are in fact naming information
and not directory attributes.

>
>Hope this helps.
>
>Nick Pope
>

It has.

/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
-------------------------------------------------------------------