On 1.8.2014 15:34, Simo Sorce wrote:
On Fri, 2014-08-01 at 14:31 +0200, Jan Cholasta wrote:
>Dne 1.8.2014 v 13:54 Simo Sorce napsal(a):
> >I have a questions about algorithms agility though, are we tied to use
> >AES128 and RSA2048 ? Or do we have the means to specify and use
> >alternative alg
On Fri, 2014-08-01 at 14:31 +0200, Jan Cholasta wrote:
> Dne 1.8.2014 v 13:54 Simo Sorce napsal(a):
> > On Tue, 2014-07-29 at 11:49 +0200, Jan Cholasta wrote:
> >
> >> I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going
> >> to comment the steps from the link above here:
> >
> >
Dne 1.8.2014 v 13:54 Simo Sorce napsal(a):
On Tue, 2014-07-29 at 11:49 +0200, Jan Cholasta wrote:
I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going
to comment the steps from the link above here:
I think anyone with a fedora login can change it, but thanks anyway, you
cla
On 08/01/2014 01:54 PM, Simo Sorce wrote:
> On Tue, 2014-07-29 at 11:49 +0200, Jan Cholasta wrote:
>
>> I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going
>> to comment the steps from the link above here:
>
> I think anyone with a fedora login can change it, but thanks anywa
On Tue, 2014-07-29 at 11:49 +0200, Jan Cholasta wrote:
> I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going
> to comment the steps from the link above here:
I think anyone with a fedora login can change it, but thanks anyway, you
clarified quite some things.
I have a questi
Dne 29.7.2014 v 08:56 Simo Sorce napsal(a):
On Tue, 2014-07-29 at 08:46 +0200, Jan Cholasta wrote:
Dne 28.7.2014 v 11:04 Simo Sorce napsal(a):
On Fri, 2014-07-25 at 19:26 +0200, Petr Spacek wrote:
I have updated design page and diagrams:
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Des
On Tue, 2014-07-29 at 08:46 +0200, Jan Cholasta wrote:
> Dne 28.7.2014 v 11:04 Simo Sorce napsal(a):
> > On Fri, 2014-07-25 at 19:26 +0200, Petr Spacek wrote:
> >>
> >> I have updated design page and diagrams:
> >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#LDA
Dne 28.7.2014 v 11:04 Simo Sorce napsal(a):
On Fri, 2014-07-25 at 19:26 +0200, Petr Spacek wrote:
I have updated design page and diagrams:
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#LDAPschema
Excellent page, I took a full read and it all seem reasonable.
On Fri, 2014-07-25 at 19:26 +0200, Petr Spacek wrote:
>
> I have updated design page and diagrams:
> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#LDAPschema
Excellent page, I took a full read and it all seem reasonable.
However I would like a page like this wi
On 17.7.2014 10:30, Jan Cholasta wrote:
On 16.7.2014 17:13, Petr Spacek wrote:
On 24.6.2014 08:43, Jan Cholasta wrote:
On 20.6.2014 20:23, Simo Sorce wrote:
On Fri, 2014-06-20 at 20:04 +0200, Petr Spacek wrote:
ipk11Private;privatekey: TRUE
ipk11Private;publickey: FALSE
can these two ever h
On 16.7.2014 17:13, Petr Spacek wrote:
On 24.6.2014 08:43, Jan Cholasta wrote:
On 20.6.2014 20:23, Simo Sorce wrote:
On Fri, 2014-06-20 at 20:04 +0200, Petr Spacek wrote:
ipk11Private;privatekey: TRUE
ipk11Private;publickey: FALSE
can these two ever hold a different value ?
ie a privatekey b
On 24.6.2014 08:43, Jan Cholasta wrote:
On 20.6.2014 20:23, Simo Sorce wrote:
On Fri, 2014-06-20 at 20:04 +0200, Petr Spacek wrote:
ipk11Private;privatekey: TRUE
ipk11Private;publickey: FALSE
can these two ever hold a different value ?
ie a privatekey be FALSE and a publickey be TRUE ?
If no
On 20.6.2014 20:23, Simo Sorce wrote:
On Fri, 2014-06-20 at 20:04 +0200, Petr Spacek wrote:
ipk11Private;privatekey: TRUE
ipk11Private;publickey: FALSE
can these two ever hold a different value ?
ie a privatekey be FALSE and a publickey be TRUE ?
If not I suggest you do not add this attribute
On Fri, 2014-06-20 at 20:04 +0200, Petr Spacek wrote:
> ipk11Private;privatekey: TRUE
> ipk11Private;publickey: FALSE
can these two ever hold a different value ?
ie a privatekey be FALSE and a publickey be TRUE ?
If not I suggest you do not add this attribute at all and assume their
value ?
(btw
On 12.6.2014 16:23, Petr Spacek wrote:
On 30.4.2014 18:19, Petr Spacek wrote:
following text summarizes schema & DIT layout for DNSSEC key storage in LDAP.
I have added object classes and default values for attributes I consider
important. This is final proposal for implementation. Please revi
On 30.4.2014 18:19, Petr Spacek wrote:
following text summarizes schema & DIT layout for DNSSEC key storage in LDAP.
I have added object classes and default values for attributes I consider
important. This is final proposal for implementation. Please review it ASAP.
This is subset of full P
On 5.5.2014 10:45, Ludwig Krispenz wrote:
Hi Petr,
On 05/02/2014 08:48 PM, Petr Spacek wrote:
On 1.5.2014 16:10, Rich Megginson wrote:
On 04/30/2014 10:19 AM, Petr Spacek wrote:
- We need to decide about object naming:
- One obvious option for RDN is to use uniqueID but I don't like
it. It
Hi Petr,
On 05/02/2014 08:48 PM, Petr Spacek wrote:
On 1.5.2014 16:10, Rich Megginson wrote:
On 04/30/2014 10:19 AM, Petr Spacek wrote:
Hello list,
following text summarizes schema & DIT layout for DNSSEC key storage
in LDAP.
This is subset of full PKCS#11 schema [0]. It stores bare keys w
On 05/02/2014 12:48 PM, Petr Spacek wrote:
On 1.5.2014 16:10, Rich Megginson wrote:
On 04/30/2014 10:19 AM, Petr Spacek wrote:
Hello list,
following text summarizes schema & DIT layout for DNSSEC key storage
in LDAP.
This is subset of full PKCS#11 schema [0]. It stores bare keys with few
me
On 1.5.2014 16:10, Rich Megginson wrote:
On 04/30/2014 10:19 AM, Petr Spacek wrote:
Hello list,
following text summarizes schema & DIT layout for DNSSEC key storage in LDAP.
This is subset of full PKCS#11 schema [0]. It stores bare keys with few
metadata attributes when necessary.
The intenti
On 04/30/2014 10:19 AM, Petr Spacek wrote:
Hello list,
following text summarizes schema & DIT layout for DNSSEC key storage
in LDAP.
This is subset of full PKCS#11 schema [0]. It stores bare keys with
few metadata attributes when necessary.
The intention is to make transition to full PKCS#
Hello list,
following text summarizes schema & DIT layout for DNSSEC key storage in LDAP.
This is subset of full PKCS#11 schema [0]. It stores bare keys with few
metadata attributes when necessary.
The intention is to make transition to full PKCS#11-in-LDAP schema [0] as easy
as possible. Th
22 matches
Mail list logo
