Subject: 3280 Question WRT SKID/AKID matching

From: "Matt Cooper" <[email-masked]>
Date: Wed, 20 Aug 2003 12:18:56 -0400

As many of you are aware, the problem of mismatched SKIDs and AKIDs have
caused many interoperability problems between vendors in the past when it
comes to cross certification. This can happen for a variety of reasons, but
is usually to do with how the KeyID is calculated. X.509 indicates that
SKID/AKID match provides path building guidance; matching is not required in
order to have a valid path.

There was mention at the IETF conference that 3280 required subject and
authority key ID's to match; with the inference being that the path would be
invalid if they did not. However, I've looked again and I'm not necessarily
reading that into what is in the text; though I see how it could be read
that way. 

Clearly stated is what a CA must put into the certificate with regard to
AKID and SKID, but it is not stated that a path that did not adhere to this
should be considered invalid. I definitely lean toward not requiring a match
for validation, but would be interested to hear other's (especially the 3280
author's) thoughts.

From authorityKeyID:
=======================================
The keyIdentifier field of the authorityKeyIdentifier extension MUST be
included in all certificates generated by conforming CAs to facilitate
certification path construction.

From subjectKeyID:
=======================================
To facilitate certification path construction, this extension MUST appear in
all conforming CA certificates, that is, all certificates including the
basic constraints extension (section 4.2.1.10) where the value of cA is
TRUE.  The value of the subject key identifier MUST be the value placed in
the key identifier field of the Authority Key Identifier extension (section
4.2.1.1) of certificates issued by the subject of this certificate.

Matt Cooper
Orion Security Solutions
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101
(Mob) 703.981.2269
(Off) 703.917.0060
(Fax) 703.917.0260
Visit our website!
http://www.orionsec.com

---

From: Steve Hanna <[email-masked]>
Date: Thu, 21 Aug 2003 10:32:31 -0400

Matt,

I'm surprised nobody has answered your question yet.
I guess everybody's on vacation!

RFC 3280 does NOT require subject and authority key
identifiers to match. I don't believe there's an
explicit statement to that effect, but section 6.1
(which describes the validation algorithm) doesn't
refer to key identifiers at all. And sections 4.2.1.1
and 4.2.1.2 (which describe the AKID and SKID extensions)
say nothing about requiring them to match for validation.
They say instead that these extensions are used to
"facilitate certification path construction".

Apparently, this is a common misconception. I suggest
that the successor to RFC 3280 explain clearly that
there's no requirement that AKID and SKID match for
a path to be valid.

I'll mention in passing why such a requirement would
be a bad idea. If you're a CA, you may not be able to
control the SKIDs that other CAs put in their cross
certificates for you. They may not use the same method
for calculating key identifiers that you use for your
AKID (since RFC 3280 allows several different methods).

Thanks for asking. It's always good to clarify any
ambiguities. And if anyone else has a good argument
that my interpretation of RFC 3280 wrong, please
speak up.

Take care,

Steve Hanna

---

From: "L Williams" <[email-masked]>
Date: Thu, 21 Aug 2003 12:59:29 -0700

[LW] In practicality, I'm not so sure this *is* a problem, since most CAs
generate the cross-certificates based on the CA's existing certificate.
Doing a binary copy of the existing certificate's SKI into the
cross-certificate's SKI is trivial.

-Laudon

---

From: "Peter Hesse" <[email-masked]>
Date: Thu, 21 Aug 2003 21:38:03 -0400

It may be trivial, but I have seen in practice that many commerical CA
products develop their own SKI when issuing a cross-certificate.
Usually it depends on how the software accepts the request for
cross-certification.  (It's easier to provide the SKI in a self-signed
certificate than say in a PKCS#10 request.)  I won't name names, but I
will say that it was a definite problem in the first few demonstrations
involving Bridge Certification Authorities.

Caveat creator!  (Loosely: let the implementer beware!)

--Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of L Williams
Sent: Thursday, August 21, 2003 3:59 PM
To: 'Steve Hanna'
Cc: [email-masked]
Subject: RE: 3280 Question WRT SKID/AKID matching

I'll mention in passing why such a requirement would
be a bad idea. If you're a CA, you may not be able to
control the SKIDs that other CAs put in their cross certificates for
you. They may not use the same method for calculating key identifiers
that you use for your AKID (since RFC 3280 allows several different
methods).

[LW] In practicality, I'm not so sure this *is* a problem, since most
CAs generate the cross-certificates based on the CA's existing
certificate. Doing a binary copy of the existing certificate's SKI into
the cross-certificate's SKI is trivial.

-Laudon

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 22 Aug 2003 11:55:16 +0200

Peter Hesse wrote:
> certificate than say in a PKCS#10 request.)

I think it's a *very* bad idea to do such a thing and I'd personnally be 
in favor of adding some text to explicitly exclude that in son-of-rfc3280.

I'd change :

To facilitate certification path construction, this extension MUST 
appear in all conforming CA certificates, that is, all certificates 
including the basic constraints extension (section 4.2.1.10) where the 
value of cA is TRUE.  The value of the subject key identifier MUST be 
the value placed in the key identifier field of the Authority Key 
Identifier extension (section 4.2.1.1) of certificates issued by the 
subject of this certificate.

to :

To facilitate certification path construction, this extension MUST 
appear in all conforming CA certificates, that is, all certificates 
including the basic constraints extension (section 4.2.1.10) where the 
value of cA is TRUE.  The value of the subject key identifier MUST be 
the value placed in the key identifier field of the Authority Key 
Identifier extension (section 4.2.1.1) of certificates issued by the 
subject of this certificate. When creating a cross-certificate for an 
external CA, the value of the subject key identifier included inside the 
cross-certificate MUST be the copy of the value of the subject key 
identifier of the original certificate of this CA.

But to answer the original question, in my opinion, they are two 
separate steps :
- creating a certificate :
 From the above quoted text, RFC3280 requires AKI and SKI to match when 
creating a certificate

- validating a certificate :
The validation algorythm in 6 doesn't explicitly require to reject 
certificates where the AKI and SKI do not match.
It's not explicit that "processing" the AKI extension means you must 
reject a certificate if the AKI does not match the SKI of it's potential 
emitter. If that's intended, a more explicit text would be useful.

In the present situation, I'd consider such a certificate can be 
validated, just like a rfc2459 certificate that would not respect some 
more stringent rules of rfc3280 could be used for path validation, as 
long as it does not break an explicit rule of path validation in rfc3280.