Subject: RE: Straw Poll: SerialNumber definition

From: Bengt Ohlsson <[email-masked]>
Date: Thu, 24 Feb 2000 09:10:13 +0100

Stefan,

I think there is an even simpler solution to the problem
by using the SubjectAltName extension. Just take those
RDNs that are required to make the name unique and
use those RDNs as a directoryName entry in the
SubjectAltName extension. E.g. if the serialNumber 
attribute is unique by itself, then the SubjectAltName
entry will only contain the serialNumber. This also allows
for a QC to contain different forms of unique names for
the same subject.

This will not affect any existing applications, since no
new attributes are instroduced. New applications that
will use QC can use the SubjectAltName extension to
find a name that is usable for the application.

/Bengt

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: den 24 februari 2000 01:16
To: 'David P. Kemp'; [email-masked]; [email-masked]
Subject: RE: Straw Poll: SerialNumber definition

David,

Your proposal seams like a nice, simple and reasonable solution.
Lets see if it can gain support from the critical eyes on this list. If so
then I can live with it.

-----
Caution Note to those participating in this thread: Please avoid cross
postings to other lists (such as SEIS and EL-SIGN) since it gets rather
nasty when people make "reply to all" on the postings. I have already got
complaints from people on the EL-SIGN list. So when replying to these
postings, please remove other lists from the recipient header.

/Stefan

> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Wednesday, February 23, 2000 11:03 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Straw Poll: SerialNumber definition
>
>
>
> > From: Denis Pinkas <[email-masked]>
> >
> > The solution to use the certPolicy OID proposed by Steve would not
> > work for an automated processing.
> > The solution proposed by Stefan would work, but I have something
> > simpler (but less flexible) that could possibly work.
>
> Simpler is better. :-)
>
>
> > The idea is that the *relative* placement of the UI in the DN chain
> > indicates to what it applies. In other words it serves like a
> > delimiter. Everything on the left of the delimiter has to be used to
> > make the name unique and permanent, for the given CA. If it comes
> > first, then it is self-sufficient by itself (e.g. it could be a
> > social security number or an employee number). In the following
> > example, it would only apply to G, I and S but not to O.
> >
> > G=; I=; S=; UI= ; O=;
> >
> > What do you think ?
>
>
> This solution presupposes that X.509 DNs do not have a one-to-one
> correspondence with the directory tree.  The last time a
> similar scheme
> came up in this thread, it was remarked that there is/should-be a
> direct mapping between the entire X.509 Distinguished Name and the
> directory. The two certs:
>
>   (1)   CN=; SN=; OU=; O=; C=;
>   (2)   CN= + SN=; OU=; O=; C=;
>
> would be stored as follows in the DIT:
>
>           (1)                       (2)
>
>            C                         C
>           / \                       / \
>          O   O                     O   O
>         / |  | \                  / |  | \
>        OU                        OU
>       /  \                      /  \
>      SN                      SN+CN
>      |
>      CN
>
> The problem with cert (1) is that it creates an additional layer
> in the directory where each SN node has only a single child.  The
> problem with cert (2) is that it does not specify whether the value
> of CN is a significant part of the subject's identity or just a
> human-readable comment.
>
> If a "delimiter" UI attribute were defined, cert (1) could have five
> single-AT&V RDNs but still be stored in a four-level
> directory structure:
>
>                               (1)
>
>                                C
>                               / \
>                              O   O
>                             / |  | \
>                            OU
>                           /  \
>            delimiter ->  UI
>  (remainder of DN is
>  just human-readable
>  information)
>
>
> Stefan previously suggested five alternatives for the static
> identifier, each of which had advantages and disadvantages.  At that
> time the creation of a new RDN attribute was deemed less
> desirable than
> using the existing SN attribute.  I don't believe the
> situation leading
> to that decision has changed.
>
> However, Stefan's suggestion to use a dnIdentityMask contained in
> the QC Statements extension can be simplified along the lines
> suggested
> by Denis and Peter Sylvester without requiring a new RDN attribute.
> All that is needed is a boolean signal indicating if the SN attribute
> is to be treated as a delimiter.  If TRUE, all subsequent RDNs and any
> additional AT&Vs in the current RDN are treated as comments, not part
> of the "DN Identity" or directory structure.  If absent or FALSE, the
> SN attribute is not treated as a delimiter.
>
> The form of the signal is immaterial. I believe it can be contained
> implicitly within Cert Policies OIDs, Anders believes an explicit
> signal is necessary; both views can be accommodated by defining an
> optional boolean field somewhere within the QC Statements extension.
>
> As an example, one could replace Stefan's
>
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL
> >           dnIdentityMask              DnIdentityMask   OPTIONAL}
> >
> >           DnIdentityMask ::= BIT STRING {
> >                countryName             (0),
> >                commonName              (1),
> >                surname                 (2),
> >                givenName               (3),
> >                pseudonym               (4),
> >                serialNumber            (5),
> >                organizationName        (6),
> >                organizationalUnitName  (7),
> >                stateOrProvinceName     (8),
> >                localityName            (9),
> >                postalAddress          (10)}
>
>
> with
>
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL
> >           snIsDelimiter              BOOLEAN DEFAULT FALSE}
>
>
>
> The advantage of using a "delimiter signal" or "static UID
> signal" with
> SN instead of defining a new RDN attribute is the same as before - it
> maximizes interoperability with existing certificates and
> applications.  Many applications are getting along quite well using
> multi-value RDNs and application-defined treatment of "affiliation
> numbers".  These applications will continue to work with certs
> containing a non-critical QC Statements extension; they would
> be broken
> by a new RDN attribute.
>
> Stefan and the WG chairs can decide if it is appropriate to be munging
> syntax during Last Call :-).  If we can't reach quick agreement, I
> believe definition of a static UID signal should be deferred to the
> next QC iteration and the current draft should proceed to RFC.
>

---

From: Antonio Lioy <[email-masked]>
Date: Thu, 24 Feb 2000 09:55:23 +0100

> find a name that is usable for the application.

I support this position.

We have already used the subjectAltName extension and we are
quite satisfied with it. In fact we can have more than one
of it, to insert into the certificate a variety of SN or
unique identifiers.
For example, we use it to insert our unique University ID
but a second extension could be added for standard Italian
national personal code, or for the case where the same
individual belongs to two different organizations.

Each subjectAltName is distinguished by a unique OID and
hence each application can look for the one that it is able
to deal with.

This goes in the line of having just one certificate for
person, instead of forcing people to have multiple
certificates for multiple applications.

Antonio Lioy