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

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 25 Oct 2003 18:41:23 +0100

The problem is that RFC 3280 in practice require a CA, issuing a CA
certs, to ask the subordinate CA for its preferred SKI rather than
generating it.

To my knowledge there is no CA software that has implemented that
behavior. If I'm not wrong they are all counting on that subordinate CAs
will adopt the SKI generated by the parent CA, as the AKI placed in
issued certs.

This works for strict hierarchical structures but not for generic cross
certification (such as Bridge CA) unless CAs use the same SKI generation
algorithm.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of David P. Kemp
> Sent: den 25 oktober 2003 00:54
> 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:
> > 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?
> >
> >
> >
> > 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
> >
> >
> > Steve Hanna wrote:
> >
> >
> >>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.
> >
> >
> >
> >
>

---

From: "David P. Kemp" <[email-masked]>
Date: Sun, 26 Oct 2003 10:43:44 -0500

Hi Stefan,

Someone (sorry, I looked back through this thread but couldn't find it) 
said "we all know what's right; the question is what do real products do 
about it?"  In this instance, doing it the way real products do it is 
not useful, and a standard has no choice but to stand up for what's right.

Saying "this CA behavior works for hierarchies but not for meshes" is 
equivalent to saying "the AKI/SKI extensions work for hierarchies but 
not for meshes".  It is theoretically impossible for AKI/SKI to work 
reliably (i.e. 100% of the time instead of 1/N of the time) unless all 
CAs that issue CA certs implement chaining.

For the first subject CA cert there are two timing options: either the 
subject CA first picks its own AKI and issues some certs and then the 
issuing CA imports subject's SKI, or the issuing CA picks SKI first and 
then subject CA uses it for AKI.  But for all remaining subject CA certs 
(cross-certs) there is only one useful option - use the subject's 
existing AKI as SKI.  The cross-certifying CAs must either use subject's 
AKI or they must issue the cross-cert without an SKI extension; the 
third option of picking an SKI using some computation technique other 
than the one already used for the subject CA is a worthless and 
misleading waste of bits - it can cause RPs to discard valid paths 
(potentially the only valid path for that RP) during path construction.

I vote for keeping 3280 the way it is.  But if it is changed, it should 
say conforming CAs MUST NOT populate SKI unless they do it as specified 
in 4.2.1.2.  Fixing every CA is surely easier than "fixing" every 
application to do path construction by checking signatures, including 
even paths with the wrong SKIs.

Dave

---

From: "David P. Kemp" <[email-masked]>
Date: Sun, 26 Oct 2003 11:36:51 -0500

Oops, now I understand the scenario Steve Hanna was referring to:
   1. Subject CA picks it's own AKI using a computation
      technique, assuming issing CAs will use the same value
      for SKI (as they should).
   2. Issuing CA issues a cross-cert with an SKI using a different
      computation technique, blindly assuming that subject CA will
      take what he has been given to use as AKI as if subject were
      a child in issuer's hierarchy.

Sorry, Steve for my rant.  A working system has to have a common
set of assumptions, such as SKIs flow from the top down (works only
for hierarchies), or SKIs flow from the subject CAs to the issuers
(works in any topology), or every CA uses the same SKI computation
technique (works in any topology).  I didn't consider the situation
where the issuing CA and subject CA operate using different concepts
of who does what to whom.  Thanks, Stefan, for pointing out that
some CAs that were designed for use only in hierarchies are being
misused to issue cross certificates.

Dave