Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Sep 2003 18:54:11 -0400

Ryan,

Sorry for being late responding to your message on this topic. It 
slipped through the cracks at my end.

>Depends on your definition Steve :)
>
>We have run the latest NIST conformance tests and with very few 
>exceptions (namely things we didn't implement because it was 
>ambiguous or not practical) we pass, I know this doesn't exactly 
>mean we are conformant with 3280 but its the most complete test of 
>that I am aware of :)

Maybe Tim can fix this oversight :-)

>
>As for the specifics on name vs. key based chaining, the algorithm 
>described in 3280 section 6.1 effectively through out valid chains 
>as a policy if the name does not match.  Its basically the last 
>check, we know the chain cryptographically validates, we know the 
>policy intersections and are happy with them, we know and trust the 
>issuer and despite all of this  (and a bunch of other things) it 
>says lets throughs it out anyways.

failure to ensure matching between the Subject/Issuer name in a cert 
chain, especially for the last two certs, creates additional 
opportunities for human users to be fooled. Specifically, a user 
examining an EE cert (that might be displayed by an application) may 
make a value judgement based on the Issuer name, which in this case 
would not necessarily be the same name as what an administrator 
examined and used in his/her value judgement.  So, failign to perform 
this check seems to create a vulnerability that could otherwise be 
avoided.  That, by itself, seems to justify following the standard.

Steve

---

From: Tim Polk <[email-masked]>
Date: Thu, 25 Sep 2003 11:46:59 -0400

Ryan,

I meant to respond to this message some time ago.  Steve's message
has reminded me to get my two cents worth in as well!

At 06:54 PM 9/24/2003 -0400, Stephen Kent wrote:

Ryan,

Sorry for being late responding to your message on this topic. It slipped
through the cracks at my end.

Depends on your
definition Steve :)

We have run the latest NIST conformance tests and with very
few exceptions (namely things we didn't implement because it was
ambiguous or not practical) we pass, I know this doesn't exactly mean we
are conformant with 3280 but its the most complete test of that I am
aware of :)

We thought the tests were pretty comprehensive... and I know for a fact
that we test name chaining in our tests!  Those must be in the tests
you determined to be impractical...

We (NIST) are very interested in knowing more these about
ambiguities.  Are these ambiguities in RFC 3280?  Ambiguities
in the tests or test documents?

We are trying very hard to complete interoperability testing so that 3280
can progress to Draft.  If there are ambiguities in 3280 we would
like to expunge as many ambiguities as possible at that time.  That
would suggest imperfections in the editors of 3280, so I find that
unlikely! :)

If the ambiguities are in the test or test documents, we would like to
fix those as well.  If the tests are wrong, we are not achieving an
accurate view of 3280 conformance.  I am also working on protection
profiles for PKI clients that reference these tests.  I don't want
to enshrine incorrect tests in a government "standard".
(Just an aside: Note the little 's' - no FIPS is planned at this
time.)

Either way, we would love to get the list of ambiguities as you see
them.

As for the specifics on name vs. key based chaining, the
algorithm described in 3280 section 6.1 effectively through out valid
chains as a policy if the name does not match.  Its basically the
last check, we know the chain cryptographically validates, we know the
policy intersections and are happy with them, we know and trust the
issuer and despite all of this  (and a bunch of other things) it
says lets throughs it out anyways.

failure to ensure matching between the Subject/Issuer name in a cert
chain, especially for the last two certs, creates additional
opportunities for human users to be fooled. Specifically, a user
examining an EE cert (that might be displayed by an application) may make
a value judgement based on the Issuer name, which in this case would not
necessarily be the same name as what an administrator examined and used
in his/her value judgement.  So, failign to perform this check seems
to create a vulnerability that could otherwise be avoided.  That, by
itself, seems to justify following the standard.

Steve

The standard is quite clear that it is *not* name vs. key based chaining,
but name *and* key based chaining.  (The key identifiers are not
required to chain, but will do so if the CAs are conformant with RFC
3280.  If the key identifiers don't chain, that would clearly cause
interoperability problems!)

Thanks,

Tim