RE: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-13 Thread benson 
I've been very pleasantly surprised, in the last few months, at the
responsiveness of MS support people and developers whom I have
encountered by submitting support requests related to Kerberos and
X.509. If someone would turn down the flame-meter a notch or two and
construct a concise document explaining what's wrong with their
implementation, you might get what you want.

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

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-13 Thread Erwann ABALEA 
On Wed, 13 Nov 2002, Frédéric Giudicelli wrote:

> Well I hope MS will be able to get into an adult argumentation, I think it's
> mostly about the comprehension of the RFC, since it's really not clear the
> way IETF expresses it.
> The best solution would be that one of you big people, contact IETF, about
> the RFC comprehension, at least that would quit any kind of linguistic
> argumentation.

I personally don't think this would be useful. The corresponding paragraph
of the RFC3280 is more or less a copy of the text of the X.509 standard.
It is clearly stated at the beginning of this paragraph (the one of the
RFC3280, as not everyone has a copy of the X.509 right now) that:

   The authority key identifier extension provides a means of
   identifying the public key corresponding to the private key used to
   sign a certificate.  This extension is used where an issuer has
   multiple signing keys (either due to multiple concurrent key pairs or
   due to changeover).  The identification MAY be based on either the
   key identifier (the subject key identifier in the issuer's
   certificate) or on the issuer name and serial number.

So the purpose of this extension is to find 'the issuer of the present
certificate', and the remaining text should be placed on that context.
More precisely, when it is talked about 'the issuer name', one must
understand 'the issuer name of the issuer of the present certificate',
just as when it is talked about the 'keyIdentifier', one must understand
'the keyIdentifier of the issuer of the present certificate', and when it
is talked about 'the serial number', one must understand 'the serial
number of the issuer of the present certificate'.

RFCs-reading is an art, just like Standards-reading ;)

So far, I think that only Microsoft made this mistake, I never found it in
any other product I've seen.

Based on that, I really don't think it might be necessary to rewrite the
RFC, or the X.509 standard (which would involve *much* more work).

-- 
Erwann ABALEA <[EMAIL PROTECTED]> - RSA PGP Key ID: 0x2D0EABD5
-
Unspeakable error in module Cthulhu at address R'lyeh.

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

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-13 Thread Frédéric Giudicelli 
Politeness is always better, especially in deadend conversations, like
those, you know, you're wrong ! no it's you who is wrong !
Althoug I'll be tempted to think that MS is particullary good at this.
:)

Well I hope MS will be able to get into an adult argumentation, I think it's
mostly about the comprehension of the RFC, since it's really not clear the
way IETF expresses it.
The best solution would be that one of you big people, contact IETF, about
the RFC comprehension, at least that would quit any kind of linguistic
argumentation.

Imagine, the headlines in every journal of the world:
"Microsoft is proved, by the OpenSSL community, to be unable to understand
english !"

WARFWARFWARF !

Sorry, I had a stressfull day.



- Original Message -
From: "Richard Levitte - VMS Whacker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, November 13, 2002 5:09 PM
Subject: Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?


> In message <03f201c28a97$38a075d0$0200a8c0@station1> on Tue, 12 Nov 2002
23:02:41 +0100, Frédéric Giudicelli <[EMAIL PROTECTED]> said:
>
> groups> I'm guessing that M$ is wrong, that would not be the first time,
howerver
> groups> the real question now, is how do you contact M$, the report the
bug, the guy
> groups> I was in contact with, is:
> groups> "krish shenoy[MS]" <[EMAIL PROTECTED]>
> groups> He claims that M$ is right, I guess I'll let you big guys convince
them !
>
> I was very close to saying "tough for them" and ignoring the whole
> thing.  But then I changed my mind, and mailed that fellow.  I was
> even polite :-).
>
> In the mean time, I'll kill the ticket if it hasn't already been done.
>
> --
> Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
> Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
> \  SWEDEN   \ or +46-708-26 53 44
> Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
> Member of the OpenSSL development team: http://www.openssl.org/
>
> Unsolicited commercial email is subject to an archival fee of $400.
> See <http://www.stacken.kth.se/~levitte/mail/> for more info.
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-13 Thread Richard Levitte - VMS Whacker 
In message <03f201c28a97$38a075d0$0200a8c0@station1> on Tue, 12 Nov 2002 23:02:41 
+0100, Frédéric Giudicelli <[EMAIL PROTECTED]> said:

groups> I'm guessing that M$ is wrong, that would not be the first time, howerver
groups> the real question now, is how do you contact M$, the report the bug, the guy
groups> I was in contact with, is:
groups> "krish shenoy[MS]" <[EMAIL PROTECTED]>
groups> He claims that M$ is right, I guess I'll let you big guys convince them !

I was very close to saying "tough for them" and ignoring the whole
thing.  But then I changed my mind, and mailed that fellow.  I was
even polite :-).

In the mean time, I'll kill the ticket if it hasn't already been done.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-13 Thread Frédéric Giudicelli 
Well IETF didn't answer...
I'm guessing that M$ is wrong, that would not be the first time, howerver
the real question now, is how do you contact M$, the report the bug, the guy
I was in contact with, is:
"krish shenoy[MS]" <[EMAIL PROTECTED]>
He claims that M$ is right, I guess I'll let you big guys convince them !
Cheers !


