Re: ITS#5072 incorrect certificateExactAssertion()

[hyc@symas.com]

ando@sys-net.it wrote:
> hyc@symas.com wrote:
>> Yes, it looks like we're using an invalid format for the issuer component. 
>> Seems like using the GSER format is a bit harder to parse, since we have no 
>> reliable indicator of where the rdnSequence ends. Any thoughts?
> 
> In general, I agree.  In this specific case, it ends at the end of the 
> octetString :)

I take that back. Section 3.20 of RFC3641 says
 >>>
3.20.  Variant Encodings

    The values of some named complex ASN.1 types have special string
    encodings.  These special encodings are always used instead of the
    encoding that would otherwise apply based on the ASN.1 type
    definition.

       VariantEncoding = RDNSequenceValue /
                         RelativeDistinguishedNameValue /
                         ORAddressValue

    A value of the RDNSequence type, i.e., a distinguished name, is
    encoded according to the <RDNSequenceValue> rule, as a quoted LDAPDN
    character string.  The character string is first derived according to
    the <distinguishedName> rule in Section 3 of RFC 2253 [5], and then
    encoded as if it were a UTF8String value, i.e., between double quotes
    with any embedded double quotes escaped by being repeated.
<<<

I.e., the sequence should be enclosed in double quotes. So your example should be

{
     serialNumber 3,
     issuer rdnSequence:"email=ca@example.com,cn=example ca,o=example,st=xx,
       c=us"
}

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/