I don't normally forward message to pem-dev that were sent to me privately, but
I
think the following exchange is important:
Date: Thu, 2 Sep 93 15:01 EST
To: secsig(_at_)udel(_dot_)edu, jueneman(_at_)gte(_dot_)com
From: Richard(_dot_)Ankney(_at_)emc2-tao(_dot_)fisc(_dot_)com
Subject: New Attributes for Part 12
I would like to add some new attributes, for use by X9F1, as well
as supporting OIDs. These need to be added to Section 7.8.
1. Signature Purpose
The Signature Purpose attribute indicates the purpose of the
originator in applying a signature to a document (e.g., authorizing
the document, witnessing another signer's signature, etc.).
signaturePurpose ATTRIBUTE
WITH ATTRIBUTE-SYNTAX OBJECT IDENTIFIER
::= { attribute 15 }
Values for the attribute will be registered at a later date.
2. Role Name
The Role Name attribute type specfies the the designated FUNCTION
of an object (generally a human) WITHIN the organization.
Example:
Role="Program Manager, X.500 Project"
Role="Principal Investigator, X.520 Anomalies and Defects"
roleName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-common-name))
::= { attribute 16 }
3. Agent Name
The Agent Name attribute specifies the FUNCTION of an object whose
actions have consequences OUTSIDE of the organization, and are
authorized in some sense to speak for, commit, or bind the
organization.
Example:
Agent="Chief Financial Officer"
Agent="Purchasing Agent"
Agent="Corporate Spokesperson"
agentName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
(SIZE (1..ub-common-name))
::= { attribute 17 }
4. Document Types
Document type OIDs are needed for the binding information
attribute. These need to be added to Annex D. Associated data
types for the OIDs can be found in Appendix E of ANSI X9.30 Part 3,
and could be added to Annex D if desired.
doc-type ID ::= { iso(1) identified-organization(3) oiw(14)
secsig(3) doc-type(6) }
id-doc-drivers-license ID ::= { doc-type 1 }
id-doc-passport ID ::= { doc-type 2 }
id-doc-alien-registration ID ::= { doc-type 3 }
----------------------------------------------------------------------------------------------
I am not familiar with the reference to "Part 12" or "Section 7.8,"
but I think these are excellent ideas.
I would assume that the roleName and agentName could reasonably
be considered part of the distinguished name, but signaturePurpose
and arguably the document types would not, but could be added to a
different kind of certificate, such as an authorization certificate.
You may get an argument over the signaturePurpose attribute. An alternative
might be to use a multipart form, wherein the body is the document itself,
and the "P.S." contains the purpose, such as "Forwarded For Your
Information, but I strongly disagree with blah, blah."
However, I can see advantages for making this section a part of the
signature itself, as it removes any ambiguity as to which was the
document and which was the comment. (I am not suggesting that PEM
needs to adopt this scheme at this time, but it might be something to
think about.)
You might want to add a couple of additional ID document types, such as
"major credit card". Although the driver's license is universal, it is the
second
worst form of identification (after the cardboard Social Security card issued
to you when you are 2 years old). A least a credit card (one that is not on the
hot list!) is reasonable proof that you live at the indicated address or at
least
pay the bills sent there, and that someone thinks you are reasonably
credit-worthy.
--------------------------------------------------------------------------------------------------
To: Richard(_dot_)Ankney(_at_)emc2-tao(_dot_)fisc(_dot_)com
Cc: jueneman(_at_)gte(_dot_)com
Subject: Re: New Attributes for Part 12
In-Reply-To: Your message of "Thu, 02 Sep 93 15:01:00 EST."
<m0oYKq2-0000ZQC(_at_)tao-gate(_dot_)fisc(_dot_)com>
Date: Fri, 03 Sep 93 01:20:17 +0100
From: Peter Williams <P(_dot_)Williams(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk>
>From: Richard(_dot_)Ankney(_at_)com(_dot_)fisc(_dot_)emc2-tao
>Subject: New Attributes for Part 12
>Date: Thu, 2 Sep 93 15:01 EST
Gentlemen,
Give the discussion on pem-dev, I can see the idea behind these
definitions.
Also, given that context, Id urge you to consider specifying structural
object classes in order that these attributes may conform to known
naming schemas and architectures, are thereby be usefully applied for
the purpose of creating distinguished, unambiguous and unique
identifiers by the naming authorities and adminsitrations. Without this
assurance, we can have no confidence wrt the Identity prescriptions
governing how DNs might be used as valid Identifiers. The facility to
determine conformance to a schema is vital for high-levels of identity
assurance.
I urge you furthermore to consider to use the IETF MHS-DS mechanisms of
registering Attributes within the evolving Internet naming
architecture, rather than using OiW. to agree an operational deployment
of such things is a shared community function, rather than a provider
duty.
----------------------------------------------------------------------------------------
Peter also sent me a lengthy message containing a certificate which
includes a multivalued RDN, and agreeing to be a test for our certificate
generation system. I'll pass it on to Dr. Yair Frankel, who is implementing
this within my organization.
I agree that it might be desirable to use the IETF MHS-DS mechanism
to register these attributes, but I am ignorant of how to go about this.
In addition, because a number of different implementations of digital
signatures are beginning to emerge, including PKCS, the ANSI X9F1,
etc., I am not sure exactly whose "turf" all of these issues impinge
upon. I agree that "an operational deployment of such things is
a shared community function, rather than a provider duty," but I am
not sure how to best go about it. Is the IETF a party to the OIW?
Should the IETF advance these issues to ANSI and/or CCITT?
Bob