- Original Message -
From: "Frédéric Giudicelli" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, November 01, 2002 12:50 AM
Subject: Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?


> Well Microsoft support tells me it's openssl's fault, and you tell me it's
> microsoft's ?
> It's dead end, what am I supposed to tell my clients ?
> Well... altough PKIX recommends the use of the authorityKeyId, and that
the
> French Government says you must to have this extension, to be certified,
> I'll have to remove this extension ?
>
> To make everybody happy let's read the RFC
>
> http://www.ietf.org/rfc/rfc2459.txt
>
> 4.2.1.1  Authority Key Identifier
>
> ...The identification may be based on either the
>key identifier (the subject key identifier in the issuer's
>certificate) or on the issuer name and serial number.
>
> 4.2.1.2  Subject Key Identifier
>
> ...The value of the subject key identifier MUST be the value
>placed in the key identifier field of the Authority Key Identifier
>extension (see sec. 4.2.1.1) of certificates issued by the subject of
>this certificate.
>
> Well the least that we could say, it is crystal clear :).
> it's incomprehensible.
> I'm writting to the authors to see what they say about it, becaus MS has
> another comprehension than yours.
>
> - Original Message -
> From: "Richard Levitte - VMS Whacker via RT" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Friday, November 01, 2002 12:23 AM
> Subject: Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension
?
>
>
> >
> > In message <[EMAIL PROTECTED]> on Thu, 31 Oct
2002
> 23:19:17 +0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:
> >
> > rt> All I know, is that MS Windows 2000 SP3 consider the chain broken,
> > rt> it links the EndUser Cert with the ROOT CERT, and since the issuer
> > rt> of the EndUser Cert is not ROOT CA, badaboum, unusable
> > rt> certificate.
> >
> > In that case, I think Windows has it wrong.
> >
> > rt> When authorityKeyId=keyid, it works, when authorityKeyId=keyid,
> > rt> issuer -> doesn't work.
> >
> > OK, listen up: It's not the combination keyID+issuer that should be
> > looked up, it's the combination issuer+serial (look at the
> > certificate, there should be a serial number there as well).  If
> > Windows breaks on such values, it's broken.
> >
> > rt> I'm sorry but when we talk about the issuer of the EndUser Cert,
> > rt> we talk about INTERMEDIATE CA, not ROOT CA.
> >
> > Again, listen up: The intermediate CA certificate can be refered to by
> > subject or by rootsubject+serial (that is, the serial number that you
> > can see in the intermediate CA certificate).  It's the latter lookup
> > method that should be used when the authorityKeyIdentifier is used.
> >
> > rt> That's a non sense.
> >
> > No, you just keep ignoring the serial number, and apparently, so does
> > Windows.
> >
> > --
> > Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
> > Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
> > \  SWEDEN   \ or +46-708-26 53 44
> > Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
> > Member of the OpenSSL development team: http://www.openssl.org/
> >
> > Unsolicited commercial email is subject to an archival fee of $400.
> > See <http://www.stacken.kth.se/~levitte/mail/> for more info.
> >
> >
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-13 Thread Vadim Fedukovich 
On Tue, Nov 12, 2002 at 11:04:17PM +0100, Frédéric Giudicelli via RT wrote:
> 
> Well IETF didn't answer...
> I'm guessing that M$ is wrong, that would not be the first time, howerver
> the real question now, is how do you contact M$, the report the bug, the guy
> I was in contact with, is:
> "krish shenoy[MS]" <[EMAIL PROTECTED]>
> He claims that M$ is right, I guess I'll let you big guys convince them !

I think it is software author should convince the customer to buy a product
doing something the right way.

> Cheers !
> 
> 
> - Original Message -
> From: "Frédéric Giudicelli" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Friday, November 01, 2002 12:50 AM
> Subject: Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?
> 
> 
> > Well Microsoft support tells me it's openssl's fault, and you tell me it's
> > microsoft's ?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-12 Thread Frédéric Giudicelli via RT 

Well IETF didn't answer...
I'm guessing that M$ is wrong, that would not be the first time, howerver
the real question now, is how do you contact M$, the report the bug, the guy
I was in contact with, is:
"krish shenoy[MS]" <[EMAIL PROTECTED]>
He claims that M$ is right, I guess I'll let you big guys convince them !
Cheers !


- Original Message -
From: "Frédéric Giudicelli" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, November 01, 2002 12:50 AM
Subject: Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?


