vt-crypt: Please add SURNAME in edu.vt.middleware.crypt.x509.types.AttributeType

[GoogleCodeExporter]

Would it be possible to add an item for SURNAME in 
edu.vt.middleware.crypt.x509.types.AttributeType

It has to be SURNAME and not SN, because it is used in Estonian personal 
identification (i.e. Estonian ID card) certificates. Although this does not 
correspond to LDAP schema, unfortunately ESTEID certificates cannot be fully 
parsed without this addition.

Original issue reported on code.google.com by toi...@gmail.com on 8 Aug 2011 at 4:23

[GoogleCodeExporter]

I just noticed that only in Java are the attributes named GIVENNAME and 
SURNAME. All other utilities (eg OpenSSL, Windows) display these attributes as 
GN and SN. Nevertheless, SURNAME is still needed in 
edu.vt.middleware.crypt.x509.types.AttributeType

Original comment by toi...@gmail.com on 9 Aug 2011 at 9:36

[GoogleCodeExporter]

Can you cite a reference for your observation about the attribute names?  In 
any case the attributes mentioned in AttributeType are ones defined by a couple 
different X.509 RFCs in addition to some others that Java supports.  I would be 
reluctant to add another attribute without some kind of standard behind it.  If 
it turns out that there is no such standard, I believe we're looking at a much 
larger scope of feature request where we would need to expose hooks for 
arbitrary third-party attribute extension values.  It would be very helpful if 
you could share some sample code of how you are using or intend to use vt-crypt 
to guide future discussion.

Original comment by marvin.addison@gmail.com on 10 Aug 2011 at 12:33

[GoogleCodeExporter]

I did some background checking and I have found the following:
 - the OIDs used in the certificate are 2.5.4.42 for given name and 2.5.4.4 name. RFC4519 names 2.5.4.4 as SN (section 2.32) but also as SURNAME (see section 4)
 - OpenSSL for example uses short names as follows: 2.5.4.42 = GN and 2.5.4.4 = SN, although in RFC4519 only GIVENNAME is assigned to 2.5.4.42 (GN is reserved in section 4).
 - Java parses and sees DN as follows: 2.5.4.42 = GIVENNAME and 2.5.4.4 = SURNAME.

OpenSSL with nameopt rfc2253 prints DN from my certificates as follows:
serialNumber=30000000000,GN=T\C3\95IVO,SN=LEEDJ\C3\84RV,CN=LEEDJ\C3\84RV\,T\C3\9
5IVO\,30000000000,OU=authentication,O=ESTEID,C=EE
Java output of DN is on the other hand as follows:
SERIALNUMBER=30000000000, GIVENNAME=TÕIVO, SURNAME=LEEDJÄRV, 
CN="LEEDJÄRV,TÕIVO,30000000000", OU=authentication, O=ESTEID, C=EE

So interestingly enough, from OpenSSL (and, for example, Windows cert 
management tool) I get GN, which is not in RFC4519, and SN, which appears to be 
OK by RFC4519. And from Java I get GIVENNAME, which is OK by RFC4519 and 
SURNAME, which also appears to be OK by RFC4519.

I don't know if Section 4 of RFC4519 is quite relevant in this context. All in 
all, I guess I could just use OIDs as AttributeTypes, but this is not quite as 
easily understood by human readers.

Original comment by toi...@gmail.com on 10 Aug 2011 at 11:46

[GoogleCodeExporter]

ISO/IEC 9594-6 does probably specify surname as well, although I do not have 
access to that standard myself.

Original comment by toi...@gmail.com on 10 Aug 2011 at 12:00

[GoogleCodeExporter]

I appreciate your thorough analysis from which I conclude the following:

There are discrepancies in the rendering of attributes 2.5.4.42 (GN or 
GIVENNAME) and 2.5.4.4 (SN or SURNAME) in the routines that produce a string 
representation of a DN in various SSL libraries.

It's our rich appreciation of this fact that drove the creation of 
RDNSequenceIterator and related components in order to have strict control over 
the String representation of DNs.  If your use case is string representation of 
DNs, there's a good chance we can help.

It's still unclear whether your SURNAME attribute is, in fact, 2.5.4.4.  Also 
it's not clear what you're attempting to do with vt-crypt.  I'm hopeful I can 
help you if you share your use case (and possibly some sample/pseudo code).

Original comment by marvin.addison@gmail.com on 10 Aug 2011 at 12:57

[GoogleCodeExporter]

Here is the output from OpenSSL:
    Subject:
        2.5.4.6 = EE
        2.5.4.10 = ESTEID
        2.5.4.11 = authentication
        2.5.4.3 = LEEDJ\C4RV,T\D5IVO,30000000000
        2.5.4.4 = LEEDJ\C4RV
        2.5.4.42 = T\D5IVO
        2.5.4.5 = 30000000000

Sorry, I somehow forgot to add more context info. Actually I am not directly 
using vt-crypt, but through CAS (http://www.jasig.org/cas). Specifically 
org.jasig.cas.adaptors.x509.authentication.principal.X509CertificateCredentialsT
oSubjectPrinciplalResolver

The code there is as follows:
    values = DNUtils.getAttributeValues(
        certificate.getSubjectX500Principal(),
        AttributeType.fromName(name));

The variable name is parsed from a String parameter that is provided by me and 
is currently: "$GIVENNAME $SURNAME"
CAS code parses this string and replaces attribute names with respective values 
from the certificate.

Original comment by toi...@gmail.com on 10 Aug 2011 at 1:11

[GoogleCodeExporter]

I believe I can help.  The following should work:

{{{
<bean
  class="org.jasig.cas.adaptors.x509.authentication.principal.X509CertificateCredentialsToSubjectPrinciplalResolver"
 p:descriptor="$GIVENNAME $SN" />
}}}

Unfortunately that likely will not work due to an obvious bug in AttributeType 
at lines 92-93:

  /** SN - RFC 4519 section 2.32. */
  Surname("2.5.4.4", "STREET"),

I've committed a fix in r2054 that will hopefully resolve your problems.  I can 
provide instructions for building a patched CAS server if needed.

Original comment by marvin.addison@gmail.com on 11 Aug 2011 at 3:31

[GoogleCodeExporter]

Mark issue status "Started" retroactively.

Original comment by marvin.addison@gmail.com on 11 Aug 2011 at 3:32

• Changed state: Started

[GoogleCodeExporter]

Thank you. It is such an obvious solution and should indeed work. I think I can 
manage on my own from here.

Original comment by toi...@gmail.com on 11 Aug 2011 at 4:14

[GoogleCodeExporter]

The typo in AttributeType was responsible, at least in part, for the problems 
of the submitter.  Closing issue since submitter claims this fix is sufficient.

Original comment by marvin.addison@gmail.com on 14 Aug 2011 at 6:29

• Changed state: Fixed