Subject: about validation of intermediate self-signed certs in a path

From: Hiroyuki Sakakibara <[email-masked]>
Date: Thu, 23 Aug 2001 18:52:04 +0900

Peter

Thank you for your comments.

Peter Hesse wrote:
>TR -> A -> B -> (B self signed) -> C -> EE
>Let's say that A->B has a notAfter date of 12/31/2002,
>(B self signed) has a notAfter date of 12/31/2001, and B->C has a notAfter
date of 12/31/2002.
>If this path was developed and validated, the path would be invalid
>if the current date was after  12/31/2001.

Excuse me that the example was not good.

again, (sorry for a long mail)

[example]

* A, B, C are CAs
* A has a key pair whose validity term is 1 years
* B has a key pair whose validity term is 1 years
* C has a key pair whose validity term is 1 years

     2001/01/01  06/01   2002/01/01    06/01  2003/01/01
        +-----------+-----------+-----------+---------+

A->B                     <----------------------->

B->B <----------------------><--------------------->
                        (1)                                 (2)

B->C                     <----------------------->

B issues a self-signed cert (1), notBefore 2001/01/01 notAfter 2001/12/31.
B is going to issue a new self-signed cert (2) which
containts the public key in (1), notBefore 2002/01/01 notAfter 2002/12/31,
if the public key in (1) has no problem on 2001/12/31.
( notBefore of (2) may be 2001/01/01 )
B announces the schedule of issuance of (2) to A and C beforehand.

A issues a certificate to B, notBefore 2001/06/01 notAfter 2002/5/31.
A expects that B is going to issue (2), hence, A can issue A->B
whose notAfter excesses notAfter of (1) and the validity term
of A->B is exactly 1 year.

B issues a certificate to C, notBefore 2001/06/01 notAfter 2002/05/31.
Because B is going to issue (2) on 2002/01/01, hence B can issue
B->C whose notAfter excesses notAfter of (1).

In this example, B can use the same public key continuously, in (1) and (2).
As a result, A can issue a cert to B whose validity term is always 1 year,
whennever A issues.
B can issue a cert to C whose validity term is always 1 year,
whennever B issues, also.

I suppose that some PKI systems adopt this kind of cert issuance.

[problem]

However, assume that B does not issues (2), by incident,
or rough operation etc....

if on 2002/01/02 a validation software can constructs,

"A->B, B->C" path only,

hence the software could not notice that the trouble
with issuance of (2).
Therefore it is not certain that the B's public key
is good or not.
In order to avoid this situation, A has to observe that
B issues and published (2) in LDAP etc about 2002/01/01
and if B does not issues (2), A should alarm that.

If the software constructs "A->B, B->B(1), B->C" path,
it can notice that the path is wrong, because B->B(1) is expired,
and would try to construct another path, "A->B, B->B(2), B->C"
however, B->B(2) is not present, so, it would give up, or
construct "A->B, B->C", eventhough it may be invalid.

Therefore, the result of validation of the path "A->B, B->C"
and the result of validation of the path "A->B, B->B(2), B->C"
are not identical in this case.

[revocation example]

Peter Hesse wrote:
>In the case of self-signed revocation, I am not sure why a CA would revoke
itself.  If the >CA was truly operating as a "rogue", it would not revoke
itself in order to keep whatever >trust it still had.  Can you trust a CA
that revokes itself?  I am reminded of the old puzzle >in which you
encounter two people at a crossroads, a truthteller and a liar.  You do not
>know which is which, and must ask one of them a question in order to know
if you should >turn left or right to get to where you want to go

I agree with you.
But in the case that A issues a cross certificate to B and
B issues a self-signed cert to itself,
not only B but also A would do rough operation.

If B is a rough CA, as you mentioned, B would not revoke itself and not
announce
the revocation status of B to A, then a path could be validated as good.

If A is a rough CA, even though B asks A to revoke the cross-cert from A to
B,
A would not, then a path could be valdiated as good also.