> Well Microsoft support tells me it's openssl's fault, and you tell me it's
> microsoft's ?
> It's dead end, what am I supposed to tell my clients ?
> Well... altough PKIX recommends the use of the authorityKeyId, and that
the
> French Government says you must to have this extension, to be certified,
> I'll have to remove this extension ?
>
> To make everybody happy let's read the RFC
>
> http://www.ietf.org/rfc/rfc2459.txt
>
> 4.2.1.1  Authority Key Identifier
>
> ...The identification may be based on either the
>key identifier (the subject key identifier in the issuer's
>certificate) or on the issuer name and serial number.
>
> 4.2.1.2  Subject Key Identifier
>
> ...The value of the subject key identifier MUST be the value
>placed in the key identifier field of the Authority Key Identifier
>extension (see sec. 4.2.1.1) of certificates issued by the subject of
>this certificate.
>
> Well the least that we could say, it is crystal clear :).
> it's incomprehensible.
> I'm writting to the authors to see what they say about it, becaus MS has
> another comprehension than yours.
>
> - Original Message -
> From: "Richard Levitte - VMS Whacker via RT" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Friday, November 01, 2002 12:23 AM
> Subject: Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension
?
>
>
> >
> > In message <[EMAIL PROTECTED]> on Thu, 31 Oct
2002
> 23:19:17 +0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:
> >
> > rt> All I know, is that MS Windows 2000 SP3 consider the chain broken,
> > rt> it links the EndUser Cert with the ROOT CERT, and since the issuer
> > rt> of the EndUser Cert is not ROOT CA, badaboum, unusable
> > rt> certificate.
> >
> > In that case, I think Windows has it wrong.
> >
> > rt> When authorityKeyId=keyid, it works, when authorityKeyId=keyid,
> > rt> issuer -> doesn't work.
> >
> > OK, listen up: It's not the combination keyID+issuer that should be
> > looked up, it's the combination issuer+serial (look at the
> > certificate, there should be a serial number there as well).  If
> > Windows breaks on such values, it's broken.
> >
> > rt> I'm sorry but when we talk about the issuer of the EndUser Cert,
> > rt> we talk about INTERMEDIATE CA, not ROOT CA.
> >
> > Again, listen up: The intermediate CA certificate can be refered to by
> > subject or by rootsubject+serial (that is, the serial number that you
> > can see in the intermediate CA certificate).  It's the latter lookup
> > method that should be used when the authorityKeyIdentifier is used.
> >
> > rt> That's a non sense.
> >
> > No, you just keep ignoring the serial number, and apparently, so does
> > Windows.
> >
> > --
> > Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
> > Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
> > \  SWEDEN   \ or +46-708-26 53 44
> > Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
> > Member of the OpenSSL development team: http://www.openssl.org/
> >
> > Unsolicited commercial email is subject to an archival fee of $400.
> > See <http://www.stacken.kth.se/~levitte/mail/> for more info.
> >
> >
>

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

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-04 Thread Erwann ABALEA 
On Fri, 1 Nov 2002, [iso-8859-1] Frédéric Giudicelli wrote:

> Well Microsoft support tells me it's openssl's fault, and you tell me it's
> microsoft's ?
> It's dead end, what am I supposed to tell my clients ?

Well. Since Microsoft's history if full of bugs, security problems, and
non-comformity to the standarts, then Microsoft is more likely to be
guilty. ;)

> Well... altough PKIX recommends the use of the authorityKeyId, and that the
> French Government says you must to have this extension, to be certified,
> I'll have to remove this extension ?

No. The authorityKeyIdentifier can be used in 3 different manners,
differing in the content of the extension:
 1/ specify the keyIdentifier contained in the subjectKeyIdentifier
extension of the issuer certificate
 2/ specify the issuer name of the issuing certificate, with the serial
number of the issuing certificate (that is, identify the issuing
certificate by it's father's name and the rank of the issuing
certificate in all those children).
 3/ both of the above contents

The easiest method is the first one, of course. But that means each
issuing certificate has to have a subjectKeyIdentifier extension. When
it's not the case, and you *must* provide an authorityKeyIdentifier
extension, then the method 2 is the only one possible.

Please take into consideration that:
 - qualified certificates are defined by European directives, not a french
   law
 - it takes a lot more than just using the authorityKeyIdentifier
   extension to have a qualified certificate

Hope this helps.

-- 
Erwann ABALEA <[EMAIL PROTECTED]> - RSA PGP Key ID: 0x2D0EABD5
-
CJ> Les censeurs agitent plus de vent que les moulins des Pays Bas.
Tiens, je savais pas que c'étaient les moulins qui créaient le vent.
-+- GR in GNU : Dame qui se shoote et sang chaud pensa -+-

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

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-04 Thread Erwann ABALEA 
On Sat, 2 Nov 2002, Vadim Fedukovich wrote:

> On Fri, Nov 01, 2002 at 12:51:24AM +0100, Frédéric Giudicelli via RT wrote:
> >
> > Well Microsoft support tells me it's openssl's fault, and you tell me it's
> > microsoft's ?
> > It's dead end, what am I supposed to tell my clients ?
>
> Well, Microsoft and openssl are not the only code available.
> Would you accept a well-done one from IBM? The SET wallet was tested
> to accept certificates hierarchy with AKI extension in merchant certificate
> referring brand CA, not merchant CA name.

You're right, that's how it's done in the SET hierarchy. The keyIdentifier
is not used, the only valid content for the authorityKeyIdentifier is the
issuer's name of the issuer certificate, packed with the issuer's
certificate serial number.

-- 
Erwann ABALEA <[EMAIL PROTECTED]> - RSA PGP Key ID: 0x2D0EABD5
-
Et puis, je sais que ça ne se fait pas de reprendre sur l'orthographe,
mais l'usage Usenetien veut qu'on écrive "scançeur".
En ajoutant "fâssiste", pour faire bonne mesure.
-+- XH in  : L'heptalingue sans peine -+-

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

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-04 Thread Erwann ABALEA 
On Thu, 31 Oct 2002, Frédéric Giudicelli via RT wrote:

