Subject: RE: Dual-signed certificates

From: "Hiroyuki Sakakibara" <[email-masked]>
Date: Thu, 27 Jul 2000 16:11:38 +0900

Hi.
I am interested in this topic.

A self-signed certificate that contains the original
certificate as an extension within it, or, a dual-signed
certificate using CMS SignedData are recommended in this-list.

On Mon, 24 Jul 2000 Mr. Russ Housley wrote:
>Bob:

>There are some significant technical issues here.  The subject cannot sign
>first because it does not know the values that will be assigned for several
>fields, like the serial number.  The subject cannot sign second
>either.  The insertion of an additional extension will break the issuer
>signature.

>Thus, to proceed in this vain, complex processing must be defined that says
>which parts of the certificate a re coved by the subject signature in the
>extension.  I think that the processing is complex enough....

>Russ

Is a X.509 ver3 certificate,
including such as "Issuance Agreement"extension signed by a subject
not feasible ?

Extension : Issuance Agreement
means that "Subject agrees with issuance of his certificate
which includes fields and values described in this agreement."
Fields and values include public key, issuer name, subject name,
extensions etc..., but DO NOT include CA's signature.
When a CA receives a request from a subject,
creates "Issuance Agreement"
and shows it to the subject. If the subject agrees it before issuance,
he signs it and give it to the CA. The CA issues the subject certificate
including "signed Issuance Agreement" as an extension.
(I attach more detais to end)

I think that this style natural.

Because, in this style, CA's signature certifies
"the subject public key and the subject's signature on
Issance Agreement in the extension",
but the subject's signature DOES NOT certifies "CA's signature".

"the subject sign second" style,
such as a self-signed certificate that contains the original
certificate as an extension within it,
I think it means that
(1) the subject's self-signed signature certifies
the CA's signature on the subject certificate inside,
(2) the CA's signature on the subject certificate certifies
the subject public key.
(3) subject public key in (2) can be used to verify
    the subject's signature (1).

Eventhough the subject self-signed certificate contains
ID of the original certificate and its hash value,
instead of the original itself,
this also certifies the CA's signature of the
original certificate indirectly.

Is this kind of Cross-Certification or nested certification,
or the tail wags the dog ?
( Am I misunderstanding ??? )

However, as Mr.Housley wrote,
a new protocol, data, the processing must be specified for
such as a certificate including "Issuance Agreement" extension.
"the subject sign first" style.

I attach my idea to end of this mail.

Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION

-------------------------------------------------------

Indeed, I think that a new certificate issuance protocol for Issuance
Agreement extension is needed
in order to solve the chickenAndEgg probolem, like this.

1.Subject -----> CA : Cert request(including Subject PublicKey)

2.Subject <----- CA : Issuance Agreement

3.Subject -----> CA : Signed Issuance Agreement by Subject PrivateKey
                      (Subject confirms that "My cert are going to include
                       information described in Issuance Agreement",
                       if he agrees, then signs it.)

4.Subject <----- CA : Subject Cert including
                        "Signed" Issuance Agreement as a extension
                        of X.509 ver3

Contents of Issuance Agreement :

Fields and values in Subject Certificate to be issued in step 4,
{
version
Issuer name
Subject name
SerialNumber(optional),
Algorithm
Subject Public Key Information
notBefore(optional)
notAfter
extensions( certPolicies, nameConstraints, keyUsage ... etc )
CA's signature algorithm
}

If a subject checks the contents in step 2,
he can know what his certificate is going to include.
Some CAs may assign SerialNumber and notBefore(scheduled) field,
some CAs may not, when CAs create Issuance Agreement.

If a CA can assign scheduled notBefore value in Issuance Agreement,
like,
"Your certificate is going to be valid after 200007261200Z",
and if the issued subject certificate inculdes the same value in validity
notBefore field, I think that it is OK.

If RelyingPertiy finds that validity notBefore
does not match with notBefore in the Signed Issuance Agreement
extension field, then RP can reject it.

I think that eventhough the contents does not include SerialNmber field,
Subject can know that what his certificate should be avilable for,
"My public key is going to be certified by Issuer and I am the holder,
 and can be used by following these validity, certPolicies, keyUsage etc..."

But this Issuance Agreement extension is as large as his certificate itself.
So some techinique which can reduce this extension size
is needed, for example, applying a hash function etc...

( I think that a self-signed certificate that contains the original
  certificate as an extension within it has the same problem,
  maybe, the size would be twice ? )

------------------------------------------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: +81-467-41-2183
FAX:   +81-467-41-2185
E-mail : [email-masked]

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 28 Jul 2000 14:57:39 -0700

At 04:11 PM 7/27/00 +0900, Hiroyuki Sakakibara wrote:
> >which parts of the certificate are covered by the subject signature in the

A subject-signed "Issuance Agreement" extension would seem to work
from the CA's point of view.  The subject data could be signed by
the subject (prior to encryption by the root-public-key) as part of
a certificate request.  Then, as I understand Hiroyuki's suggestion,
this "submission" would become a certificate extension.

However, this method involves a near-duplication of information that
"must be preserved", and would seem to require the relying party
retrieve/check the "Issuance Agreement" against the actual elements
of the certificate, in order to preclude some claim by the subject
that they (plausibly) never agreed to the certificate terms.

Why (really) cannot the CA supply the "pre" (unsigned) certificate
for the subject review and signature, prior to the final CA signature?

I do not understand the argument "subject cannot sign first" because
some values (e.g., serial number) cannot be pre-assigned.  Absent the
CA-signature, the certificate is merely a string of bytes that anyone
can generate.  It cannot have value prior to this CA-signature.  And
I can't believe the market is suffering a shortage of serial numbers.

A protocol that provided the subject "sign first" seems very elegant,
in that you get POP on the key, and POA (proof of acceptance) on the
(pre)certificate, all in one shot.  And no duplication of the data.

Is there a really compelling reason why "subject-sign-first" is
a bad idea?

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900