Re: [Ejbca-develop] X/509 Extensions

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Ok, I see. Thanks. I am trying to multitask this project, and
hopefully complete in a short time frame, but some of this is new to
me, so I really appreciate the help.

On 2/23/06, Tomas Gustavsson <to...@pr...> wrote:
>
> Not quite. I would recommend that you copy an existing extension and crea=
te a
> new one similar to it but with another name. You also need your own objec=
tId for
> your private extension.
> Your CustomCertificateProfile will extend the existing CertificateProfile=
, and
> only add your new values.
> After this you will have to add your extension in X509CA.createCertificat=
e so it
> is added to certificates if the certificate profiles says that it should =
be used.
>
> I don't think you can use one already defined extension to use for your s=
tuff,
> they all have very specific purposes and most require specific formats, l=
ike
> subject alternative name that must be a uri, email,... etc.
>
> There are probably some extensions that YOU will not use, like OCSP servi=
ce
> locator, but they are for sure used by others.
> If you want to use an already existing extension your best shot is probab=
ly to
> add uris and dns names in subjectAlternativeNames. You can add multiple u=
rls etc
> there. Perhaps that's good enough for your authorization purposes?
>
> /Tomas
>
> Jordan Rivington wrote:
> > Ok, so what you are saying it, that the best option is to take an
> > extension already defined in EJBCA (CertificateProfile) (or at least
> > one recognized by EJBCA) but one that would not be used by default in
> > my CustomCertificateProfile.java and then use it for my own end? That
> > would require no code modification in EJBCA?
> >
> > In your opinion, which are the least used extensions in
> > CertificateProfile? If that is the wrong question, where would I find
> > a list of premade extension values (in rfc?), so I can select one to
> > use.
> >
> > Thanks for the patience, and I hope I am not asking too many questions.
> >
> > On 2/23/06, Ejbca Support <ejb...@pr...> wrote:
> >> Hi Jordan,
> >>
> >> The problem is not the definition of the Extension asn.1 (because that
> >> is the same for ALL extensions) itself but the 'extnValue '. The
> >> extension value is the DER encoding of the extension itself. For examp=
le
> >> is the definition of the CertificatePolicies extension 44 lines of asn=
.1
> >> (see rfc3280).
> >> A simple extension such as the SubjectKeyIdentifier is:
> >> -----
> >> id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=3D  { id-ce 14 }
> >>
> >> SubjectKeyIdentifier ::=3D KeyIdentifier
> >>
> >> KeyIdentifier ::=3D OCTET STRING
> >> ----
> >> And it can't get any simpler than that..
> >>
> >> You can NOT customize the Extensions asn.1 definition as you say,
> >> because your certificate would break the standard an no-one would be
> >> able to parse it. What you have to do is write your own definition of
> >> the extension value similar to SubjectKeyIdentifier above.
> >>
> >> What would be possible in EJBCA is to take a pre-made 'extnValue' (der
> >> encoded entension value) and an extension object identifier and add th=
e
> >> extension to the cert. The asn.1 coding of the private extension must =
be
> >> provided by the person defining the private extension (it's kind of th=
e
> >> definition of "private").
> >>
> >> Regarding rfc3280:
> >> EJBCA does not issue certificates with 'name constraints' or 'policy
> >> constraints'. Here you must understand that EJBCA is not an
> >> "application" that parses users certificates, EJBCA only issues
> >> certificates. We have no need to read the values of name- or policy
> >> constraints of certificates. The 'MUST' requirement you are pointing t=
o
> >> is a must for applications verifying certificates to be able to
> >> recognize the extensions. It is not a MUST for CAs to ISSUE certificat=
es
> >> with those extensions in them. The verification of certificates that
> >> EJBCA does (it is only for access to the admin GUI) handles everything
> >> nicely, it is Tomcat that does that.
> >>
> >> It is rare to use name constraints and policy constraints and I would
> >> not recommend any one to use those extension, and no-one has requested
> >> EJBCA to issue certificates with those extension either. I have never
> >> seen them in the wild.
> >>
> >> You don't have to worry about specific details of rfc3280, we are not
> >> violating it. Trust me :-)
> >>
> >> Cheers,
> >> Tomas
> >>
> >> Jordan Rivington wrote:
> >>> Well, I suppose I need private extensions. The ASN.1 definition is
> >>> provided in RFC 2549. Couldn't I use the existing ASN.1 definition fo=
r
> >>> an extension:
> >>>
> >>>    Extensions  ::=3D  SEQUENCE SIZE (1..MAX) OF Extension
> >>>
> >>>    Extension  ::=3D  SEQUENCE  {
> >>>         extnID      OBJECT IDENTIFIER,
> >>>         critical    BOOLEAN DEFAULT FALSE,
> >>>         extnValue   OCTET STRING  }
> >>>
> >>> I suppose this would have to be custmomized to fit my extension
> >>> though. How difficult would it be to include this into something like
> >>> CustomUserProfile which would extend CertificateProfile?
> >>>
> >>> Then, I could add a extension for the xml formatted reputation inform=
ation.
> >>>
> >>>
> >>>
> >>> Also, the RFC syas....
> >>>
> >>>    At a minimum, applications conforming to this profile MUST recogni=
ze
> >>>    the extensions which must or may be critical in this specification=
.
> >>>    These extensions are:  key usage (see sec. 4.2.1.3), certificate
> >>>    policies (see sec. 4.2.1.5), the subject alternative name (see sec=
.
> >>>    4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints
> >>>    (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and
> >>>    extended key usage (see sec. 4.2.1.13).
> >>>
> >>> I know EJBCA supports
> >>>    key usage (see sec. 4.2.1.3), certificate policies (see sec.
> >>> 4.2.1.5), the subject
> >>>    alternative name (see sec. 4.2.1.7), basic constraints (see sec.
> >>> 4.2.1.10), and extended
> >>>    key usage (see sec. 4.2.1.13).
> >>>
> >>> But what about support for:
> >>>   name constraints (see sec. 4.2.1.11), policy constraints (see sec. =
4.2.1.12)
> >>>
> >>> I didnt see them in CertificateProfile.
> >>>
> >>> Thanks
> >>>
> >>> Jordan
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> This SF.net email is sponsored by: Splunk Inc. Do you grep through lo=
g files
> >>> for problems?  Stop!  Download the new AJAX search engine that makes
> >>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUN=
K!
> >>> http://sel.as-us.falkag.net/sel?cmd__________________________________=
_____________
> >>> Ejbca-develop mailing list
> >>> Ejb...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >>>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by xPML, a groundbreaking scripting lan=
guage
> >> that extends applications into web and mobile media. Attend the live w=
ebcast
> >> and join the prime developer group breaking into this new coding terri=
tory!
> >> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&da=
t=3D121642
> >> _______________________________________________
> >> Ejbca-develop mailing list
> >> Ejb...@li...
> >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >>
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang=
uage
> > that extends applications into web and mobile media. Attend the live we=
bcast
> > and join the prime developer group breaking into this new coding territ=
ory!
> > http://sel.as-us.falkag.net/sel?cmd____________________________________=
___________
> > Ejbca-develop mailing list
> > Ejb...@li...
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>