> ROOT CA's authorityKeyIdentifier extension gives its own DN as issuer (normal)
> INTERMEDIATE CA's authorityKeyIdentifier extension gives ROOT CA's DN as issuer 
>(normal)
> A certificate signed by INTERMEDIATE CA, gives ROOT CA's DN as issuer
> (not normal), shouldn't it be INTERMEDIATE CA's DN ? since the issuer of
> this certificate is INTERMEDIATE CA and not ROOT CA.

OpenSSL is right. To use 'human' terms, to point to your father, you have
to give your grandfather's name and the exact number of your father among
all your grandfather's children. That's how it's done, and that's how it
has to be done.

-- 
Erwann ABALEA <[EMAIL PROTECTED]> - RSA PGP Key ID: 0x2D0EABD5
-
Le netétiquette n'est qu'une vaste fumisterie,il faut de l'argent pour
fonctionner,à force,en France de refuser tout rapport sain avec
l'argent,l'on riqsque de tuer ce nouvel outil.
-+- AA in: Guide du Neuneu d'Usenet - Le netétiquette du riche -+-

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

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension?

2002-11-02 Thread Massimiliano Pala 
Frédéric Giudicelli via RT wrote:

Well Microsoft support tells me it's openssl's fault, and you tell me it's
microsoft's ?
It's dead end, what am I supposed to tell my clients ?
Well... altough PKIX recommends the use of the authorityKeyId, and that the
French Government says you must to have this extension, to be certified,
I'll have to remove this extension ?


No, I agree with Richard's opionion, and I guess it is the only one that
makes sense... anyway M$ has been often reported to not follow the standards
nevertheless what they where saying about it.

My suggestion, do things in the right way.

--

C'you,

	Massimiliano Pala

--o-
Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED]
 [EMAIL PROTECTED]
http://www.openca.orgTel.:   +39 (0)59  270  094
http://openca.sourceforge.netMobile: +39 (0)347 7222 365



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-01 Thread Vadim Fedukovich 
On Fri, Nov 01, 2002 at 12:51:24AM +0100, Frédéric Giudicelli via RT wrote:
> 
> Well Microsoft support tells me it's openssl's fault, and you tell me it's
> microsoft's ?
> It's dead end, what am I supposed to tell my clients ?

Well, Microsoft and openssl are not the only code available.
Would you accept a well-done one from IBM? The SET wallet was tested
to accept certificates hierarchy with AKI extension in merchant certificate
referring brand CA, not merchant CA name.

This hierarchy was generated for test only; one could learn details
looking at Naina library, http://www.unity.net/~vf/naina_r1.tgz

happy learning,
Vadim

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

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-01 Thread Richard Levitte - VMS Whacker via RT 

In message <[EMAIL PROTECTED]> on Fri,  1 Nov 2002 00:51:24 
+0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:

rt> Well Microsoft support tells me it's openssl's fault, and you tell
rt> me it's microsoft's?

I'm basing what I say, not only on the way it's implemented, but also
on what's written in RFC3280 (the new version of what was RFC2459) and
in various books.  I've explained how it should work according to
those and why OpenSSL is doing the right thing, have Microsoft done
some kind of explanation of their behavior or were they just in a
blame game (I suspect the latter, but I'd love to be pleasantly
surprised).  I'd love to hear how they think things should work.

rt> It's dead end, what am I supposed to tell my clients ?
rt> Well... altough PKIX recommends the use of the authorityKeyId, and that the
rt> French Government says you must to have this extension, to be certified,
rt> I'll have to remove this extension ?

