I neglected to say that the hash would be SHA-1!
----------
From: James M Hayes[SMTP:jmh(_at_)tycho(_dot_)ncsc(_dot_)mil]
Sent: Wednesday, May 06, 1998 1:33 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: FW: Charter Change Request
Hello All,
This email was sent to me concerning item 2 of the Charter Change. I am new to
the list so I'm not familiar with all of the on going issues. I have been
looking at attribute certificates and how to bind them to base certificates
(signing certificates?).
James,
Please see item 2 below...
Jean
----------
From: Jim Schaad
(Exchange)[SMTP:jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com]
Sent: Friday, May 01, 1998 7:48 PM
To: Ietf-Smime (E-mail)
Subject: Charter Change Request
I am proposing a pair of charter changes to deal with the two new drafts
which the working group decided it wanted to look at during the March IETF
meeting. These drafts are:
1. A draft to address methods of publishing certificates with authenticated
attributes in directories.
2. A draft proposing a new authenticated attribute which carries the issuer
and serial number fields to more tightly bind the signing certificate into
the signature itself.
The binding between an attribute certificate and a X.509 v3 certificate in a
multiroot environment may not be unique. The current X.509 standard calls for
a binding based on either the subjectName or issuer name and serial number.
The proposed Charter Change Request would use the latter. A proposed binding
of issuer name and serial number may not be unique in the context of a
certificate masquerade. Let me use an example before I get into defining a
proposed "relatively" unique binding.
Let's say you have CA A and CA B. In addition let's say CA B is initially a
good CA but turns bad and it doesn't use name constraints. CA A has the
ability to issue attribute certificates to both CA A and CA B clients and CA B
does not. Now, let's say that there's a server out on the Internet that will
allow access to users who have X.509 v3 certificates signed by CA A and CA B
and attribute certificates signed by CA A.
CA B creates a subordinate "CA A" or cross certifies with a its own root "CA
A". CA B's CA A has the exact same DN and serial number as the real CA A. CA
B can now issue "CA A" certificates that correspond to the correct serial
numbers as the real CA A certificates. They don't even have to be the same
subject names. CA B goes through all this trouble so that its clients can have
the same kinds of privileges as the real CA A's clients. Each of CA B's CA A
client certificates can be said to be bound to the same attribute certificates
as the real CA A clients. In order to compensate for this vulnerability, the
server would have to implement rules of its own to stop the X.509 v3
certificates from CA B's CA A from being bound to the attribute certificates
issued by the real CA A. Not a very nice programming task.
Ideally, we would like the certificate framework to define a relatively
"unique" binding between the X.509 v3 base certificate and the attribute
certificate. The Charter IMHO should use the optional issuerUID to bind the
base certificate with the attribute certificate. It could be defined as
follows:
{issuerUID Uniqueidentifier}
where Uniqueidentifier ::=SEQUENCE{publicKeyThumbprint
DD{SubjectPublicKeyInfo{SupportedAlgorithms}}}
This solution too is implementation dependent. What would be nice would be to
modify X.509 to include a BaseCertKeyID and define subject CHOICE as follows:
subject CHOICE{
baseCertificateID [0] IssuerSerial, --associated
with a PK certificate
subjectName [1] GeneralNames, --associated with a
name
BaseCertKeyID [2] HashedPublicKeySyntax, --associated with a PK}
HashedPublicKeySyntax ::=SEQUENCE{publicKeyThumbprint DD
{SubjectPublicKeyInfo{SupportedAlgorithms}}}
What's nice about the new binding is that it requires no modifications to
implementations if the environment goes from a single root to a multiple root
environment.
Hope this clarifies the case for establishing a different way to bind AC and
base certificates. Please excuse any ASN.1 notation errors. I do not know it
and used cut and paste to illustrate my point.
The charter changes are a new paragraph (paragraph #3) and a new sentence at
the end of paragraph #2
The S/MIME Working Group will define MIME encapsulation of digitally signed
and encrypted objects whose format is based on PKCS #7. [1] X.509
Certificates and CRLs as profiled by the existing PKIX Working Group will be
used to support authentication and key management. The Working Group will
base its work on the S/MIME version 2 specification (available from RSA Data
Security), but the Working Group will be free to change any part of that
specification. In particular, the Working Group will prepare a new document
that allows algorithm independence, based on PKCS #7 1.5.
The message syntax specification, based on PKCS #7 version 1.5, will be
expanded to allow additional key signature and key exchange algorithms. The
message and certificate specifications will be revised to allow them to
become standards. The optional security extensions document will specify
protocols that allow for additional security features, such as signed
message receipts. An optional specification will provide an authenticated
attribute to provide for tight binding of the signing certificate to a
signature.
The S/MIME Working Group will define methods of publishing certificates in
public repositories with the aim of maximizing the ability to send
encrypted and signed mail between two parties without prior direct
negotiation between the parties.
The S/MIME Working Group will attempt to coordinate its efforts with the
OpenPGP Working Group in areas where the work of the two groups overlap,
particularly in specification of cryptographic algorithms and MIME
structure.
[1] RSA Data Security publishes the PKCS Series of documents. RSA Data
Security has permitted the IETF to publish them as Informational RFCs as
well as to extend and enhance them.
JAMES M HAYES, Capt, USAF
Information Warfare Research Manager
National Security Agency