RE: Straw (was Stray) Poll: SerialNumber definition

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: Anders Rundgren <anders.rundgren@jaybis.com>
> 
> OK, where can I find the list of defined OIDs expressing how to interpret 
serialNumber
> in the really impressing number of ways you provide in your posting?
> 
> Because, if a CA have to define these by itself and communicate this to all 
potential
> RPs it is really the CA that is setting the standard.  I don't buy into that.


Anders,

Automated RPs must have:

1) Domain-specific knowledge required to interpret the name schema,
   to include the meaning of the SN attribute, if present.
   RPs aren't usually comparing one cert with another, they are
   allowing the user who has presented a cert to do something useful.
   If I am filing a tax return, I must identify myself with something
   meaningful to the tax collection agency.

2) Knowledge that a cert belongs to the RP's recognized domain(s).
   "Someone" (an industry consortium, a standards body, a government
   agency, a self-appointed policy authority such as a public CA, etc)
   has to define what their domain means and register an OID to identify
   the domain.  In the simplest case, the OID would go in the Certificate
   Policies extension, not requiring the QC Statements extension.  The CP
   would state that the SN attribute contains a taxpayer ID number, and
   the tax collecting RP would only trust CAs known to follow the CP
   (by populating SN as agreed in certs with that CP OID).

Who originally creates the CP and the naming convention is outside the
scope of the QC profile.  All that matters is that the CA and the RP
agree on the meaning of a domain and can mechanically determine that a
cert belongs to the domain.


One problem with insisting on two different RDN attributes for
disambiguator and static identifier is that different RPs (or the
same RP for different purposes) may treat the identical information
differently.  If there are two certs:

   cn=Pamela Jones + sn=200
   cn=Pamela Anderson + sn=200

the SN may well identify a single person, but an RP may wish to maintain
one set of accounts/privileges/attributes/statistics which are segregated
by CN, and another set which apply to the person regardless of CN.
For some purposes the certs refer to two different entities; for other
purposes they refer to a single entity.


---------------------


Stefan,

I can't tell from section 3.2 which extensions MUST be present in a QC
and which are optional.  For example, "The certificate policies extension
SHALL contain the identifier of at least one certificate policy ...",
but it's not unambiguously clear (to me) that the CP extension SHALL
be present in every QC.

Could the required/optional status of each of the five extensions be
stated in section 3.2?

Dave Kemp