Or stop using software that can't handle security properly, OR find
out if there's something else that Microsoft wants to see in their
certkey store.  Are the root CA and intermediate CA certificates in
there (I'm fumbling in the dark with my guesses, I know)?

rt> To make everybody happy let's read the RFC
rt> 
rt> http://www.ietf.org/rfc/rfc2459.txt
rt> 
rt> 4.2.1.1  Authority Key Identifier
rt> 
rt> ...The identification may be based on either the
rt>key identifier (the subject key identifier in the issuer's
rt>certificate) or on the issuer name and serial number.
   
That says it all.  Just think of what the combination of issuer and
serial number is used for.  But you're right, it would be clearer if
there was the following parenthesis added on:

(the issuer and serial number in the issuer's certificate)

Think about it like this: if the authorityKeyID was to have the issuer
and serial number of the certificate it's in, what use would it have,
since it would just duplicate parts of that same certificate (the
issuer and serial number fields on the constant part of the
certificate).  It simply doesn't make sense to have the redundancy,
and certainly doesn't help finding the specific CA certificate that
was used to sign this certificate.

rt> 4.2.1.2  Subject Key Identifier
rt> 
rt> ...The value of the subject key identifier MUST be the value
rt>placed in the key identifier field of the Authority Key Identifier
rt>extension (see sec. 4.2.1.1) of certificates issued by the subject of
rt>this certificate.
rt> 
rt> Well the least that we could say, it is crystal clear :).
rt> it's incomprehensible.

I disagree with you, but I've worked with this long enough to have a
rather fine-tuned understanding of how this works.  It took me some
time to get here.

rt> I'm writting to the authors to see what they say about it, becaus
rt> MS has another comprehension than yours.

I'd love to hear what answers you get, from all parties.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.

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

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-01 Thread Richard Levitte - VMS Whacker 
In message <[EMAIL PROTECTED]> on Fri,  1 Nov 2002 00:51:24 
+0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:

rt> Well Microsoft support tells me it's openssl's fault, and you tell
rt> me it's microsoft's?

I'm basing what I say, not only on the way it's implemented, but also
on what's written in RFC3280 (the new version of what was RFC2459) and
in various books.  I've explained how it should work according to
those and why OpenSSL is doing the right thing, have Microsoft done
some kind of explanation of their behavior or were they just in a
blame game (I suspect the latter, but I'd love to be pleasantly
surprised).  I'd love to hear how they think things should work.

rt> It's dead end, what am I supposed to tell my clients ?
rt> Well... altough PKIX recommends the use of the authorityKeyId, and that the
rt> French Government says you must to have this extension, to be certified,
rt> I'll have to remove this extension ?

Or stop using software that can't handle security properly, OR find
out if there's something else that Microsoft wants to see in their
certkey store.  Are the root CA and intermediate CA certificates in
there (I'm fumbling in the dark with my guesses, I know)?

rt> To make everybody happy let's read the RFC
rt> 
rt> http://www.ietf.org/rfc/rfc2459.txt
rt> 
rt> 4.2.1.1  Authority Key Identifier
rt> 
rt> ...The identification may be based on either the
rt>key identifier (the subject key identifier in the issuer's
rt>certificate) or on the issuer name and serial number.
   
That says it all.  Just think of what the combination of issuer and
serial number is used for.  But you're right, it would be clearer if
there was the following parenthesis added on:

(the issuer and serial number in the issuer's certificate)

Think about it like this: if the authorityKeyID was to have the issuer
and serial number of the certificate it's in, what use would it have,
since it would just duplicate parts of that same certificate (the
issuer and serial number fields on the constant part of the
certificate).  It simply doesn't make sense to have the redundancy,
and certainly doesn't help finding the specific CA certificate that
was used to sign this certificate.

rt> 4.2.1.2  Subject Key Identifier
rt> 
rt> ...The value of the subject key identifier MUST be the value
rt>placed in the key identifier field of the Authority Key Identifier
rt>extension (see sec. 4.2.1.1) of certificates issued by the subject of
rt>this certificate.
rt> 
rt> Well the least that we could say, it is crystal clear :).
rt> it's incomprehensible.

I disagree with you, but I've worked with this long enough to have a
rather fine-tuned understanding of how this works.  It took me some
time to get here.

rt> I'm writting to the authors to see what they say about it, becaus
rt> MS has another comprehension than yours.

I'd love to hear what answers you get, from all parties.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-01 Thread Frédéric Giudicelli 
Well Microsoft support tells me it's openssl's fault, and you tell me it's
microsoft's ?
It's dead end, what am I supposed to tell my clients ?
Well... altough PKIX recommends the use of the authorityKeyId, and that the
French Government says you must to have this extension, to be certified,
I'll have to remove this extension ?

To make everybody happy let's read the RFC

http://www.ietf.org/rfc/rfc2459.txt

4.2.1.1  Authority Key Identifier

...The identification may be based on either the
   key identifier (the subject key identifier in the issuer's
   certificate) or on the issuer name and serial number.

4.2.1.2  Subject Key Identifier

...The value of the subject key identifier MUST be the value
   placed in the key identifier field of the Authority Key Identifier
   extension (see sec. 4.2.1.1) of certificates issued by the subject of
   this certificate.

Well the least that we could say, it is crystal clear :).
it's incomprehensible.
I'm writting to the authors to see what they say about it, becaus MS has
another comprehension than yours.

- Original Message -
From: "Richard Levitte - VMS Whacker via RT" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, November 01, 2002 12:23 AM
Subject: Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?


>
> In message <[EMAIL PROTECTED]> on Thu, 31 Oct 2002
23:19:17 +0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:
>
> rt> All I know, is that MS Windows 2000 SP3 consider the chain broken,
> rt> it links the EndUser Cert with the ROOT CERT, and since the issuer
> rt> of the EndUser Cert is not ROOT CA, badaboum, unusable
> rt> certificate.
>
> In that case, I think Windows has it wrong.
>
> rt> When authorityKeyId=keyid, it works, when authorityKeyId=keyid,
> rt> issuer -> doesn't work.
>
> OK, listen up: It's not the combination keyID+issuer that should be
> looked up, it's the combination issuer+serial (look at the
> certificate, there should be a serial number there as well).  If
> Windows breaks on such values, it's broken.
>
> rt> I'm sorry but when we talk about the issuer of the EndUser Cert,
> rt> we talk about INTERMEDIATE CA, not ROOT CA.
>
> Again, listen up: The intermediate CA certificate can be refered to by
> subject or by rootsubject+serial (that is, the serial number that you
> can see in the intermediate CA certificate).  It's the latter lookup
> method that should be used when the authorityKeyIdentifier is used.
>
> rt> That's a non sense.
>
> No, you just keep ignoring the serial number, and apparently, so does
> Windows.
>
> --
> Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
> Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
> \  SWEDEN   \ or +46-708-26 53 44
> Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
> Member of the OpenSSL development team: http://www.openssl.org/
>
> Unsolicited commercial email is subject to an archival fee of $400.
> See <http://www.stacken.kth.se/~levitte/mail/> for more info.
>
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-11-01 Thread Frédéric Giudicelli 
All I know, is that MS Windows 2000 SP3 consider the chain broken, it links
the EndUser Cert with the ROOT CERT, and since the issuer of the EndUser
Cert is not ROOT CA, badaboum, unusable certificate.
When authorityKeyId=keyid, it works, when authorityKeyId=keyid, issuer ->
doesn't work.
So I compiled openssl with the changement I proposed and it works fine, the
cert chain is validated by windows.

