Subject: RE: AKI and SKI problem with RFC 3280?

From: [email-masked] (Peter Gutmann)
Date: Wed, 22 Oct 2003 02:09:34 +1300

"Al Arsenault" <[email-masked]> writes:

>Why does an AKI/SKI have to be globally unique?
>
>It strikes me that the AKI/SKI extensions are simply "search aids".  That is,
>they merely help the application (RP) determine which of a set of possible
>certificates to use is the correct one. While it would be kind of cool if an
>SKI/AKI would be globally unique (it would make searching a repository a
>little easier/quicker IN SOME CASES), it doesn't strike me as a huge deal.

  You send me a CMS signed message (say) with the key identified by sKID = 0.
  My MUA finds a cert with sKID = 0 and tries to verify the signature.  The
  verification fails, and I get a warning saying that the forces of darkness
  are tampering with my communications, I could be under attack, and the world
  is about to end.

  You send me a CMS signed message (say) with the key identified by sKID =
  aildhfsdfsjklhgdfjghkf.  My MUA can't find a cert with that sKID and
  displays an informational message saying that it couldn't find a signing
  key, and perhaps I should contact the sender for more information.

There's a big difference in terms of usability.

Peter.

---

From: Steve Hanna <[email-masked]>
Date: Tue, 21 Oct 2003 10:21:31 -0400

A decent MUA would understand that there may be more
than one cert with the same SKI. AKI/SKI is just a
hint. As such, it's nice (maybe leading to better
performance) if there's one and only one cert with
a particular SKI. But it's not required.

In fact, if you use one of the key hash methods for
calculating the AKI/SKI and there are several certificates
with the same subject public key (as with multiple
cross-certificates for a single CA), these certificates
will probably all have the same SKI.

Note also that AKI/SKI chaining SHOULD NOT be checked
during path validation. To be more explicit, it's
NOT true that the SKI of a CA certificate must match
the AKI of a certificate signed by that CA. Why?
Because the CA certificate may have been issued by
a CA that uses a different AKI/SKI computation technique
than the CA who's the subject of the CA certificate.

Thanks,

Steve

---

From: "Al Arsenault" <[email-masked]>
Date: Tue, 21 Oct 2003 10:18:04 -0400

Well, bear in mind that RFC3280 allows the "monotonically increasing..." bit
only for CA certificates.  Section 4.2.1.2 explicitly says:

	" For end entity certificates, subject key identifiers SHOULD be
   derived from the public key.  Two common methods for generating key
   identifiers from the public key are identified above."

Okay, it's only a SHOULD, not a MUST, but the scenario you reference below
only comes in to play if I signed the CMS message using my CA cert, not my
end-entity cert.

Got an example where this is relevant if the sKID's of two different CA
certs are the same?  Granted, if I use the CA cert directly in an
application, problems like your example can occur, but such uses shouldn't
be happening (IMNSHO).

		Al Arsenault

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]]
Sent: Tuesday, October 21, 2003 9:10 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?

  You send me a CMS signed message (say) with the key identified by sKID =
0.
  My MUA finds a cert with sKID = 0 and tries to verify the signature.  The
  verification fails, and I get a warning saying that the forces of darkness
  are tampering with my communications, I could be under attack, and the
world
  is about to end.

Peter.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 21 Oct 2003 17:52:44 +0200

>than the CA who's the subject of the CA certificate.
I really think it would be a better practice to always have a method of 
reusing existing SKI when emitting a cross-certificate.

It might be difficult with some currently used mecanisms for that, but 
cross-certificates for CA are not likemy to be an automatic process like 
the emission of a end-user certificate.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 22 Oct 2003 10:15:52 +0200

Steve Hanna wrote:
> hint.
 > [..]
> the AKI of a certificate signed by that CA.

Reading this discussion I ask myself:
Is there any good reason to set AKI/SKI at all?
Is it worth for anything?
Or is it just YAPEB [1]?

Ciao, Michael.

[1] yet another PKIX extension bloat

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 Oct 2003 08:53:38 -0400

>[1] yet another PKIX extension bloat

Michael,

If you read 3280 and 2459, you'll note that the 
primary use of these extensions is to allow one 
to perform more efficient path discovery, by 
helping select the right cert when more than one 
(CA) cert matches based on Subject/Issuer 
relationship.  Most of the complaints I hear are 
a result form trying to misuse the AKI/SKI as a 
search key. It's inappropriate to complain about 
how poorly your screwdriver works as a cold 
chisel.

Steve

---

From: "Peter Hesse" <[email-masked]>
Date: Wed, 22 Oct 2003 09:45:22 -0400

Michael,

When a path-building implementation is building a path, and it comes
upon one subject with multiple certificates and is trying to determine
which one to use, AKID and SKID are useful, because if they match
properly, there is a high degree of confidence that the certificate(s)
with matching AKID/SKIDs is/are the correct certificate(s) to choose.

However, just because they do not match does not mean that there is no
"there" there.  The degree of confidence that it will lead to a valid
path is lessened somewhat, but there is still a chance that the path in
that direction will be valid.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 24 Oct 2003 12:18:33 -0400

