Jeff, a couple of follow-up questions:
RIPEM does not use bare keys. It uses X.509 certificates. The only
difference from classic RFC 1421 is that it allows the
Originator-Certificate to hold a self-signed certificate, as opposed
to a certificate from a particular issuer. As in the header above,
certificates from particular issuers can be included as
Issuer-Certificates - from the Persona Certification Authority in
this case.
I understand.
The bare key you mention is only for the recipient of an ENCRYPTED
message. I would reiterate: there is no need for the recipient to be
indicated by a Warwick-style key selector or issuer/serial because
the recipient already knows their own public key. When I receive an
ENCRYPTED message, there is no need for me to look up my own key in a
database, or to verify a certificate from an issuer. When I was
participating in RFC 1421 development, if I had thought of just
putting the public key in a Recipient-Key-Asymmetric, instead of
using the recipient's issuer/serial in a Recipient-ID-Asymmetric,
even for strict 1422 hierarchies, I would have mentioned it then and
I think it would have been accepted. Doing this has nothing to do
specifically with direct trust. I think the recipient ID just ended
up that way out of aesthetic symmetry with the Originator-ID which is
an issuer/serial. (At least, that's what I was thinking.)
Let me probe this a little bit, in hopes of nudging the various derivitives and
alternatives to PEM, together with PEM itself, a little closer together.
At first I would have tended to agree with you, but if you consider the
possibility of using multiple keys over time, your statement "there is no
need for me to look up my own key" may not be true. (I won't debate the
wisdom of periodically changing keys -- there are pros and cons that
depend on the users situtation.) And as was also pointed out, if your private
key is resident on a smart card, the user will have to maintain some type of a
local database just to specify which card corresponds to which public key.
Would it not have been possible for you to use the issuer/serial construct,
EVEN IN THE CASE OF A SELF-SIGNED CERTIFICATE, instead of
using the public key (or a digest) of the recipient's key? It seems to me that
this
might provide additional flexibility with respect to RFC 1421 compatibility,
with
no significant costs. Am I missing something?
As far as the differences between RIPEM and what you suggested:
1. Add explicit support in the RFC for self-signed certificates in
order to jump-start the process and address those users who were more
interested in issues of trust and trustworthiness, as opposed to a
formal hierarchical identification policy.
Great. This is what RIPEM does. I don't want to bore people with
explaining RIPEM's certification model. (I posted the relevant text
from the RIPEM user manual not too long ago when someone asked for an
example implementation.) Suffice it to say, I can easily configure
RIPEM to only hook me into RSADSI's Commercial Hiererchy a la RFC
1422. Or I can forget formal hierarchies and directly certify only
the people I want, thus implementing the "friends and family"
certification model (as Steve Kent once called it :-) ). You can also
have both. The self-signed cert simply allows the originator to
initiate communication without having to go through a third-party
issuer.
I assume that you can also hook into the IPRA, or into someone else's PCA
(e.g., the TIS PCA). And I would be willing to be that you could specify only
a single CA (for my company only), or multiple CA's for teaming agreements,
etc. Right?
Do you have the ability to REJECT a particular user, CA, or PCA? I thought that
we
should have included that in PEM, but Steve Kent felt that it should just be an
implementation option.
2. Support a simple e-mail based certificate-issuing responder
service that would have used the fact of e-mail connectivity as a
basis for a PCA policy model for identification. As I recall, RSA
indicated their willingness to support such a service. This policy
would clearly lie somewhere in between the RSA Commercial Hierarchy
and the Persona PCA policy models for identification purposes.
Billing for such services wasn't discussed, but it might be
reasonable to charge $30 to $50 per 10 users per e-mail account or
domain name, rather than trying to bill for $1 to $3 per user
certificate. (TARNSTAFL - There ain't really no such thing as a free
lunch.)
3. As part of this compromise between the medium-high
integrity/well-structured systems that are required by most large
corporations (witness Paul Lambert's excellent comments recently) and
the low integrity, low cost, anarchists VolksMail PGP approach, we
would adopt the use of the rfc822 e-mail name as a distinguished
name, as an alternative or in addition to the organizational person
or residential person DN model. I even offered to host a free or very
low cost X.500 directory service to facilitate such an effort, and
would have been happy to deal with the problem of aliasing back and
forth between the more conventional forms of DNs.
Sounds great. As long as the email address fits in a distinguished
name, RIPEM works fine with this. (Contrary to early releases which
had straight string-type identifiers, RIPEM is now X.509 certificate
based.) Just for my benefit, out of all the schemes I've seen for
sticking email addresses in distinguished names, which one do you
like?
I'm at home today, without all my refences, and the last thing I would try to
do
is extemporize ASN.1! But I would certainly prefer a strongly typed attribute
that is reserved explicitly for such purposes, instead of "borrowing" another
attribute. I'm attaching the X.509v3 draft from Warwick, which included the
following. I can NEVER remember the exact definition of IA5 vs. printable
string, etc., but I assume that IA5 includes the at sign, angle brackets, and
quotes that RFC-822 allows.
I have not heard anyone define a particular authoritative need for for the
privateName attribute, but I would not be surprised to see a DUNS number
referred to in that manner. It's a useful escape clause for the future, the need
for which has by now been well established!
12.4.2.1 Subject Alternative Name Field
This field provides a name, of a name form other than that of
Directory names, which is bound by the CA to the certified public
key. The following ASN.1 type defines this field:
SubjectAltName EXTENSION ::= {
SYNTAX AltName
IDENTIFIED BY { ce 8 } }
AltName ::= CHOICE {
rfc822Name [0] IA5String,
dNSName [1] IA5String,
x400Address [2] ORAddress -- Imported from X.400 --,
privateName [3] INSTANCE OF PRIVATE-NAME }
PRIVATE-NAME ::= TYPE-IDENTIFIER
This extension is always non-critical. An implementation
which recognizes this extension is not required to be able
to process all alternatives of the CHOICE. If the
alternative used is not supported by the implementation, the
extension field is ignored.
Use of the TYPE-IDENTIFIER class is described in Annexes A
and C of ITU-T Rec. X.681 | ISO/IEC 8824-2.
Finally, one question that you didn't answer is whether there is an existing
repository of RIPEM/X509 certificates?
I assume that RIPEM provides the ability to locally cache certificates that are
received from other users (embedded in their messages). Is any other form of key
distribution supported and/or popular? I'm trying to contrast the number of
RIPEM
users with the number of PGP users. Sevearl weeks ago, Rhys Weatherley sent the
following in a private message -- does this sound reasonable?
On the question of which has greater deployment, PEM or PGP: I fetched
the RIPEM key database from ripem.msu.edu this morning. It was about
200k in length. The PGP database is still arriving in my mailbox as I
write this and is getting close to 4 Mb.
Presumably the lengths are in bytes, not number of users. Since I don't know the
number of bytes per user, I can't calculate the number of users. Does 600 RIPEM
users and 12,000 PGP users sound about right?
Bob
--------------------------------
Robert R. Jueneman
Staff Scientist
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820
--- Begin Message ---
The ISO/IEC/ITU group responsible for X.509 last week issued Draft Technical
Corrigenda adding extensibility mechanisms to the X.509 certificate and CRL
formats. These result in the definition of the v3 certificate format and v2
CRL
format. These formats are as follows.
-----------------------------------
Certificate Format:
Certificate ::= SIGNED { SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version must be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version must be v2 or v3
extensions [3] Extensions OPTIONAL
-- If present, version must be v3 --} }
Version ::= INTEGER { v1(0), v2(1), v3(2) }
Extensions ::= SEQUENCE OF Extension
Extension ::= SEQUENCE {
extnId EXTENSION.&id ({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains a DER encoding of a value of type
&ExtnType
-- for the extension object identified by
extnId -- }
The extensions field allows addition of new fields to the structure without
modification to the ASN.1 definition. An extension field consists of an
extension identifier, a criticality flag, and a canonical encoding of a data
value of an ASN.1 type associated with the identified extension. When an
implementation processing a certificate does not recognize an extension, if the
criticality flag is FALSE, it may ignore that extension. If the criticality
flag is TRUE, unrecognized extensions shall cause the structure to be
considered
invalid, i.e., in a certificate, an unrecognized critical extension would cause
validation of a signature using that certificate to fail.
The following object class is used to define specific extensions. Specific
extensions may be defined in ITU-T Recommendations | International Standards or
by any organization which has a need.
EXTENSION ::= CLASS
{
&id OBJECT IDENTIFIER UNIQUE,
&ExtnType
}
WITH SYNTAX
{
SYNTAX &ExtnType
IDENTIFIED BY &id
}
--------------------------------------
CRL Format:
CertificateList ::= SIGNED { SEQUENCE {
version Version OPTIONAL,
-- if present, version must be
v2--
signature AlgorithmIdentifier,
issuer Name,
thisUpdate UTCTime,
nextUpdate UTCTime OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate UTCTime,
crlEntryExtensions Extensions OPTIONAL }
OPTIONAL,
crlExtensions [0] Extensions OPTIONAL }}
If any extensions included in a CertificateList are defined as critical, the
version element of the CertificateList shall be present. If no extensions
defined as critical are included, the version element shall be absent.
----------------------------------
In addition, the group approved issue of a Proposed Draft Amendment to X.509
defining a set of standard extensions. Draft descriptions of some samples of
extensions of likely interest to this list are given below. The full text
will be available mid-January and will be posted to this list. This text will
constitute a complete specification suitable for experimental implementation.
12.2.2.1 Authority Key Identifier Field
This field enables distinct keys used by the same certification
authority to be differentiated (e.g., as key updating occurs). The
key may be identified by an explicit key identifier, by
identification of a certificate for the key (giving certificate
issuer and certificate serial number), or both. The following
ASN.1 type defines this field:
AuthorityKeyIdentifier EXTENSION ::= {
SYNTAX AuthorityKeyId
IDENTIFIED BY { ce 1 } }
AuthorityKeyId ::= SEQUENCE {
keyIdentifier KeyIdentifier OPTIONAL,
certIssuer Name OPTIONAL,
certSerialNumber CertificateSerialNumber OPTIONAL
-- certIssuer and certSerialNumber constitute a logical pair,
-- and if either is present both must be present. Either this
-- pair or the keyIdentifier field shall be present. If all
-- three fields are present, then the certificate issuer
-- shall ensure they are consistent -- }
KeyIdentifier ::= OCTET STRING
This extension is always non-critical. A key identifier
must be unique with respect to all key identifiers for the
subject with which it is used.
12.4.2.1 Subject Alternative Name Field
This field provides a name, of a name form other than that of
Directory names, which is bound by the CA to the certified public
key. The following ASN.1 type defines this field:
SubjectAltName EXTENSION ::= {
SYNTAX AltName
IDENTIFIED BY { ce 8 } }
AltName ::= CHOICE {
rfc822Name [0] IA5String,
dNSName [1] IA5String,
x400Address [2] ORAddress -- Imported from X.400 --,
privateName [3] INSTANCE OF PRIVATE-NAME }
PRIVATE-NAME ::= TYPE-IDENTIFIER
This extension is always non-critical. An implementation
which recognizes this extension is not required to be able
to process all alternatives of the CHOICE. If the
alternative used is not supported by the implementation, the
extension field is ignored.
Use of the TYPE-IDENTIFIER class is described in Annexes A
and C of ITU-T Rec. X.681 | ISO/IEC 8824-2.
12.4.2.2 Issuer Alternative Name Field
This field provides a name, of a name form other than that of
Directory names, for the certificate issuer. The following ASN.1
type defines this field:
IssuerAltName EXTENSION ::= {
SYNTAX AltName
IDENTIFIED BY { ce 9 } }
This extension is always non-critical. An implementation
which recognizes this extension is not required to be able
to process all alternatives of the CHOICE. If the
alternative used is not supported by the implementation, the
extension field is ignored.
12.4.2.3 Directory Attributes Field
This field conveys any desired Directory attribute values for the
subject of the certificate. The following ASN.1 type defines this
field:
DirectoryAttributes EXTENSION ::= {
SYNTAX AttributesSyntax
IDENTIFIED BY { ce 10 } }
AttributesSyntax ::= SEQUENCE OF Attribute
-- Imported from X.501 InformationFramework
This extension is always non-critical.
12.2.2.4 Certificate Policies Field
This extension field lists certificate policies that the
certificate is expressly recognized as supporting, together with
optional qualifier information pertaining to these policies.
The following ASN.1 type defines this field:
CertificatePolicies EXTENSION ::= {
SYNTAX PolicyInformation
IDENTIFIED BY { ce 4 } }
PolicyInformation ::= SEQUENCE OF SEQUENCE {
certPolicyId CERTIFICATEPOLICY.&id,
qualifier CERTIFICATEPOLICY.&Qualifier {(_at_)certPolicyId}
OPTIONAL }
This extension is always non-critical.
A certificate policy may be defined by any organization with a
need. Object identifiers used to identify certificate policies
shall be assigned in accordance with CCITT Rec. X.660 | ISO/IEC
9834-1. The following ASN.1 object class is used in defining
specific certificate policies:
CERTIFICATEPOLICY ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Qualifier OPTIONAL }
WITH SYNTAX {
POLICY-IDENTIFIER &id
[QUALIFIER-TYPE &Qualifier]}
----------------------------------
Warwick Ford
--- End Message ---