I'm sorry but when we talk about the issuer of the EndUser Cert, we talk
about INTERMEDIATE CA, not ROOT CA.

Tell me what DN would contained the authorityKeyId's issuer if I had a 3
levels architecture ?
That's a non sense.

- Original Message -
From: "Richard Levitte - VMS Whacker via RT" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, October 31, 2002 11:07 PM
Subject: Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?


>
> In message <[EMAIL PROTECTED]> on Thu, 31 Oct 2002
22:44:33 +0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:
>
> rt> The "authorityKeyIdentifier" extension seems to behave weirdly...
> rt>
> rt> I have a two level CA architecture:
> rt> ROOT CA
> rt> INTERMEDIATE CA
> rt> For both CA:
> rt> authorityKeyIdentifier = keyid,issuer:always
> rt>
> rt> ROOT CA's authorityKeyIdentifier extension gives its own DN as issuer
(normal)
> rt> INTERMEDIATE CA's authorityKeyIdentifier extension gives ROOT CA's DN
as issuer (normal)
> rt> A certificate signed by INTERMEDIATE CA, gives ROOT CA's DN as issuer
(not normal), shouldn't it be INTERMEDIATE CA's DN ? since the issuer of
this certificate is INTERMEDIATE CA and not ROOT CA.
> rt>
> rt> So I looked at the source code, and I found:
> rt>
> rt> crypto/x509v3/v3_akey.c:144
> rt>
> rt> cert = ctx->issuer_cert;
> rt> ...
> rt> if((issuer && !ikeyid) || (issuer == 2)) {
> rt>  isname = X509_NAME_dup(X509_get_issuer_name(cert));
> rt>
> rt> So "cert" contains the issuer certificate, and we copy the "cert"'s
issuer DN, and not his DN 
> rt>  isname = X509_NAME_dup(X509_get_subject_name(cert)); would be more
proper no ?
>
> You entirely missed the line following what you show:
>
> serial = M_ASN1_INTEGER_dup(X509_get_serialNumber(cert));
>
> and how those two variables.  Think about it, how are certificates
> refered to?  You can refer to it by subject, which is inprecise, since
> it doesn't specify *one*specific* certificate.  The other way is to
> refer to it with issuer and serial number, which should match exactly
> one and only one certificate (unless the issuer has fucked up the
> serial number sequencer).
>
> So, what is stored in the authorityKeyId extension is the issuer and
> serial number of the intermediate CA, which refers to one specific
> certificate that belongs to that intermediate CA, as well as the key
> ID.
>
> This is not an error.
>
> --
> Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
> Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
> \  SWEDEN   \ or +46-708-26 53 44
> Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
> Member of the OpenSSL development team: http://www.openssl.org/
>
> Unsolicited commercial email is subject to an archival fee of $400.
> See <http://www.stacken.kth.se/~levitte/mail/> for more info.
>
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-10-31 Thread Frédéric Giudicelli via RT 

Well Microsoft support tells me it's openssl's fault, and you tell me it's
microsoft's ?
It's dead end, what am I supposed to tell my clients ?
Well... altough PKIX recommends the use of the authorityKeyId, and that the
French Government says you must to have this extension, to be certified,
I'll have to remove this extension ?

To make everybody happy let's read the RFC

http://www.ietf.org/rfc/rfc2459.txt

4.2.1.1  Authority Key Identifier

...The identification may be based on either the
   key identifier (the subject key identifier in the issuer's
   certificate) or on the issuer name and serial number.

4.2.1.2  Subject Key Identifier

...The value of the subject key identifier MUST be the value
   placed in the key identifier field of the Authority Key Identifier
   extension (see sec. 4.2.1.1) of certificates issued by the subject of
   this certificate.

Well the least that we could say, it is crystal clear :).
it's incomprehensible.
I'm writting to the authors to see what they say about it, becaus MS has
another comprehension than yours.

- Original Message -
From: "Richard Levitte - VMS Whacker via RT" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, November 01, 2002 12:23 AM
Subject: Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?


>
> In message <[EMAIL PROTECTED]> on Thu, 31 Oct 2002
23:19:17 +0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:
>
> rt> All I know, is that MS Windows 2000 SP3 consider the chain broken,
> rt> it links the EndUser Cert with the ROOT CERT, and since the issuer
> rt> of the EndUser Cert is not ROOT CA, badaboum, unusable
> rt> certificate.
>
> In that case, I think Windows has it wrong.
>
> rt> When authorityKeyId=keyid, it works, when authorityKeyId=keyid,
> rt> issuer -> doesn't work.
>
> OK, listen up: It's not the combination keyID+issuer that should be
> looked up, it's the combination issuer+serial (look at the
> certificate, there should be a serial number there as well).  If
> Windows breaks on such values, it's broken.
>
> rt> I'm sorry but when we talk about the issuer of the EndUser Cert,
> rt> we talk about INTERMEDIATE CA, not ROOT CA.
>
> Again, listen up: The intermediate CA certificate can be refered to by
> subject or by rootsubject+serial (that is, the serial number that you
> can see in the intermediate CA certificate).  It's the latter lookup
> method that should be used when the authorityKeyIdentifier is used.
>
> rt> That's a non sense.
>
> No, you just keep ignoring the serial number, and apparently, so does
> Windows.
>
> --
> Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
> Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
> \  SWEDEN   \ or +46-708-26 53 44
> Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
> Member of the OpenSSL development team: http://www.openssl.org/
>
> Unsolicited commercial email is subject to an archival fee of $400.
> See <http://www.stacken.kth.se/~levitte/mail/> for more info.
>
>

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

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-10-31 Thread Richard Levitte - VMS Whacker via RT 

