Subject: RE: Straw (was Stray) Poll: SerialNumber definition

From: "David P. Kemp" <[email-masked]>
Date: Fri, 18 Feb 2000 13:49:31 -0500 (EST)

> From: Anders Rundgren <[email-masked]>
> 
> 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

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 18 Feb 2000 21:01:51 -0000

David,
Straw? Pardon my language :-(

>   meaningful to the tax collection agency.

I don't disagree.   But there is no requirement on a QC-conformat CA to specify anything
in the CP to aid developers.  Regarding RPs comparing certs:  In the Swedish system you
don't even have to compare certs as it is sufficient to know the subjects SN!  And of course
recongnizing that the issuer is one of the trusted CAs issuing such certificates..

>   the domain.

That is a possibility but who is handling this registration?  I believe that it is enough
that the CA specifies domain in the CP.  Sort of MINIMUM requirement.

<snip>

>cert belongs to the domain.

Hum, there may be thousands of RPs 'listening' to a certain CA.   This thinking does
not scale.  I.e. this MUST be declared by the CA.  In some way.

>purposes they refer to a single entity.

I must admit that I don't understand this.  To me it is the CA and not the RP that sets
the policy.  If CA = RP (eating its own crap) there is never any need to carry any kind of
additional information in the cert as such info is extracted from various sources based
on authentication.  In case the RP really needs signed/certified additional information,
ACs or Thin PKI solve this.

Anders