>From: Ashok C [mailto:ash....@gmail.com]
>Sent: Saturday, 28 July, 2012 01:21
>Thanks Dave. But main use case for me is the trust anchor update case.
>I have a certain requirement which goes like this:
>I have a client application which runs on my machine and it will attempt
>to connect to multiple remote servers.
>At time T0:
>Client has old root. All servers have old end entity, connection goes fine.
>At time T1:
>Trust anchor updates itself and my client gets hold of the new root.
>But at the same time it will not delete the old root since some servers
>would not yet have procured the new end entity from the new root.
>At this time, both roots would be present in my trust store. And I will
>need to form the right certificate chain ... For this, I would need
>the AKI/SKI related checks. Since the issuer-id subject-name fields
>of both old as well as new root would be same.
Will they? Most public CAs use different names. *Similar*, like
Verisign blah blah G3 and Verisign blah blah G4, but different.
If you are using a CA where DN is kept the same, yes you need AKI*,
or else you need to do trial and error. Good luck. (* Technically
this could be AKI->IssuerAndSerial, as long as serial is unique,
instead of AKI->SKI. But I've not seen anyone use that.)
>And regarding the "some even don't have AKI/SKI", I read the RFC and
>it mandates the presence of these extensions in all conforming CAs.
Conforming, yes. In the real world, it isn't always true that everybody
conforms. But at least when they're not conforming, you can tell your
users to blame them. That usually helps for about 5 minutes.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