Isn't the raison d'etre of AKI/SKI to allow a verifier
to select the correct CA cert when multiple certs of the
same issuer with different public keys are available
(i.e. during rollover)?

A CA may use any computation technique to populate the
SKI of certs that it issues, but it MUST chain its own
SKI into the AKI of certs that it issues.  Otherwise
what's the point of populating AKI at all?

The reason AKI/SKI chaining MUST NOT be enforced during
path validation is because one CA could have one
signing public key identified by N different SKIs
in N different certs. (That's a bad thang, and
cross-certificates should follow precedent rather
than using a different SKI for the same public key.)
But the CA MUST choose one of it's N SKIs
to use as AKI, not make up some different N+1th value.
If it picks one of the N, then AKI is helpful 1/Nth
of the time.  If it picks something else, then AKI
can never be helpful.

Dave

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 24 Oct 2003 16:21:48 -0400

David:

Some of us are interpreting 3280 (specifically Section 4.2.1.2,Subject Key
Identifier) to state that all N SKI should be the same and match the AKI
used by the subject CA in the certificates it issues.  If not, the CAs that
do not populate the 
SKI, may not be RFC 3280 compliant.

Thus, your suggestion of the subject CA using one of the SKI is a more
liberal interpretation of 3280 and is covered by our interpretation of 3280.
At the risk of being redundant, if all CAs are 3280 compliant all N SKI in N
certificates issued to a CA for the same SPKI X == AKI in all certificates
signed by the CA, where the signature can be verified using X

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David P. Kemp
Sent: Friday, October 24, 2003 12:19 PM
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?

The reason AKI/SKI chaining MUST NOT be enforced during
path validation is because one CA could have one
signing public key identified by N different SKIs
in N different certs. (That's a bad thang, and cross-certificates should
follow precedent rather than using a different SKI for the same public key.)
But the CA MUST choose one of it's N SKIs to use as AKI, not make up some
different N+1th value. If it picks one of the N, then AKI is helpful 1/Nth
of the time.  If it picks something else, then AKI can never be helpful.

Dave

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 24 Oct 2003 18:53:53 -0400

Santosh,

I agree that Section 4.2.1.2 of 3280 unambiguously states
that an "issuing CA" that does not populate SKI with the value
of AKI used by the "subject CA" is not compliant.

It appeared that Steve Hanna was referring to non-3280-compliant
CAs, where
   "the CA certificate may have been issued by a CA that uses
    a different AKI/SKI computation technique than the CA
    who's the subject of the CA certificate."

A compliant "subject CA" may have an AKI computation technique,
but a compliant "issuing CA" must not have an SKI computation
technique for CA certs - it must import the subject CA's AKI.

Outside the realm of 3280 compliance, where the situation
of N different SKIs might occur and AKI/SKI don't necessarily
chain, the chaining problem occurs when two issuing CAs use
two different computation techniques to assign SKIs to the
subject, *not* when the issuing CA uses a different technique
than the subject CA.  The subject CA's techniques for choosing
an AKI for itself and SKIs to go in its issued certs is
completely irrelevant.

Dave

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 26 Oct 2003 10:03:34 -0500

David:

The problem of different CAs populating different SKI is the reason path
development by the relying parties should not require AKI/SKI match, but
rather use AKI/SKI match as a prioritization or weighting function.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David P. Kemp
Sent: Friday, October 24, 2003 6:54 PM
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?

Santosh,

I agree that Section 4.2.1.2 of 3280 unambiguously states
that an "issuing CA" that does not populate SKI with the value of AKI used
by the "subject CA" is not compliant.

It appeared that Steve Hanna was referring to non-3280-compliant CAs, where
   "the CA certificate may have been issued by a CA that uses
    a different AKI/SKI computation technique than the CA
    who's the subject of the CA certificate."

A compliant "subject CA" may have an AKI computation technique, but a
compliant "issuing CA" must not have an SKI computation technique for CA
certs - it must import the subject CA's AKI.

Outside the realm of 3280 compliance, where the situation
of N different SKIs might occur and AKI/SKI don't necessarily chain, the
chaining problem occurs when two issuing CAs use two different computation
techniques to assign SKIs to the subject, *not* when the issuing CA uses a
different technique than the subject CA.  The subject CA's techniques for
choosing an AKI for itself and SKIs to go in its issued certs is completely
irrelevant.

Dave

Santosh Chokhani wrote:
> liberal interpretation of 3280 and is covered by our interpretation of 
> 3280. At the risk of being redundant, if all CAs are 3280 compliant 
> all N SKI in N certificates issued to a CA for the same SPKI X == AKI 
> in all certificates signed by the CA, where the signature can be 
> verified using X
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David P. Kemp
> in N different certs. (That's a bad thang, and cross-certificates 
> should follow precedent rather than using a different SKI for the same 
> public key.) But the CA MUST choose one of it's N SKIs to use as AKI, 
> not make up some different N+1th value. If it picks one of the N, then 
> AKI is helpful 1/Nth of the time.  If it picks something else, then 
> AKI can never be helpful.
> 
> Dave
> 
> 
> Steve Hanna wrote:
> 
>