In message <[EMAIL PROTECTED]> on Thu, 31 Oct 2002 23:19:17 
+0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:

rt> All I know, is that MS Windows 2000 SP3 consider the chain broken,
rt> it links the EndUser Cert with the ROOT CERT, and since the issuer
rt> of the EndUser Cert is not ROOT CA, badaboum, unusable
rt> certificate.

In that case, I think Windows has it wrong.

rt> When authorityKeyId=keyid, it works, when authorityKeyId=keyid,
rt> issuer -> doesn't work.

OK, listen up: It's not the combination keyID+issuer that should be
looked up, it's the combination issuer+serial (look at the
certificate, there should be a serial number there as well).  If
Windows breaks on such values, it's broken.

rt> I'm sorry but when we talk about the issuer of the EndUser Cert,
rt> we talk about INTERMEDIATE CA, not ROOT CA.

Again, listen up: The intermediate CA certificate can be refered to by
subject or by rootsubject+serial (that is, the serial number that you
can see in the intermediate CA certificate).  It's the latter lookup
method that should be used when the authorityKeyIdentifier is used.

rt> That's a non sense.

No, you just keep ignoring the serial number, and apparently, so does
Windows.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.

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

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-10-31 Thread Richard Levitte - VMS Whacker 
In message <[EMAIL PROTECTED]> on Thu, 31 Oct 2002 23:19:17 
+0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:

rt> All I know, is that MS Windows 2000 SP3 consider the chain broken,
rt> it links the EndUser Cert with the ROOT CERT, and since the issuer
rt> of the EndUser Cert is not ROOT CA, badaboum, unusable
rt> certificate.

In that case, I think Windows has it wrong.

rt> When authorityKeyId=keyid, it works, when authorityKeyId=keyid,
rt> issuer -> doesn't work.

OK, listen up: It's not the combination keyID+issuer that should be
looked up, it's the combination issuer+serial (look at the
certificate, there should be a serial number there as well).  If
Windows breaks on such values, it's broken.

rt> I'm sorry but when we talk about the issuer of the EndUser Cert,
rt> we talk about INTERMEDIATE CA, not ROOT CA.

Again, listen up: The intermediate CA certificate can be refered to by
subject or by rootsubject+serial (that is, the serial number that you
can see in the intermediate CA certificate).  It's the latter lookup
method that should be used when the authorityKeyIdentifier is used.

rt> That's a non sense.

No, you just keep ignoring the serial number, and apparently, so does
Windows.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-10-31 Thread Frédéric Giudicelli via RT 

All I know, is that MS Windows 2000 SP3 consider the chain broken, it links
the EndUser Cert with the ROOT CERT, and since the issuer of the EndUser
Cert is not ROOT CA, badaboum, unusable certificate.
When authorityKeyId=keyid, it works, when authorityKeyId=keyid, issuer ->
doesn't work.
So I compiled openssl with the changement I proposed and it works fine, the
cert chain is validated by windows.

I'm sorry but when we talk about the issuer of the EndUser Cert, we talk
about INTERMEDIATE CA, not ROOT CA.

Tell me what DN would contained the authorityKeyId's issuer if I had a 3
levels architecture ?
That's a non sense.

- Original Message -
From: "Richard Levitte - VMS Whacker via RT" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, October 31, 2002 11:07 PM
Subject: Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?


