From: Dave B. <dw...@co...> - 2001-08-22 16:10:50
|
I slightly misspoke myself. We do have a syntax setting, however it has choices like "Case Ignore String" and "Binary" . . On Wed, Aug 22, 2001 at 04:46:27PM +0200, Michael Bell wrote: > Dave Botsch wrote: > > I am looking at the userCertificate schema in our directory .. > > First thanks a lot that I can have a look on to your Directoryserver. > > > Description: Standard Attribute > > OID: 2.5.4.36 > > Usage: User applications > > Syntax {length} 1.3.6.1.4.1466.115.121.1.5 > > > > As you can see, all is the same minus the ";binary required" comment and the last digit of the syntax being a 5 and not an 8. > > Hey, that's a good observation. I start searching the RFCs. > > I found the following in the RFCs: > > ################################################ > RFC 2252 > > 4.3.1 Binary Transfer of Values > > This encoding format is used if the binary encoding is requested by > the client for an attribute, or if the attribute syntax name is > "1.3.6.1.4.1.1466.115.121.1.5". The contents of the LDAP > AttributeValue or AssertionValue field is a BER-encoded instance of > the attribute value or a matching rule assertion value ASN.1 data > type as defined for use with X.500. (The first byte inside the OCTET > STRING wrapper is a tag octet. However, the OCTET STRING is still > encoded in primitive form.) > > All servers MUST implement this form for both generating attribute > values in search responses, and parsing attribute values in add, > compare and modify requests, if the attribute type is recognized and > the attribute syntax name is that of Binary. Clients which request > that all attributes be returned from entries MUST be prepared to > receive values in binary (e.g. userCertificate;binary), and SHOULD > NOT simply display binary or unrecognized values to users. > > 6.5. Certificate > > ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' ) > > Because of the changes from X.509(1988) and X.509(1993) and > additional changes to the ASN.1 definition to support certificate > extensions, no string representation is defined, and values in this > syntax MUST only be transferred using the binary encoding, by > requesting or returning the attributes with descriptions > "userCertificate;binary" or "caCertificate;binary". The BNF notation > in RFC 1778 for "User Certificate" is not recommended to be used. > > RFC 2256 > > 5.37. userCertificate > > This attribute is to be stored and requested in the binary form, as > 'userCertificate;binary'. > > ( 2.5.4.36 NAME 'userCertificate' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) > > RFC 2798 > > 2.5.4.36 > NAME 'userCertificate' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) > ################################################ > > So could you please check the schemas of your directoryserver? The > Syntax MUST end with an 8! Please change the number and start again or > did I misinterpret the RFCs? > > If you performed the changes then the attribute should be > "userCertificate;binary" and the value should be $cert->getDER() without > any conversions. > > > The Usersmimecertificate field is the same as above except for an OID of 2.16.840.1.113730.3.1.40 > > userSMIMECertificate requires a PKCS#7-structure. So you cannot use it > with a normal certificate. > > Cheers, > > Michael > -- > ---------------------------------------------------------------------------- > Michael Bell Email: mic...@we... > Rechenzentrum - Datacenter Email (work): > mic...@rz... > Humboldt-University of Berlin Tel.(work): +49 (0)30-2093 2482 > Unter den Linden 6 Fax.(work): +49 (0)30-2093 2959 > 10099 Berlin > Germany [OpenCA Core > Developer] > > http://openca.sourceforge.net > > _______________________________________________ > Openca-Users mailing list > Ope...@li... > http://lists.sourceforge.net/lists/listinfo/openca-users -- ******************************** David William Botsch dw...@co... ******************************** |