Subject: Re: Straw Poll: SerialNumber definition

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 18 Feb 2000 23:39:37 -0000

Stefan,

<snip>

>Let me give you one reason/example why we can't require serialNumber to be
>unique for a person.

This is very important: I do not REQUIRED that serialNumbers should be unique
for a person.  I really think they should but my world is not smashed into pieces if I don't get
it.  Such a solution would IMO require a reinstated dnQualifier as well.

I have though requested simple (as I am only intereted in real-world stuff you know) additions
to QC CP-requirements so that a conforming CA must DECLARE a few VERY important things like

   Naming domain.

   How serialNumbers and other DN components are to be interpreted during the decoding of the
   unmistakable identity and that this interpretation may or may not be X500-friendly (using DN as a whole).

   State the reuse of the extracted identity over time versus entities.

With a fairly limited set of rules like that you can design apps with confidence and compare certs
or SNs or whatever in a defined way.

To use private OIDs for such things is IMO a vaste of time as you have to do this separately
for each CA as the OIDs are not standardized.  And then there is the default-interpretion-rule-trauma.

Note: No new bits and bytes.  Just rules will do the trick.

<snip>

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 19 Feb 2000 09:24:14 -0000

Charles,

>I can send you some example of CP qualifiers that we have use din closed
>communities to do some of the things you are looking for...

Don't do that because as I say, the number of rules to MANDATORY DECLARE for a QC CA
(in plain writing, NOT as private OIDs) can't be that great.  To solve the "identity crisis" that is.

It could/should be 

   Naming domain
      "Citizen of Guatemala"
      "VeriSign Qualified Certificate Domain"
      "Telia Mobitel"
      "IBM Corp."
      "Utah Driving License Register"

   How subject DNs are to be interpreted to form the unmistakable identity (*)
      "All DN components"
      "[SN only],  CN contains the name of the subject at the time of issuing"
      "[SN + OU], CN contains the name of the subject at the time of issuing"

  How the CA reuses unmistakable identities (UI)
      "Never reuses an UI to another entity"
      "May reuse an UI to another entity"      ; Should NOT be alllowed for a QC IMO

(*) Strictly X.500 all QC-variants using the entire DN form an unmistakable identity
but that the THEORETICAL model.   The PRACTICAL model may go a few steps
further.  And does so in a number of large, potentially very important PKIs.

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 21 Feb 2000 11:08:06 +0100

Denis,

<snip>

>All concepts could nicely co-exist if we could find a way to say on
>*which* components of the DN the dnq (DN Qualifier) would apply.
>Rather than leaving the interpretation to an (unprocessable)
>Certificate Policy OID, we should define a way to express which
>components of the RDN should be associated with the dnq to make the
>name unmistakable and *permanently* unique. 

>In this way RPs could use this minimum structure in their ACLs. Note
>that at the same time this would define the rule to compare two
>certificates, i.e. know whether they bear the same minimum permanent
>structure and hence refer to the same individual or not.

This sounds like MUSIC in my ears!

<snip>

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 21 Feb 2000 17:33:32 +0100

Paul,

>Ouch.

>The situation we started from is that there were two ways of
>interpreting a particular attribute.  The new situation you're
>pointing to is to increase that number from 2 to N.  I think that's a
>large step in the wrong direction.

Actually Denis proposal (which is exactly what I want to achieve with QC++) shows
a possible way to introduce a GENERIC mechanism that can be AUTOMATICALLY
deciphered (up to the level where the unmistakable identity is revealed) by RP software.
It gives N possibilities nut does not complicate RP software any more than any other extension

<snip>

Anders

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 23 Feb 2000 19:18:11 +0100 (MET)

Why the hell do we have object identifiers in RDNs, and not
numbers? 

> 
>           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)}

It seems that the most simple solution is to add a new attribute
'the at-sign', or the stop sign. The attribute has no possible
values, its placement inside the RDN SEQUENCE indicates that everything
before defines the unique entity. 

At a first glance on might think to create an attribute that contains
some value (like serialnumber or unique id). but there is no need
to combine these different two functions, and it is even stupid,
because it might not even be necessary to have a Serialnumber. 

Of course the approach doesn't handle ALL posible theoretical cases
like multi-valued AVAs. And in some cases you need to reverse some
schema in order to have the right hierarchy. Who cares?

Peter Sylvester

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 23 Feb 2000 19:34:01 -0000

Peter,

Your solution is of course possible.  That it is easier to explain is one thing.  To
implement them in SW is fairly equivalent.

How about a SET of RDN OIDs instead of this BITSTRING?

The reason I prefer the separate approach is that this QC Statement could
contain a block of things that would help the mecanic
interpretation of certs.  Like naming domain.   Yes, the existence
of this QC Statement could signify: "Plug'nPlay Certificate".

Anders

<snip>

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 23 Feb 2000 20:26:09 +0100 (MET)

