[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Straw Poll: SerialNumber definition
Since the last call period is now open, let us attempt to
(hopefully) solve this issue within that period.
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.
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.
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 ?
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.
>
> SemanticsInformation ::= SEQUENCE {
> semanticsIdentifier OBJECT IDENTIFIER OPTIONAL,
> nameRegistrationAuthorities NameRegistrationAuthorities
> 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:
>
> 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)}
>
> 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:anders.rundgren@jaybis.com]
> > Sent: Wednesday, February 23, 2000 10:00 AM
> > To: Denis Pinkas; Stephen Kent
> > Cc: ietf-pkix@imc.org; EL-SIGN@LIST.ETSI.FR
> > 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
> >
> >