Description Brian Walker 2009-03-25 12:39:53 EDT

Noted from a test that John Bradley ran: 

On Mar 22, 2009, at 5:03 PM, John Bradley wrote:

I have a head scratcher for you.

I have RPs set up with different certs.
https://start-class2.test-id.net:8444/RP/InfoCardPpid.aspx
E = hostmaster@test-id.net
CN = start-class2.test-id.net
OU = StartCom Verified Certificate Member
O = John Bradley
L = Vancouver
ST = British Columbia
C = CA

E = hostmaster@test-id.net
CN = *.test-id.net
OU = StartCom Verified Certificate Member
O = John Bradley
L = Vancouver
ST = British Columbia
C = CA

I point you to the IMI spec sec 7.6.1 and ISIP 1.5
Convert the organizational identifier attributes in the end-entity certificate into a string, call it
OrgIdString, of the following form:
|O="string"|L="string"|S="string"|C="string"|
The vertical bar character (ASCII 0x7C) is used as a delimiter at the start and end of the string as
well as between the attribute types. Further, the string values of the individual attribute types are
enclosed within double quote characters (ASCII 0x22). If an attribute type is absent in the subject
field of the end-entity certificate, then the corresponding string value is the empty string ("").
Following is an example OrgIdString per this convention.
|O="Microsoft"|L="Redmond"|S="Washington"|C="US"|

Yes for the sharp eyed amongst you there is a mistake in the spec I just found S is actually ST in the X.509 spec.

Assuming the programers did the correct thing and used "|Non-EV|O="John Bradley"|L="Vancouver"|ST="British Columbia"|C="CA|"

The RP PPID Seed and hence the PPID should be identical between them.

I know you saw this coming they are not!

I surmise that ether the error in the spec or something else is triggering the STS to use the wrong algorithem for generating the RP PPID seed.

You may hate me but better to find this now.

Regards
John B.