On 3.3.2014 14:52, Stef Walter wrote:
On 03.03.2014 14:30, Petr Spacek wrote:
On 3.3.2014 13:49, Jan Cholasta wrote:
On 3.3.2014 12:51, Ludwig Krispenz wrote:
starting a new thread, after a lot of discussion and feedback, which I
tried to integrate into thecurrent draft at:
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema
I have added couple links and typo fixes to the document. Please add
externals links when referring to some other standard so other people
don't need to dig related links again and again. (I have added links for
PKCS#8 and PKCS#11.)
What is this for? This seems pretty wild :)
This is for
<https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC> and
<http://www.freeipa.org/page/V3/CA_certificate_renewal>, see
<http://www.freeipa.org/page/V3/PKCS11_in_LDAP> for overview.
Here are some design decisions I made and which need to be finally
decided.
1] Add nss trust objects.
These are not defined in the PKCS#11 standard, but Jan said they will be
needed and I added them to the spec
For the record, here are some details about NSS trust objects:
<http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html>
Right, the NSS trust objects are definitely not an extensible scheme.
What's your use case. Don't you already have other ways in LDAP of
indicating trust in a certificate?
The use case is to store NSS trust flags in LDAP along with CA certificates.
This link definitely should be somewhere in design docs.
BTW, there are some additional attributes defined in
/usr/include/nss3/pkcs11n.h besides these mentioned in the link above:
And this too... Feel free to upload the file to wiki if you didn't find
any on-line repo suitable for direct linking from design docs.
CKA_TRUST_IPSEC_END_SYSTEM
CKA_TRUST_IPSEC_TUNNEL
CKA_TRUST_IPSEC_USER
CKA_TRUST_TIME_STAMPING
CKA_TRUST_STEP_UP_APPROVED
Can you please add them as well?
2] Certificate representation
In pkcs11 there is a certificate category (user, authority, ..) and
certificate value. An alternate way to represent this would be to use
the schema defined in rfc4523 and map
(user, value) --> (objectclass: pkiUser, usercertificate) and
(authority, value) --> (objectclass: pkiCA, cAcertificate)
I kept the attributes pkcs11certificateCategory and
pkcs11certificateValue and let the applications decide which format will
be used.
Applications talking to PKCS#11 do not need to be concerned with this and
applications talking to LDAP will be only us.
I would like to emphasis Rob's idea that this schema is IPA-specific for
now but we should assume that other PKCS#11<->LDAP implementations can
exist.
And also NSS specific, given the storage of NSS trust.
I think we can make that conditional, i.e. by using an environment
variable or the reserved argument in C_Initialize (like NSS does).
If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust
objects from the module?
Cheers,
Stef
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
