Re: kdesupport/qca/plugins/qca-pkcs11

On Saturday 07 April 2007 9:06 am, Alon Bar-Lev wrote:
> On 4/7/07, Justin Karneges <justin-psi2affinix.com> wrote:
> > > On 4/7/07, Alon Bar-Lev <alon.barlevgmail.com> wrote:
> > > > A few thoughts...
> > > > 1. I would like the PIN prompt to prompt
the token name as the token
> > > > prompt does. The PIN is actually
requested for the token and not for
> > > > the key, the key should be a comment
like information.
> >
> > Hmm, maybe in this case, don't pass an entry? 
Then the token will be
> > prompted for instead.
>
> Hmmm... This is what I requested initially...

Entry has always been optional for the password prompt, and
recently it is 
also optional for the token prompt.

Earlier, I said that passing the entry is a neat thing to
do, and this is what 
we do for gpg.  However, in the case of gpg, the entry is
protected, not the 
whole keyring, so it makes sense in this context.  However,
if you're 
prompting for the PIN of the entire token, then don't pass
the entry.  Sorry 
for the confusion.

> > good source, we could come up with a simple scheme
(e.g. "$CN from $O").
>
> Well... this is for high-level API to decide...
> Again... I think I should only provide my objects...
Higher API should
> decide how to display them... As always... I wish to
reduce
> functionality  of the provider... 

Maybe we can have 2 functions in the base QCA: one for
making highly specific 
DN-strings and one for making friendly entry name strings? 
You could call 
the second one to fill in the entry.name.

> > I just think that those OpenSSL-ish strings are
very long and not
> > intuitive (only people like us will understand
them).
>
> I don't think so... People are aware of them... Most
people will have
> several certificates with the same CN, one for
authentication, one for
> signature and one for decryption.
> And they can have multiple of these issued by different
CAs.
>
> So how do they know which one is requested?
>
> The best approach is full DN + enhanced key usage...
> But the enhanced key usage turns up to be quite
long...
> So I print only the DN.

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?

Maybe something like:
  QStringList makeFriendlyNames(const
QList<Certificate> &certs);

You'd call it once at the end of a token enumeration.

> > If you still want to be able to construct those
strings, maybe we could
> > make a public function to calculate them.  Is
there a specification
> > somewhere?  Or can you describe the process?
>
> I don't understand.

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).

> > There are two E values because of the Email DN and
the Email
> > subjectAltName. Any suggestion?
>
> Oh!!!!
> I did not expect subjectInfoOrdered  to scan the name
and altname...
> Please provide two methods.

Yes, those info containers hold all info.  However, Email is
the only one with 
that merging property.  I'll add another field called
EmailAlt, and then 
there will be no merging, at least for the ordered
container.

-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:
> Maybe we can have 2 functions in the base QCA: one for
making highly specific
> DN-strings and one for making friendly entry name
strings?  You could call
> the second one to fill in the entry.name.

OK.

> 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.

> 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

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