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" }