[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Straw Poll: SerialNumber definition
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
>
>