Hi, there. I have been looking at the RFC trying to make sense of what the difference
between the .8 and .5 syntaxes are. Any ideas?
I'll have to see if we can change the syntax for the UserCertificate field. It appears
to be preset with the only option being a checkbox to enable or disable binary for the
attribute.
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: [EMAIL PROTECTED]
> Rechenzentrum - Datacenter Email (work):
> [EMAIL PROTECTED]
> 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
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/openca-users
--
********************************
David William Botsch
[EMAIL PROTECTED]
********************************
_______________________________________________
Openca-Users mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/openca-users