> How about a SET of RDN OIDs instead of this BITSTRING?

That won't work, you can one OU that is part of the unique element and another
that is part of changable part. You could do a bitstring to indicate
which position in the sequence is fixed or not for EACH naming scheme. 
(I am not sayin that I like such a complex solution.)

> >Why the hell do we have object identifiers in RDNs, and not
BTW: I have been living in France for so many years now that I have
forgotten that a German person normally doesn't use such DIRECT comments. 
in fact it is one French way to say: Please, you might consider to read this. :-)

Regards and have fun.

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 23 Feb 2000 17:02:55 -0500 (EST)

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

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: "Stefan Santesson" <[email-masked]>
Date: Wed, 23 Feb 2000 19:22:05 +0100

Denis,

Let me first state that my solution was not a proposal. I don't know yet if
I like it myself. It was just a solution thrown to the floor for open
consideration. Personally I'm not yet convinced that we have a problem that
should be fixed in the first place.

But anyway, I don't like the solution you you present here by one big
reason, it introduces a new nonstandard attribute in the subject field. That
has been considered before and the principial standpoint is that it should
be avoided.

/Stefan

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, February 23, 2000 4:19 PM
> To: [email-masked]; [email-masked]
> Subject: Re: Straw Poll: SerialNumber definition
>
>
> Since the last call period is now open, let us attempt to
> (hopefully) solve this issue within that period.
>
> Let is take a look at an old INFORMATIONAL RFC, i.e. RFC 1685
> issused in August 1994. Its name is: Writing X.400 O/R Names.
>
> Basically this document *recommends* a sequence for writing
> distinguished names for human beings which is:
>
> G=;I=;S=;O=;OU1=;OU2=;P=;A=;C=;
>
> with:
>
>     Given Name                             Given name        G
>     Initial                                Initials          I
>     Surname                                Surname           S
>     Generation Qualifier                   Generation        Q
>     Common Name                            Common Name       CN
>     Organization                           Organization      O
>     Organizational Unit 1                  Org.Unit.1        OU1
>     Organizational Unit 2                  Org.Unit.2        OU2
>     Organizational Unit 3                  Org.Unit.3        OU3
>     Organizational Unit 4                  Org.Unit.4        OU4
>     Private Management Domain Name         PRMD              P
>     Administration Management Domain Name  ADMD              A
>     Country                                Country           C
>
> Suppose that now we introduce the new atribute called
> UniqueIdentifier (UI), instead of SerialNumber which is a little bit
> confusing.
>
> Denis
> > Guys,
> > I may have a nice solution to this debate.
> >
> > May I first draw your attention once again to the fact that
> the solution in
> > the qcStatement extension almost have what you ask for in
> the first place.
> >
> > What we have is a predefined statement in QC 03 saying:
> >
> >    3.2.5.1 Predefined Statements
> >
> >    This profile includes one predefined object identifier (id-qcs-
> >    pkixQCSyntax-v1), identifying conformance with syntax
> and semantics
> >    defined in this profile. This Qualified Certificate profile is
> >    referred to as version 1.
> >
> >       qcStatement-1 QC-STATEMENT ::= { SemanticsInformation
> IDENTIFIED
> >           BY id-qcs-pkixQCSyntax-v1 }
> >       --  This statement identifies conformance with syntax and
> >       --  semantics defined in this Qualified Certificate profile
> >       --  (Version 1). The SemanticsInformation may
> optionally contain
> >       --  additional semantics information as specified.
> >
> >                                                           OPTIONAL }
> >           (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
> >            WITH COMPONENTS {...,
> nameRegistrationAuthorities PRESENT})
> >
> >       NameRegistrationAuthorities ::=  SEQUENCE SIZE (1..MAX) OF
> >           GeneralName
> >
> > This is a predefined statement dedicated to include
> information that would
> > clarify the actual content in the DN attributes.
> > Lets say that we added another optional data element
> "dnIdentityMask" in the
> > samanticsInformation:
> >
> > The defined meaning of dnIdentitymask would then be to
> specify the minimum
> > set of attributes needed to obtain a unique identity of the
> subject, needed
> > to identify the subject among all subjects handled by the CA.
> >
> > The good side of this solution is that it can be used
> without any need to
> > define a new OID, since the attribute semantics OID is optional.
> >
> > This solution could in a nice way satisfy all needs raised
> in the discussion
> > without breaking any current practice or stretch any
> intended definitions or
> > structures.
> >
> > I guess that this could be considered as a minor
> adjustments to be included
> > without requiring a new last call period.
> >
> > Thoughts, comments?
> >
> > /Stefan
> >
> > > -----Original Message-----
> > > From: Anders Rundgren [mailto:[email-masked]]
> > > Sent: Wednesday, February 23, 2000 10:00 AM
> > > To: Denis Pinkas; Stephen Kent
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: Straw Poll: SerialNumber definition
> > >
> > >
> > > Steve,
> > >
> > > <snip>
> > > >I'm opposed to adding a notion of selective marking of RDNs to
> > > >indicate which ones, in concert, really qualify as a DN,
> remembering
> > > >the definition of a DN.  This was the subject of a
> private message
> > > >exchange between Anders and me last week, so I'm happy
> to share my
> > > >thoughts on this topic.
> > > >
> > > >The notion underlying this proposal seems to be that DNs are
> > > >convenient ways to express human readable names, but
> that in using
> > > >them we should abandon all notions of the DIT context from
> > > which they
> > > >emanated.
> > >
> > > Not abandon, a DN would still be a DN.  Heritage is of
> less interest.
> > > The solution is a technical way to solve something that is
> > > already performed using
> > > "local knowledge and manual settings" by a lot of current
> RP software.
> > >
> > > > A purer way to address this need would be to define a new
> > > >name type under general names (we have a couple of
> options for this
> > > >in GNs), but this would not be backward compatible with
> > > existing apps
> > > >that already have some ability to parse DNs, but not all forms of
> > > >GNs, much less a new form.
> > >
> > > As compatibility with existing SW is crucial, some purity
> > > will have to be sacrificed.
> > > For radical changes like GNs it may be better to look on
> > > XML-certs but that is another story.
> > >
> > > <snip>
> > >
> > > >I think a better approach to the base problem that motivated this
> > > >debate is to use an extension that claims to be a unique
> ID for the
> > > >subject, relative to the Issuer.  But, we already have
> such a value,
> > > >in the form of the SubjectUniqueID, if we really want
> this feature!
> > >
> > > As Denis nicely points out, the suggested solution allows
> > > arbitrary uses
> > > of DN attributes including various combinations with
> serialNumber and
> > > lets say organizationUnit.   But for the RP it looks like a
> > > singular solution
> > > as it just requires a call to the (anticipated) API function
> > > "getQCUnmistakableIdenitity()"
> > > to get the optional subset of of DN that holds the
> > > unmistakable identity.
> > > That is what I call GENERIC SOLUTION and is what standards need.
> > >
> > > SubjectUniqueID is a SPECIAL CASE of no general interest.
> > >
> > > <snip>
> > >
> > > >certs contain subject DNs that differ in other attributes?  Well,
> > > >since all the other proposals for selective RDN use require some
> > > >means of signalling RP software, why not use a cert policy
> > > OID?  It's
> > > >just as valid a means of signalling this non-standard
> > > interpretation,
> > > >for the set of RP software that will need to make use of
> this fact.
> > >
> > > Unfortunately NON-STANDARD policy OIDs create much more
> problems than
> > > they solve.  I have already elaborated on that in this list.
> > >
> > > What is missing from the current suggestion is a Naming
> > > Domain definition.
> > > I can just find two variants: Either the naming domain is
> > > marked as internal/CA
> > > and does not have to be known outside, or the CA issues
> > > certificates to
> > > an external naming domain like "registered Citizen of XYZ".
> > > The latter should
> > > require an officially registered value of some kind to be
> > > interoperable among
> > > competing CAs,
> > >
> > > Conclusion: the maintenance and setup of QC RP SW  can be
> > > really greatly simplified!
> > >
> > > OK, it does not solve the actual meaning of OU, CN, and SN
> > > etc. but somewhere you
> > > have to stop!
> > >
> > > Anders
> > >
> > > PS Steve, do you prefer that a solution according to my and
> > > Denis lines are
> > > taken to PKI-FORUM rather than developed here?  I don't
> care where as
> > > long as it gets done.  DS
> > >
> > >
>

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 24 Feb 2000 01:16:03 +0100

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

> From: David P. Kemp [mailto:[email-masked]]
> Sent: Wednesday, February 23, 2000 11:03 PM
> To: [email-masked]; [email-masked]; [email-masked]

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 24 Feb 2000 09:25:07 -0000

Bengt,

<snip>

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

The idea is (in my opinion at least) that existing aplication should continue to work
as this must be an uncritical extension.  But that new applications should see this
extension as the signal: "Plug'nPlay Certificate".   That requires though that the
NAMING DOMAIN issue is also covered by this extension.

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 24 Feb 2000 09:29:09 -0000

David,
Although I like the simplicity of the scheme it does IMO limit the ways you
can express Unmistakable Identity (UI).

I am not sure (since my X500 is rather sluggish) but it seems that you may have to move
around RDNs in order to create what you want. Do we want that?  

Let's say
DN = CN + [OU + SN]        ;Organization Unit and Serial Number
DN = CN + [SN] + OU       ; Only serial number (Swedish EID)
DN = [CN+SN] + OU        ; Probably name disambiguer usage

The [] indicates UI.   Is that compatible with this single boolean of yours?
BTW, can't an e-mail address also serve as a UI?

Conclusion: Denis' orginal position-oriented BITSTRING is more universal and
can even be applied to private RDNs.

Anders