[Fwd: RE: RFC 3280 and smartcardlogin]

[Michael Bell]

This is the second answer and there are no doubts. They use the same interpretation of the standard like OpenSSL. So if you find a situation where Microsoft's software uses another interpretation then you should feel free to contact these guys directly or refer Microsoft's support to them.

Best regards

Michael

-------- Original Message --------
Subject: RE: RFC 3280 and smartcardlogin
Date: Mon, 2 Dec 2002 10:16:25 -0800
From: Laudon Williams <[EMAIL PROTECTED]>
To: Glenn Pittaway <[EMAIL PROTECTED]>, Michael Bell <[EMAIL PROTECTED]>, David Cross <[EMAIL PROTECTED]>

This is a common misunderstanding of the standard.

Problem is this...

SKI based on a hash of Public Key
---------------------------------
Root:
No AKI
SKI is unique hash of the public key in this certificate

Intermediary:
AKI is exact duplicate of the Root's SKI. This should never be computed.
It is an exact copy.
SKI is unique has of the public key in this certificate

End Entity:
AKI is exact duplicate of the Root's SKI. This should never be computed.
It is an exact copy.
SKI is unique has of the public key in this certificate

- The RFC recommends, but does not require a specific algorithm for
generating the SKI.


AKI based on Authority name and Serial Number
---------------------------------------------

Root:
Serial # - 12345
Issuer - Root CA
Subject - Root CA
No AKI
No SKI

Intermediary:
Serial # - 54321
Issuer - Root CA
Subject - Int CA
AKI - NULL, Root CA, 12345
SKI - Whatever...

End Entity:
Serial # - 67890
Issuer - Int CA
Subject - Whoever
AKI - NULL, Root CA, 54321 (this refers to the Issuer and Serial number
in the Intermediary CA)
SKI - whatever...

- The AKI does not refer to the Toot certificate. It refers to the
Issuer and Serial number in the intermediary CA.

-Laudon



-----Original Message-----
From: Glenn Pittaway
Sent: Monday, December 02, 2002 8:25 AM
To: 'Michael Bell'; Laudon Williams; David Cross

Laudon/David,
Can either of you comment?
Glenn

-----Original Message-----
From: Michael Bell [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 29, 2002 3:29 AM
To: Glenn Pittaway
Subject: RFC 3280 and smartcardlogin


Dear Mr. Pittaway,

we tested the Microsoft smartcard login successfully with a Citrix
Metaframe Server. This is also possible with a third party CA. The
problems starts if we use a CA-hierarchy. The software tries to validate

the complete certificate chain what is really good.

We afraid that there is a problem in the extension interpretation of the

validation code. It expects in the authorityKeyIdentifier in the field
authorityCertIssuer (see RFC 3280) at every time the issuer of the
certificate but this is only correct for selfsigned CA-certificates. If
you use a hierarchy which is higher than one then the
authorityCertIssuer is the issuer of the CA-cert and not the subject of
the CA-cert.

The problem is that PKIX and some laws in Europe require the use of this

extension and Microsoft is the only vendor who interprets RFC 3280 in
this way. So we cannot simply remove the extension from the
certificates. The result is that we cannot create hierarchies with
Microsft smartcardlogin or we have to build only flat hierarchies (means

there is no hierarchy).

My question is now who can I contact at Microsoft to get a statement
about this problem and does Microsoft see the problem as a bug or as is
because a patch would break too many clients?

Best regards

Michael Bell
--
-------------------------------------------------------------------
Michael Bell Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email: [EMAIL PROTECTED]
Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax: +49 (0)30-2093 2959
10099 Berlin
Germany



--
-------------------------------------------------------------------
Michael Bell Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email: [EMAIL PROTECTED]
Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax: +49 (0)30-2093 2959
10099 Berlin
Germany http://www.openca.org


______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]