cert naming (was: Re: kdesupport/qca/plugins/qca-pkcs11)

On Saturday 07 April 2007 10:37 am, Alon Bar-Lev wrote:
> On 4/7/07, Justin Karneges <justin-psi2affinix.com> wrote:
> > One approach might be to start with just the CN by
default, and gradually
> > add details depending on the differences with
other certs in the same
> > storage. This would require the name generator to
know about the other
> > certs though, but it probably isn't too complex?
>
> Right...
> It should be run in runtime at asker time based on all
available
> public objects in all available stores.
>
> > Maybe something like:
> >   QStringList makeFriendlyNames(const
QList<Certificate> &certs);
> >
> > You'd call it once at the end of a token
enumeration.
>
> No...no... no...
> The framework should get all available certificates
from all the
> stores... If I call this when I construct the entry I
may have partial
> picture.

If you assign the names at the end of enumeration, then you
won't have a 
partial picture.  I think it is plenty for the names to be
unique within the 
scope of a single store.

Also, it is important to assign names at the point of
enumeration, and not at 
asker time, so that entryList provides good names (for
example, if the app is 
displaying a cert chooser).

I think this function is fine.

> > Which info fields are used?  What are the letters
for each?  Are there
> > fields without letters?  Etc.  I don't know how
these strings work.  
> > Is there a specification for this or is it just a
convention?  If it is a
> > convention, would you attribute it to OpenSSL or
some other project?
> > (good to know for naming the function as well as
documenting it).
>
> Except of Microsoft example and OpenSSL, you can refer
to Java or RFCs:
> http://www.faqs
.org/rfcs/rfc1779.html
>
> As I understand, the letters are defined in X.500 at
ISO/IEC 9594-1,
> but you need to buy these documents in order to read
them...
>
> If you don't have a corresponding letter you just put
the oid...
> For example:
> CN=Alon Bar-Lev, C=IL, oid_1.2.3.4=Male

OIDs are allowed in DNs?  I thought DNs were not extensible,
and this is what 
altname is for.  Also, if OIDs are allowed, how do you know
how to print the 
value?  (at least, the value for altname/othername is an
ASN.1 data blob, 
basically unprintable if you're not looking for something
specific).

-Justin
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On 4/7/07, Justin Karneges <justin-psi2affinix.com> wrote:
> If you assign the names at the end of enumeration, then
you won't have a
> partial picture.  I think it is plenty for the names to
be unique within the
> scope of a single store.
>
> Also, it is important to assign names at the point of
enumeration, and not at
> asker time, so that entryList provides good names (for
example, if the app is
> displaying a cert chooser).
>
> I think this function is fine.

OK... You are the boss...
Although I disagree that the provider should handle any
functionality
that is common to all providers, and can be easily
implemented by the
core framework.

> OIDs are allowed in DNs?  I thought DNs were not
extensible, and this is what
> altname is for.  Also, if OIDs are allowed, how do you
know how to print the
> value?  (at least, the value for altname/othername is
an ASN.1 data blob,
> basically unprintable if you're not looking for
something specific).

As far as I know they are extensible... And as far as I
know, all are
PRINTABLESTRING or somekind of other string such as
IA5STRING.

Best Regards,
Alon Bar-Lev.
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com