>
> In message <[EMAIL PROTECTED]> on Thu, 31 Oct 2002
22:44:33 +0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:
>
> rt> The "authorityKeyIdentifier" extension seems to behave weirdly...
> rt>
> rt> I have a two level CA architecture:
> rt> ROOT CA
> rt> INTERMEDIATE CA
> rt> For both CA:
> rt> authorityKeyIdentifier = keyid,issuer:always
> rt>
> rt> ROOT CA's authorityKeyIdentifier extension gives its own DN as issuer
(normal)
> rt> INTERMEDIATE CA's authorityKeyIdentifier extension gives ROOT CA's DN
as issuer (normal)
> rt> A certificate signed by INTERMEDIATE CA, gives ROOT CA's DN as issuer
(not normal), shouldn't it be INTERMEDIATE CA's DN ? since the issuer of
this certificate is INTERMEDIATE CA and not ROOT CA.
> rt>
> rt> So I looked at the source code, and I found:
> rt>
> rt> crypto/x509v3/v3_akey.c:144
> rt>
> rt> cert = ctx->issuer_cert;
> rt> ...
> rt> if((issuer && !ikeyid) || (issuer == 2)) {
> rt>  isname = X509_NAME_dup(X509_get_issuer_name(cert));
> rt>
> rt> So "cert" contains the issuer certificate, and we copy the "cert"'s
issuer DN, and not his DN 
> rt>  isname = X509_NAME_dup(X509_get_subject_name(cert)); would be more
proper no ?
>
> You entirely missed the line following what you show:
>
> serial = M_ASN1_INTEGER_dup(X509_get_serialNumber(cert));
>
> and how those two variables.  Think about it, how are certificates
> refered to?  You can refer to it by subject, which is inprecise, since
> it doesn't specify *one*specific* certificate.  The other way is to
> refer to it with issuer and serial number, which should match exactly
> one and only one certificate (unless the issuer has fucked up the
> serial number sequencer).
>
> So, what is stored in the authorityKeyId extension is the issuer and
> serial number of the intermediate CA, which refers to one specific
> certificate that belongs to that intermediate CA, as well as the key
> ID.
>
> This is not an error.
>
> --
> Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
> Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
> \  SWEDEN   \ or +46-708-26 53 44
> Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
> Member of the OpenSSL development team: http://www.openssl.org/
>
> Unsolicited commercial email is subject to an archival fee of $400.
> See <http://www.stacken.kth.se/~levitte/mail/> for more info.
>
>

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

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-10-31 Thread Richard Levitte - VMS Whacker via RT 

In message <[EMAIL PROTECTED]> on Thu, 31 Oct 2002 22:44:33 
+0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:

rt> The "authorityKeyIdentifier" extension seems to behave weirdly...
rt> 
rt> I have a two level CA architecture:
rt> ROOT CA
rt> INTERMEDIATE CA
rt> For both CA:
rt> authorityKeyIdentifier = keyid,issuer:always
rt> 
rt> ROOT CA's authorityKeyIdentifier extension gives its own DN as issuer (normal)
rt> INTERMEDIATE CA's authorityKeyIdentifier extension gives ROOT CA's DN as issuer 
(normal)
rt> A certificate signed by INTERMEDIATE CA, gives ROOT CA's DN as issuer (not 
normal), shouldn't it be INTERMEDIATE CA's DN ? since the issuer of this certificate 
is INTERMEDIATE CA and not ROOT CA.
rt> 
rt> So I looked at the source code, and I found:
rt> 
rt> crypto/x509v3/v3_akey.c:144
rt> 
rt> cert = ctx->issuer_cert;
rt> ...
rt> if((issuer && !ikeyid) || (issuer == 2)) {
rt>  isname = X509_NAME_dup(X509_get_issuer_name(cert));
rt> 
rt> So "cert" contains the issuer certificate, and we copy the "cert"'s issuer DN, and 
not his DN 
rt>  isname = X509_NAME_dup(X509_get_subject_name(cert)); would be more proper no ?

You entirely missed the line following what you show:

serial = M_ASN1_INTEGER_dup(X509_get_serialNumber(cert));

and how those two variables.  Think about it, how are certificates
refered to?  You can refer to it by subject, which is inprecise, since
it doesn't specify *one*specific* certificate.  The other way is to
refer to it with issuer and serial number, which should match exactly
one and only one certificate (unless the issuer has fucked up the
serial number sequencer).

So, what is stored in the authorityKeyId extension is the issuer and
serial number of the intermediate CA, which refers to one specific
certificate that belongs to that intermediate CA, as well as the key
ID.

This is not an error.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.

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

Re: [openssl.org #323] Bug in "authorityKeyIdentifier" extension ?

2002-10-31 Thread Richard Levitte - VMS Whacker 
In message <[EMAIL PROTECTED]> on Thu, 31 Oct 2002 22:44:33 
+0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:

rt> The "authorityKeyIdentifier" extension seems to behave weirdly...
rt> 
rt> I have a two level CA architecture:
rt> ROOT CA
rt> INTERMEDIATE CA
rt> For both CA:
rt> authorityKeyIdentifier = keyid,issuer:always
rt> 
rt> ROOT CA's authorityKeyIdentifier extension gives its own DN as issuer (normal)
rt> INTERMEDIATE CA's authorityKeyIdentifier extension gives ROOT CA's DN as issuer 
(normal)
rt> A certificate signed by INTERMEDIATE CA, gives ROOT CA's DN as issuer (not 
normal), shouldn't it be INTERMEDIATE CA's DN ? since the issuer of this certificate 
is INTERMEDIATE CA and not ROOT CA.
rt> 
rt> So I looked at the source code, and I found:
rt> 
rt> crypto/x509v3/v3_akey.c:144
rt> 
rt> cert = ctx->issuer_cert;
rt> ...
rt> if((issuer && !ikeyid) || (issuer == 2)) {
rt>  isname = X509_NAME_dup(X509_get_issuer_name(cert));
rt> 
rt> So "cert" contains the issuer certificate, and we copy the "cert"'s issuer DN, and 
not his DN 
rt>  isname = X509_NAME_dup(X509_get_subject_name(cert)); would be more proper no ?

You entirely missed the line following what you show:

serial = M_ASN1_INTEGER_dup(X509_get_serialNumber(cert));

and how those two variables.  Think about it, how are certificates
refered to?  You can refer to it by subject, which is inprecise, since
it doesn't specify *one*specific* certificate.  The other way is to
refer to it with issuer and serial number, which should match exactly
one and only one certificate (unless the issuer has fucked up the
serial number sequencer).

So, what is stored in the authorityKeyId extension is the issuer and
serial number of the intermediate CA, which refers to one specific
certificate that belongs to that intermediate CA, as well as the key
ID.

This is not an error.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]