I will show an example where a validation software
would had better check revocation status of self-signed certificates.
( this is an example of latter case.)

1. B's private key was revoked.

2. B issues a CRL asserting "B is revoked"
   with its revoked privatekey.

3. B announces its revocaton to other CAs, then other CAs
   should revoke cross-certs to B.

If the procedure 3 is done immediately, the procedure 2 is not neccesarry.
But if not, because of trouble of CA sysytems or rough operateion what else,
I suppose that adoption of the procedure 2 is a good idea.

Actually, there is a risk that a bad person who knows B's private key issues
a fake CRL asserting "B is OK(not on the list)",
and a validation software uses the fake one accidentally.

A validation software can not distinguish that an obtained CRL is issued by
B
or by the bad person,
however if the software obtains the correct CRL issued by "B" first or
obtains both the correct one and the fake one, the software can
notice that the revocation of B, even though the procedure 3 is not done
immediately.

Offcourse, it is not able to prevent a validation software from obtaining
only the fake CRL first, however issuing a CRL in the procedure 2 could
reduce a risk that the software ALWAYS referes only the fake one.

[my interpretation]

I think that a validation software could gain some additional benefits
by checking self-signed certificates in a path in the case of some
PKI system such as the shown example.

However when mis-operations or troubles among CAs seldom happen,
a validation software would not need to check them.

So, section 6.1, considering your comments,
my interpretation became as follows,

* validating a path without self-signed certs ONLY -> GOOD
* validating a path with self-signed certs ONLY -> GOOD
* validating BOTH paths -> GOOD

actually, I agree with that most implementations apply the first one
because of its simplicity as you mentioned.

Also, I think that any guidline of a recommended
path pattern (such as the first one) is useful.

---------------------------------------
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: Peter Hesse <[email-masked]>
Date: Thu, 23 Aug 2001 11:26:11 -0400

Hiroyuki,

Thank you for your detailed explanations of two cases in which validating
the self-signed certificate within the path become valuable.

My main concern is with operational systems.  I've been on development teams
for numerous CA and certificate validation products, and been involved with
interoperability testing with many other products.  I have gained the
following insights on the subject of self-signed certificates:

- Not all CA products generate self-signed certificates to be treated as a
certificate within a certificate path.  By this, I mean that not all
products are concerned with setting extensions such as constraints and
policies so that a path containing this certificate would successfully
validate.  Many CA products issue a signed name and public key in the
simplest form possible.

- Not all certificate validation systems place the trust root self-signed
certificate within the path for validation.  This is the guidance provided
by RFC 2459, but is changing in son-of-2459.  This is partially because of
the bullet above.

- Not all certificate validation systems allow any self-signed certificates
to appear as intermediate certificates in paths.  This is primarily for two
reasons: 1) Preventing same subject name and public key from appearing twice
in a path prevents loops, and 2) some argue that the same public key
appearing twice in the path dilutes the trust chain.

Since these are operational realities, I would be concerned with giving
strong guidance within son-of-2459 about whether or not self-signed
certificates should or should not appear within certificate paths.  That
said, I do think we could some mention of the fact that including or not
including them can change the results of validation.  I am primarily
concerned with making sure that son-of-2459 does not allow trust root
self-signed certificates at the start of paths, and not so concerned about
eliminating self-signed certificates from ever appearing in a path.

--Peter

----------------------------------------------------------------
 Peter M. Hesse            CygnaCom Solutions, a division of
 Phone: 703-270-3523                   Entrust
 ICQ:   1942828                 Securing the Internet
----------------------------------------------------------------
"Pay no attention to what the critics say; there has never been
a statue set up in honor of a critic." --Jean Sibelius

-----Original Message-----
From: Hiroyuki Sakakibara [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 5:52 AM
To: Housley, Russ; Peter Hesse
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: about validation of intermediate self-signed certs in a path

Peter

date of 12/31/2002.

[example]

* A, B, C are CAs

[problem]

"A->B, B->C" path only,

[revocation example]

I agree with you.

[my interpretation]