From roy at nominet.org.uk  Mon Dec  1 09:40:44 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Mon, 1 Dec 2008 10:40:44 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <E7DE3DD8-E518-41DF-83C0-3D4F68EA2027@jadickinson.co.uk>
References: <69748EBA-0D42-4283-A48D-561A53DE2121@NLnetLabs.nl>
	<OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<OFE4B69301.19C333AF-ON8025750F.005EA6D5-C125750F.00604774@nominet.org.uk>
	<E7DE3DD8-E518-41DF-83C0-3D4F68EA2027@jadickinson.co.uk>
Message-ID: <OFFB61B8F3.CDF64D53-ON80257512.0033E0A8-C1257512.00352B50@nominet.org.uk>

John Dickinson <jad at jadickinson.co.uk> wrote on 11/28/2008 07:03:27 PM:

> On 28 Nov 2008, at 17:31, Roy Arends wrote:
> 
> > Stephen Morris wrote on 11/28/2008 05:47:32 PM:
> >
> >> Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 27/11/2008 16:01:26:
> >>
> >>>
> >>> On Nov 27, 2008, at 4:54 PM, John Dickinson wrote:
> >>>
> >>>>
> >>>> So I guess if you have a large zone like co.uk then a couple of
> >>>> seconds in the 6 odd minutes that it would take to sign from 
> >>>> scratch
> >
> >>>> is nothing. However, if you have 1000's of small zones or you are
> >>>> dynamically updating every minute then it could make a big
> > difference.
> >>>
> >>> But even then... the key-rollover would take place only once per 
> >>> month
> >
> >>> or so. So this 2 second pain per zone only happens once or twice per
> >>> month.
> >>
> >> In this approach, are there any problems in ensuring that the keys 
> >> are
> >> replicated to a backup HSM before they are used?  Do you need any 
> >> type
> > of
> >> "master" password to export private keys from the HSM?
> >
> > I guess in a situation where the procedures require that keys need 
> > to be
> > backed up, it is up to the specific HSM implementation if such a 
> > scenario
> > is possible. Different HSMs use different methods. For instance, to be
> > fully FIPS 140-2 level 3 compliant, the HSM needs to be in complete 
> > "do
> > not export" state, which guarantees that keys stored on an HSM can't 
> > be
> > exported. Another requirement is that "do not export" is irreversible.
> 
> This means that to allow for backup you might want to have the key 
> generation on a separate machine - I did once imagine a system where 
> an offline server generated keys in a "master" HSM. The HSM backup 
> system was then used to copy those keys to HSMs to be attached to the 
> signing server. This would allow the HSMs attached to the signer to be 
> locked (backups not possible). (But then again, can you have one HSM 
> that is the duplicate of another where one is in FIPS 140-2 level 3 
> and one not??)
> 
> >
> > What I think is fairly common is that a keystore (containing the 
> > actual
> > private DNSKEY's) is an encrypted filesystem (the individual files are
> > encrypted, not the directory structure) on a regular disk, while the
> > Keystore Decryption Key (or Master Key, or SuperKey or RootToken, all
> > depending on which vendor you talk to) resides physically in the 
> > HSM. This
> 
> We have had this conversation elsewhere: But WHY? Just use an HSM or 
> soft token for all the keys :)

I think we're not aligned here :-)

1) Backup and Fallback of private DNSKEYs is a requirement for us.
2) private DNSKEYs should never leave an HSM unencrypted.
3) the encryption key must never (EVER!) leave an HSM while in production.

In our design at Nominet, we've satisfied all three requirements.

Surely we could use an HSM where the private DNSKEYs reside on a HSM (ie 
in hardware), but that would be overkill.

> > Decryption key can actually be synchronised between the various HSMs 
> > (of
> > the same brand, as there is currently no standard defined way). 
> > There are
> > different methods to do this. Once the decrytion key is equal on all 
> > HSMs,
> > keystores can be read by all involved HSMs, while the same encrypted
> > keystores (filesystems) can be backed-up, replicated, etc.
> >
> >
> > However, since the methods on key-retrieval, backup, recovery is so
> > incredibly vendor specific, I think that is out of scope. We should 
> > just
> 
> I agree, key backup is outside the scope of OpenDNSSEC and should be 
> done according to the mechanism designed by the HSM manufacturer. 
> Ability to do this would be a consideration when selecting an HSM or 
> soft token.
> 
> However, I do agree with Stephen, an operator might want a chance to 
> know that they had backups before deciding to use a key. Given that 
> backup is likely to be a manual step maybe pre-creation is needed, at 
> least for some people. Maybe we need a backup interval between 
> generation and publication.

Ack.

> >
> > allow the system to be able to pre-generate keys, in order to allow
> > redundant keystores.
> 
> I am a bit confused - is that pre-generate the same as the "So, why 
> not pre-create as many keys as needed, instead of as much as 
> possible?" in the previous email?

Yes.

> BTW - how many is "as many keys as 
> needed"? Enough for the immediate key rollover that the enforcer is 
> trying to do or enough for all the key rollovers planned in the next x 
> minutes?

Enough for the next planned backup procedure. If the backup procedure is 
to be done every six month (say), than you need to have keys that will 
take you past those six months, plus some slack.

> Or should we allow the operator to select pre-generate or only 
> generate the minimum needed?

I don't think these two are comparable. Can you elaborate?

Roy


From roy at nominet.org.uk  Mon Dec  1 09:48:14 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Mon, 1 Dec 2008 10:48:14 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <49305A14.4080704@surfnet.nl>
References: <69748EBA-0D42-4283-A48D-561A53DE2121@NLnetLabs.nl>	<OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<OFE4B69301.19C333AF-ON8025750F.005EA6D5-C125750F.00604774@nominet.org.uk>
	<E7DE3DD8-E518-41DF-83C0-3D4F68EA2027@jadickinson.co.uk>
	<49305A14.4080704@surfnet.nl>
Message-ID: <OF132DBD69.731EE5B7-ON80257512.00353051-C1257512.0035DB58@nominet.org.uk>

Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote on 11/28/2008 
09:52:36 PM:

> Hi all,
> 
> Just thought I'd contribute my 2 cents to the discussion.
> 
> John Dickinson wrote:
> > 
> > On 28 Nov 2008, at 17:31, Roy Arends wrote:
> > 
> >> Stephen Morris wrote on 11/28/2008 05:47:32 PM:
> >>
> >>> Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 27/11/2008 16:01:26:
> >>>
> >>>>
> >>>> On Nov 27, 2008, at 4:54 PM, John Dickinson wrote:
> >>>>
> >>>>>
> >>>>> So I guess if you have a large zone like co.uk then a couple of
> >>>>> seconds in the 6 odd minutes that it would take to sign from 
scratch
> >>
> >>>>> is nothing. However, if you have 1000's of small zones or you are
> >>>>> dynamically updating every minute then it could make a big
> >> difference.
> >>>>
> >>>> But even then... the key-rollover would take place only once per 
month
> >>
> >>>> or so. So this 2 second pain per zone only happens once or twice 
per
> >>>> month.
> >>>
> >>> In this approach, are there any problems in ensuring that the keys 
are
> >>> replicated to a backup HSM before they are used?  Do you need any 
type
> >> of
> >>> "master" password to export private keys from the HSM?
> >>
> >> I guess in a situation where the procedures require that keys need to 
be
> >> backed up, it is up to the specific HSM implementation if such a 
scenario
> >> is possible. Different HSMs use different methods. For instance, to 
be
> >> fully FIPS 140-2 level 3 compliant, the HSM needs to be in complete 
"do
> >> not export" state, which guarantees that keys stored on an HSM can't 
be
> >> exported. Another requirement is that "do not export" is 
irreversible.
> > 
> > This means that to allow for backup you might want to have the key 
> > generation on a separate machine - I did once imagine a system where 
an 
> > offline server generated keys in a "master" HSM. The HSM backup system 

> > was then used to copy those keys to HSMs to be attached to the signing 

> > server. This would allow the HSMs attached to the signer to be locked 
> > (backups not possible). (But then again, can you have one HSM that is 
> > the duplicate of another where one is in FIPS 140-2 level 3 and one 
not??)
> > 
> >>
> >> What I think is fairly common is that a keystore (containing the 
actual
> >> private DNSKEY's) is an encrypted filesystem (the individual files 
are
> >> encrypted, not the directory structure) on a regular disk, while the
> >> Keystore Decryption Key (or Master Key, or SuperKey or RootToken, all
> >> depending on which vendor you talk to) resides physically in the HSM. 

> >> This
> > 
> > We have had this conversation elsewhere: But WHY? Just use an HSM or 
> > soft token for all the keys :)
> > 
> >>
> >> Decryption key can actually be synchronised between the various HSMs 
(of
> >> the same brand, as there is currently no standard defined way). There 
are
> >> different methods to do this. Once the decrytion key is equal on all 
> >> HSMs,
> >> keystores can be read by all involved HSMs, while the same encrypted
> >> keystores (filesystems) can be backed-up, replicated, etc.
> >>
> >>
> >> However, since the methods on key-retrieval, backup, recovery is so
> >> incredibly vendor specific, I think that is out of scope. We should 
just
> > 
> > I agree, key backup is outside the scope of OpenDNSSEC and should be 
> > done according to the mechanism designed by the HSM manufacturer. 
> > Ability to do this would be a consideration when selecting an HSM or 
> > soft token.
> 
> I agree as well, I know of quite a few HSM manufacturers that use the 
> model described above (master key in the HSM, actual key material stored 

> on disk with ways to restore the master key). A good example is nCipher.
> 
> I'm pretty sure each manufacturer provides their own methods for backing 

> up and restoring key material and also for duplicating security worlds 
> across multiple distributed HSMs.
> 
> In my opinion, functionality like key backup should be addressed in 
> something like a manual (it's something operators should at least think 
> about) but should not be solved by OpenDNSSEC.

Exactly. This is what I was referring to with "procedure".

> HSM manufacturers have 
> much more experience in this which should be leveraged. Unfortunately 
> they also have widely varying implementations which makes it hard to 
> specify a single statement on how to go about backing up your keys :-(.
> 
> > However, I do agree with Stephen, an operator might want a chance to 
> > know that they had backups before deciding to use a key. Given that 
> > backup is likely to be a manual step maybe pre-creation is needed, at 
> > least for some people. Maybe we need a backup interval between 
> > generation and publication.
> 
> It's a good point that operators may want to have some assurance about 
> having a backup. The trouble is that it is going to be hard to ascertain 

> this by querying the HSM. There is no 'this key is backed up' flag in 
> PKCS #11. For these reasons I'm doubtful whether there should be a 
> technical facility in OpenDNSSEC to enforce this.

There should not. I agree. 

> What I could imagine 
> is that an operator knows the creation date of a key (which should thus 
> be stored somewhere) and knows the last time the HSM was backed up and 
> can thus manually verify that a backup is available.

Sure.

> >> allow the system to be able to pre-generate keys, in order to allow
> >> redundant keystores.
> > 
> > I am a bit confused - is that pre-generate the same as the "So, why 
not 
> > pre-create as many keys as needed, instead of as much as possible?" in 

> > the previous email? BTW - how many is "as many keys as needed"? Enough 

> > for the immediate key rollover that the enforcer is trying to do or 
> > enough for all the key rollovers planned in the next x minutes?
> 
> Although key generation is computationally expensive, this should not be 

> overestimated. Especially for ZSKs where the key size is likely to be 
> limited to something like 1024 bits, key generation is not that hard to 
> do, especially for some special purpose hardware like a HSM. This only 
> becomes an issue for KSKs which are rolled over far less often. IMHO it 
> should be possible to work out the number of keys that should be kept in 

> store according to some formula based on the number of zones (thus ZSKs 
> and KSKs), the validity period of each key and a worst case scenario 
> where all keys expire at the same time (which is unlikely) and then 
> provide enough keys to roll over each key at least n-times where n is 
> configurable.
> 
> Then there could be a background daemon that chugs away at a lower 
> priority generating key material as needed. On that point: this may 
> require some form of load balancing interface to sit between the 
> processes using the HSM and the HSM itself that decides which has a 
> higher priority (key generation or signing) since I can imagine that 
> there may be a few HSMs that can only do one thing at a time (especially 

> if you include a really cheap HSM: a smart card in a reader).
> 
> > Or should we allow the operator to select pre-generate or only 
generate 
> > the minimum needed?
> 
> Why not make this configurable? I think it should be possible to come up 

> with a sensible default scenario with some formula as I proposed above 
> but leave it up to more experienced administrator to decide on their own 

> policy.
> 
> Another thing I'm pondering is the policy for KSKs. Have you already 
> discussed having one KSK for all zones administered by an OpenDNSSEC box 

> versus having a KSK for each zone? (If you have, forgive me for bringing 

> it up). 
> There are of course risks in having a single KSK (bigger impact 
> if the key is compromised), but benefits as well (less key material 
> floating around, easier to communicate to your parent). And then there 
> are legal issues to consider (who is signing on behalf of whom, 
> especially in the case where an ISP manages many zones for a lot of 
> different entities); there is going to be a point where people start 
> wondering who 'owns' the key material that is used to sign a zone and 
> who is legally responsible for the statement of authenticity that is 
> being given for the signed data.
> 
> Finally, there is one other thing I'd like to bring up (and again, since 

> I don't know the whole history of the discussions you've had before, 
> please ignore it if it's already been discussed and decided on):
> 
> It may make sense to store KSKs in an expensive device like a HSM but to 

> store ZSKs in a soft token (because of limitations in the HSMs storage 
> space, etc. etc.). I would like to point out that it would still make a 
> lot of sense to generate the key material in the HSM because of the 
> better quality key generator in the HSM (care taken to provide entropy, 
> filtering of weak keys, etc.).

It does indeed make sense. We have pondered about it as well.

> These could then be exported in a 
> standard format (have a look at PKCS #8) in wrapped form (e.g. wrapped 
> using a symmetric algorithm) and be imported into the soft token where 
> they are then unwrapped and stored for use.
> 
> Hope I've helped a bit...


Definitely,

Thanks Roland

Roy


From patrik.wallstrom at iis.se  Mon Dec  1 10:52:42 2008
From: patrik.wallstrom at iis.se (Patrik Wallstrom)
Date: Mon, 1 Dec 2008 11:52:42 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <49305A14.4080704@surfnet.nl>
References: <69748EBA-0D42-4283-A48D-561A53DE2121@NLnetLabs.nl>	<OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>	<OFE4B69301.19C333AF-ON8025750F.005EA6D5-C125750F.00604774@nominet.org.uk>
	<E7DE3DD8-E518-41DF-83C0-3D4F68EA2027@jadickinson.co.uk>
	<49305A14.4080704@surfnet.nl>
Message-ID: <C477433C-73CC-433E-9082-28D54FB9DF7D@iis.se>


On Nov 28, 2008, at 9:52 PM, Roland van Rijswijk wrote:

>> I agree, key backup is outside the scope of OpenDNSSEC and should  
>> be done according to the mechanism designed by the HSM  
>> manufacturer. Ability to do this would be a consideration when  
>> selecting an HSM or soft token.
>
> I agree as well, I know of quite a few HSM manufacturers that use  
> the model described above (master key in the HSM, actual key  
> material stored on disk with ways to restore the master key). A good  
> example is nCipher.
>
> I'm pretty sure each manufacturer provides their own methods for  
> backing up and restoring key material and also for duplicating  
> security worlds across multiple distributed HSMs.
>
> In my opinion, functionality like key backup should be addressed in  
> something like a manual (it's something operators should at least  
> think about) but should not be solved by OpenDNSSEC. HSM  
> manufacturers have much more experience in this which should be  
> leveraged. Unfortunately they also have widely varying  
> implementations which makes it hard to specify a single statement on  
> how to go about backing up your keys :-(.

Even though backup of keys is outside the scope of our project, maybe  
details on how each HSM handles backup and key storage is something we  
should add to the Wiki on the HSM Comparison page?

http://www.opendnssec.se/wiki/HSM/Comparison

-- 
Patrik Wallstr?m
Project Manager, R&D
.SE (Stiftelsen f?r Internetinfrastruktur)
E-mail: patrik.wallstrom at iis.se
Web: http://www.iis.se/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081201/87e7e89a/attachment.bin>

From Rickard.Bondesson at iis.se  Mon Dec  1 12:12:55 2008
From: Rickard.Bondesson at iis.se (Rickard Bondesson)
Date: Mon, 1 Dec 2008 13:12:55 +0100
Subject: [Opendnssec-develop] SoftHSM
Message-ID: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

What is your view about the SoftHSM? Should it become a solution for OpenDNSSEC or a general purpose HSM?

For example:
- - In OpenDNSSEC there is no need of having the possibility to add external public keys to the HSM, since we do not need to verify external signatures or encrypt data to a third party.

- - In OpenDNSSEC we do not need to encrypt/decrypt anything.

- - Since we only sign information, we do not need to keep track of whether a key pair is for signing or encryption.

- - A general solution would need a more complex internal key handling solution.

- - A general purpose solution would become a bit slower since we have to handle more internal state cases.

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSTPUx+CjgaNTdVjaAQiGCAf/awf/DeMXk4Z03RIxeiuv0rvlNsTZF0lZ
Xrck/9Cm0rzF/l0h0ScypekjhPByuwjbXUSmFRCbxubav7M6ZsZXR43zRVKKafX1
QR9+lfekXyNf8Ll1cqzNoTLLJ+2SUOWecxE16okO1FsRn9LwyV5DGmxOrYyJgwvV
WrXxIH9shg5Nu5e7ehCO9tjfOi+/43FGkf5fBFmbeqQLt35J5sq7vMt/pEyrAylF
Es/3N1VVI2/xYpmRBfKMkJB8NO7wZ5OWmQaJ4CwALXgz4KdKRshlXs6bNgQKjLbm
DcZFiPVlHexbAt771mv0+T/L+VFb91r9JB20TK4Vo5wJIzLxWIFD/Q==
=5CG4
-----END PGP SIGNATURE-----


From roy at nominet.org.uk  Mon Dec  1 12:30:15 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Mon, 1 Dec 2008 13:30:15 +0100
Subject: [Opendnssec-develop] SoftHSM
In-Reply-To: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>
Message-ID: <OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk>

"Rickard Bondesson" <Rickard.Bondesson at iis.se> wrote on 12/01/2008 
01:12:55 PM:

> What is your view about the SoftHSM? Should it become a solution for
> OpenDNSSEC or a general purpose HSM?

I don't think these goals are mutual exclusive. The required functionality 
for OpenDNSSEC is a small subset of a fully featured "virtual" HSM. We 
need SoftHSM to at least work with OpenDNSSEC. Though I do see some value 
for SoftHSM for other purposes outside of OpenDNSSEC (for which it then 
needs richer functionality), but I'd give that less (or no) priority.

> For example:
> - - In OpenDNSSEC there is no need of having the possibility to add 
> external public keys to the HSM, since we do not need to verify 
> external signatures or encrypt data to a third party.

That is correct.

> - - In OpenDNSSEC we do not need to encrypt/decrypt anything.

Yes.

> - - Since we only sign information, we do not need to keep track of 
> whether a key pair is for signing or encryption.

To be clear, OpenDNSSEC is also capable of using a real HSM, one that 
might store keys for encryption purposes as well. So if a pkcs11 template 
is generated for a request, I'd like to contain CKA_SIGN=TRUE (at least) 
and maybe even CKA_DECRYPT=FALSE. In short, the softtoken does need to 
understand (or ignore, but not fail) those attributes.

> - - A general solution would need a more complex internal key 
> handling solution.

Yes.

> - - A general purpose solution would become a bit slower since we 
> have to handle more internal state cases.

Yes.

Hope this helps.

Roy


From jad at jadickinson.co.uk  Mon Dec  1 13:50:48 2008
From: jad at jadickinson.co.uk (John Dickinson)
Date: Mon, 1 Dec 2008 13:50:48 +0000
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>
Message-ID: <A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>


On 30 Nov 2008, at 14:46, Olaf Kolkman wrote:

>
>
>
>
>
> On Nov 28, 2008, at 5:47 PM, Stephen.Morris at nominet.org.uk wrote:
>
>> Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 27/11/2008 16:01:26:
>>
>>>
>>> On Nov 27, 2008, at 4:54 PM, John Dickinson wrote:
>>>
>>>>
>>>> So I guess if you have a large zone like co.uk then a couple of
>>>> seconds in the 6 odd minutes that it would take to sign from  
>>>> scratch
>>>> is nothing. However, if you have 1000's of small zones or you are
>>>> dynamically updating every minute then it could make a big  
>>>> difference.
>>>
>>> But even then... the key-rollover would take place only once per  
>>> month
>>> or so. So this 2 second pain per zone only happens once or twice per
>>> month.
>>
>> In this approach, are there any problems in ensuring that the keys  
>> are
>> replicated to a backup HSM before they are used?  Do you need any  
>> type of
>> "master" password to export private keys from the HSM?
>>
>
>
> And again, here I can see a many zones using one private key. With  
> that possibility a number of these questions do not pop up. One  
> private key (with many public key instances) that is used for many  
> zones. One single generation, one single backup an al this magic.
>
> Not that one priv-key to many zones excludes many-to-many.

If you share keys do you need to coordinate key roll overs? For  
example, what about if you have 10 zones all sharing a key. Can you  
then add an 11th? It will have a different timeline for key rollovers.  
For starters the key publication and ready dates will be different,  
this means that the predicted key retire and dead times will be  
different. I guess you could sync them by retiring the key early in  
zone 11. Does rollover need to be done for all zones at the same time?

John




From Stephen.Morris at nominet.org.uk  Mon Dec  1 14:34:09 2008
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Mon, 1 Dec 2008 14:34:09 +0000
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>
Message-ID: <OF091CC12F.072ED892-ON80257512.004E747B-80257512.00500890@nominet.org.uk>

John Dickinson <jad at jadickinson.co.uk> wrote on 01/12/2008 13:50:48:

> If you share keys do you need to coordinate key roll overs? For 
> example, what about if you have 10 zones all sharing a key. Can you 
> then add an 11th? It will have a different timeline for key rollovers. 
> For starters the key publication and ready dates will be different, 
> this means that the predicted key retire and dead times will be 
> different. I guess you could sync them by retiring the key early in 
> zone 11. Does rollover need to be done for all zones at the same time?

I wouldn't see that as an absolute requirement, but it would simplify the 
management software.

Perhaps we should look at the question in a different way: in the case 
where a group of zones share a key, under what circumstances would we 
require that a key be rolled at different times in different zones?

Stephen



From olaf at NLnetLabs.nl  Mon Dec  1 14:40:07 2008
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Mon, 1 Dec 2008 15:40:07 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>
	<A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>
Message-ID: <13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>

>>
>> And again, here I can see a many zones using one private key. With  
>> that possibility a number of these questions do not pop up. One  
>> private key (with many public key instances) that is used for many  
>> zones. One single generation, one single backup an al this magic.
>>
>> Not that one priv-key to many zones excludes many-to-many.
>
> If you share keys do you need to coordinate key roll overs? For  
> example, what about if you have 10 zones all sharing a key. Can you  
> then add an 11th? It will have a different timeline for key  
> rollovers. For starters the key publication and ready dates will be  
> different, this means that the predicted key retire and dead times  
> will be different. I guess you could sync them by retiring the key  
> early in zone 11. Does rollover need to be done for all zones at the  
> same time?
>
>

Yes, all zones that share the same private key will need to roll at  
the same time. For a KSK rollover that is most tricky since you have  
to wait until all DS RRs at the parents are replaced, and then wait a  
little more, but I do not think that is not doable.

Besides "retiring" the key is AFAIU a concept that applies to the  
private key material, so the key-lifetime is a property of the  
(private key) and not of a zone.

--Olaf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 235 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081201/35816481/attachment.bin>

From roland.vanrijswijk at surfnet.nl  Mon Dec  1 14:43:24 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Mon, 01 Dec 2008 15:43:24 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <OF091CC12F.072ED892-ON80257512.004E747B-80257512.00500890@nominet.org.uk>
References: <OF091CC12F.072ED892-ON80257512.004E747B-80257512.00500890@nominet.org.uk>
Message-ID: <4933F80C.1060509@surfnet.nl>

Stephen.Morris at nominet.org.uk wrote:
> John Dickinson <jad at jadickinson.co.uk> wrote on 01/12/2008 13:50:48:
> 
>> If you share keys do you need to coordinate key roll overs? For 
>> example, what about if you have 10 zones all sharing a key. Can you 
>> then add an 11th? It will have a different timeline for key rollovers. 
>> For starters the key publication and ready dates will be different, 
>> this means that the predicted key retire and dead times will be 
>> different. I guess you could sync them by retiring the key early in 
>> zone 11. Does rollover need to be done for all zones at the same time?
> 
> I wouldn't see that as an absolute requirement, but it would simplify the 
> management software.
> 
> Perhaps we should look at the question in a different way: in the case 
> where a group of zones share a key, under what circumstances would we 
> require that a key be rolled at different times in different zones?

Correct me if I'm wrong, but to me it seems that this is only an issue
when a new zone is added and it is only an issue for the first rollover
for that zone. I think it would make sense to have all zones that share
a key roll over simultaneously, so if a new zone is added for a key,
this zone would most likely get a key rollover earlier than would
normally be the policy but only for the first key rollover, after that
first rollover it is in sync with the rest of the zones sharing the keys.

In my opinion, it would not be wise to have zones that share a key roll
over at different times. The only disadvantage I can see here is that in
this model you might have to sign a lot of zones at the same time when a
key rollover is about to take place and you run the risk of all zone
resigns remaining in sync if the same signing policy is used for all
zones that share a key thus creating peaks in signing activity.

Cheers,

Roland.

-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From rick at openfortress.nl  Tue Dec  2 11:53:15 2008
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 2 Dec 2008 11:53:15 +0000
Subject: [Opendnssec-develop] SoftHSM
In-Reply-To: <OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>
	<OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk>
Message-ID: <20081202115315.GD28552@phantom.vanrein.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

Thank you for the good discussion topics on this list.  As introduced by
Roy last week, I've done a lot of PKCS #11 application development at
OpenFortress, and will try to add my twopence to this discussion.

> To be clear, OpenDNSSEC is also capable of using a real HSM, one that 
> might store keys for encryption purposes as well. So if a pkcs11 template 
> is generated for a request, I'd like to contain CKA_SIGN=TRUE (at least) 
> and maybe even CKA_DECRYPT=FALSE.

There are several CKA_xxx attributes, and many are worthwhile to use.
Among my favourites are the flags that tell the PKCS #11 implementation
to avoid export, and to enforce keys having been generated on-token.

It has been my experience (mainly with USB tokens and smart cards) that
support for the CKA_xxx flags is not proper and complete for most of the
tokens, making many libraries will fail if you are over-explicit.  I've
been talking to quite a few manufacturers and got such flags implemented,
but count on a period of months to wait before any middleware is improved
if you rely on CKA_xxx flags too heavily.  My impression is that most
token middleware is developed to work with a few browsers and a handful
of mailers, and then shipped off.  The remaining flags often remain as
TODO items until someone complains about them.

> In short, the softtoken does need to 
> understand (or ignore, but not fail) those attributes.

This is precisely what worries me.  Ideally, I'd agree.  Practically though,
it may be a serious show-stopper when deploying the OpenDNSSEC daemon on a
given piece of hardware.

The nuisance of this is that OpenDNSSEC, to be practical, would have to be
configurable for the CKA_xxx flags it relies on, just to make up for any
half-done middlewares.  I'd love to believe that HSM manufacturers are
doing better, but honestly I doubt it.


Cheers,

Rick van Rein
OpenFortress Digital signatures
http;//openfortress.nl/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: New to PGP? http://openfortress.nl/doc/essay/OpenPGP/index.nl.html

iD8DBQFJNSGPFBGpwol1RgYRAtF+AJ4okhWWklj0Ss8yQqZWjg1DbXpDcgCfToT2
m1drDbB5z55XoQDNtOHZQ5Q=
=2UYu
-----END PGP SIGNATURE-----


From roy at nominet.org.uk  Tue Dec  2 12:05:44 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Tue, 2 Dec 2008 13:05:44 +0100
Subject: [Opendnssec-develop] SoftHSM
In-Reply-To: <20081202115315.GD28552@phantom.vanrein.org>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>	<OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk>
	<20081202115315.GD28552@phantom.vanrein.org>
Message-ID: <OF6E268D81.217451A5-ON80257513.0041BB12-C1257513.00427170@nominet.org.uk>

Rick van Rein wrote on 12/02/2008 12:53:15 PM:

> Hello,
> 
> Thank you for the good discussion topics on this list.  As introduced by
> Roy last week, I've done a lot of PKCS #11 application development at
> OpenFortress, and will try to add my twopence to this discussion.
> 
> > To be clear, OpenDNSSEC is also capable of using a real HSM, one that 
> > might store keys for encryption purposes as well. So if a pkcs11 
template 
> > is generated for a request, I'd like to contain CKA_SIGN=TRUE (at 
least) 
> > and maybe even CKA_DECRYPT=FALSE.
> 
> There are several CKA_xxx attributes, and many are worthwhile to use.
> Among my favourites are the flags that tell the PKCS #11 implementation
> to avoid export, and to enforce keys having been generated on-token.
> 
> It has been my experience (mainly with USB tokens and smart cards) that
> support for the CKA_xxx flags is not proper and complete for most of the
> tokens, making many libraries will fail if you are over-explicit.  I've
> been talking to quite a few manufacturers and got such flags 
implemented,
> but count on a period of months to wait before any middleware is 
improved
> if you rely on CKA_xxx flags too heavily.  My impression is that most
> token middleware is developed to work with a few browsers and a handful
> of mailers, and then shipped off.  The remaining flags often remain as
> TODO items until someone complains about them.
> 
> > In short, the softtoken does need to 
> > understand (or ignore, but not fail) those attributes.
> 
> This is precisely what worries me.  Ideally, I'd agree.  Practically 
though,
> it may be a serious show-stopper when deploying the OpenDNSSEC daemon on 
a
> given piece of hardware.
> 
> The nuisance of this is that OpenDNSSEC, to be practical, would have to 
be
> configurable for the CKA_xxx flags it relies on, just to make up for any
> half-done middlewares.  I'd love to believe that HSM manufacturers are
> doing better, but honestly I doubt it.

So much for PKCS11 compliant then.

I'll start a new thread on the list to eh, list the equipment we can test 
OpenDNSSEC's PKCS11 compliance reqs against.

Thanks for the info on this.

Roy Arends
Sr Researcher.
Nominet UK






From roland.vanrijswijk at surfnet.nl  Tue Dec  2 12:05:53 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Tue, 02 Dec 2008 13:05:53 +0100
Subject: [Opendnssec-develop] SoftHSM
In-Reply-To: <20081202115315.GD28552@phantom.vanrein.org>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>	<OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk>
	<20081202115315.GD28552@phantom.vanrein.org>
Message-ID: <493524A1.6040708@surfnet.nl>

Hello,

> The nuisance of this is that OpenDNSSEC, to be practical, would have to be
> configurable for the CKA_xxx flags it relies on, just to make up for any
> half-done middlewares.  I'd love to believe that HSM manufacturers are
> doing better, but honestly I doubt it.

In my experience, HSM manufacturers generally do a better job of
implementing PKCS #11 libraries than smart card manufacturers. Keep in
mind that HSMs are an order of magnitude more expensive and complex than
smart cards so they _need_ to support more CKA_xyz attributes.
Manufacturers of HSMs generally put more effort into their P #11
libraries. The only problem is that it is common practice for HSM
manufacturers to 'extend' the PKCS #11 API with vendor specific
functionality. In my opinion, if possible this kind of vendor specific
functionality should not be relied on.

On another note: even the worst smart card manufacturers implement the
common CKA_xyz attributes. Though I agree with Rick that there are many
bad implementations, this should not deter you from correctly using PKCS
#11 attributes. Maybe it is a good idea to give an insight into which
flags and attributes you want to use. I - and I believe Rick as well -
should be able to tell you what the correct usage of these attributes is
and whether or not they are commonly used...

Cheers,

Roland.

-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From Rickard.Bondesson at iis.se  Tue Dec  2 12:36:37 2008
From: Rickard.Bondesson at iis.se (Rickard Bondesson)
Date: Tue, 2 Dec 2008 13:36:37 +0100
Subject: SV: [Opendnssec-develop] SoftHSM
In-Reply-To: <493524A1.6040708@surfnet.nl>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>	<OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk><20081202115315.GD28552@phantom.vanrein.org>
	<493524A1.6040708@surfnet.nl>
Message-ID: <69830D4127201D4EBD146B9041199718645EFB@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Does the quotation below imply that you HAVE to assign the other values, given by the user, to the generated key?

"Other attributes supported by the RSA public and private key types (specifically, the flags indicating which functions the keys support) may also be specified in the templates for the keys, or else are assigned default initial values." 

With for example CKM_RSA_PKCS_KEY_PAIR_GEN:
Is it ok to just take the CKA_MODULUS_BITS and CKA_PUBLIC_EXPONENT (default 65537) from the template and ignore the the other values? Then for example assign CKA_SIGN = TRUE in our case, since that is what the purpose is with the generated keys in the SoftHSM.

// Rickard 

- -----Ursprungligt meddelande-----
Fr?n: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] F?r Roland van Rijswijk
Skickat: den 2 december 2008 13:06
Till: Rick van Rein
Kopia: Opendnssec-develop at lists.opendnssec.org
?mne: Re: [Opendnssec-develop] SoftHSM

Hello,

> The nuisance of this is that OpenDNSSEC, to be practical, would have 
> to be configurable for the CKA_xxx flags it relies on, just to make up 
> for any half-done middlewares.  I'd love to believe that HSM 
> manufacturers are doing better, but honestly I doubt it.

In my experience, HSM manufacturers generally do a better job of implementing PKCS #11 libraries than smart card manufacturers. Keep in mind that HSMs are an order of magnitude more expensive and complex than smart cards so they _need_ to support more CKA_xyz attributes.
Manufacturers of HSMs generally put more effort into their P #11 libraries. The only problem is that it is common practice for HSM manufacturers to 'extend' the PKCS #11 API with vendor specific functionality. In my opinion, if possible this kind of vendor specific functionality should not be relied on.

On another note: even the worst smart card manufacturers implement the common CKA_xyz attributes. Though I agree with Rick that there are many bad implementations, this should not deter you from correctly using PKCS
#11 attributes. Maybe it is a good idea to give an insight into which flags and attributes you want to use. I - and I believe Rick as well - should be able to tell you what the correct usage of these attributes is and whether or not they are commonly used...

Cheers,

Roland.

- -- 

- -- Roland M. van Rijswijk
- -- SURFnet Middleware Services
- -- t: +31-30-2305388
- -- e: roland.vanrijswijk at surfnet.nl
_______________________________________________
Opendnssec-develop mailing list
Opendnssec-develop at lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSTUr1eCjgaNTdVjaAQiMyAf+JhafS+srRLkF76Xxq9uos0QK2ogKdp8y
ZBS6d4oj2r62/PXHmpOs9roSqWeNUvjFAME+Os2Qrjo2giKzRK6QN+Mmv1b2iRf8
A1e0NvkzW7tLIbDM+l1WcWAKYjOFxjivX3hkl74esGcQ/0rIOP+CdBqXjcOTo1ah
KlZBwo5+L6unzUQivE7IsnLdsWwTODXl/WdUlkCCA9f8YUOD40iCZR+oE8TIelC/
+Tjgqdnyo5WDrEWWdTJ0EF4F9q5zOWJGBdYmlObUgo8iz2pr6lu5SlQrmUd0hbyq
7qe84/+Ycw2NQoYPec/tnz5oRjnG0n9Ex6CZ9pxUnDJ6FncScBPalw==
=4UUd
-----END PGP SIGNATURE-----


From roland.vanrijswijk at surfnet.nl  Tue Dec  2 12:46:20 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Tue, 02 Dec 2008 13:46:20 +0100
Subject: SV: [Opendnssec-develop] SoftHSM
In-Reply-To: <69830D4127201D4EBD146B9041199718645EFB@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>	<OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk><20081202115315.GD28552@phantom.vanrein.org>
	<493524A1.6040708@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645EFB@EXCHANGE.office.nic.se>
Message-ID: <49352E1C.4090705@surfnet.nl>

Hi Rickard,

Rickard Bondesson wrote:
> Does the quotation below imply that you HAVE to assign the other
> values, given by the user, to the generated key?
> 
> "Other attributes supported by the RSA public and private key types
> (specifically, the flags indicating which functions the keys support)
> may also be specified in the templates for the keys, or else are
> assigned default initial values."
> 
> With for example CKM_RSA_PKCS_KEY_PAIR_GEN: Is it ok to just take the
> CKA_MODULUS_BITS and CKA_PUBLIC_EXPONENT (default 65537) from the
> template and ignore the the other values? Then for example assign
> CKA_SIGN = TRUE in our case, since that is what the purpose is with
> the generated keys in the SoftHSM.

The correct way to implement it is as follows:

- It is not mandatory to specify any key attributes. If none are
specified, none are supposed to be set on the object; this means that no
default values should be assigned

- The values specified by the user should not be overridden; you should
copy the values that the user specifies

- The attributes must be enforced by the PKCS #11 module when calls to
functions like C_SignInit are made

- It is up to the implementor of the module whether or not changes are
allowed to these attributes once the object has been created

Summarising: you should not assign a value yourself and you should not
ignore what is in the template. This would go against the PKCS #11
specification.

I hope this answers your question.

Cheers,

Roland.

-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From roy at nominet.org.uk  Tue Dec  2 12:46:55 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Tue, 2 Dec 2008 13:46:55 +0100
Subject: [Opendnssec-develop] HSM vendors and common key attributes
Message-ID: <OFC9A4F133.4BC0EC55-ON80257513.004272D8-C1257513.00463688@nominet.org.uk>

Hi,

In a separate thread, Rick van Rein elaborated on the state of PKCS11 
compliance, especially the CKA_XXX attributes a key might have.

I think that a rule of thumb should be that OpenDNSSEC should be as strict 
as possible, but not more strict than that :-)

In order to gauge how strict, please list the type of HSM to your avail 
that you will be able to test OpenDNSSEC against.

Nominet has the following:

Sun SCA6000
SafeNet Luna SA 
nCipher netHSM

Consequently, we can create a simple matrix that contains CKA_XXX 
compliance and vendor.

What follows is a list of attributes I require:

CKA_ID (but see note [1] below)

And here the attributes I'd recommend to have:

CKA_KEY_TYPE
CKA_LOCAL = CK_TRUE
CKA_SIGN = CK_TRUE
CKA_EXTRACTABLE = CK_FALSE
CKA_NEVER_EXTRACTABLE = CK_TRUE
CKA_SENSITIVE = CK_TRUE
CKA_ALWAYS_SENSITIVE = CK_TRUE

And here the attibutes I think are nice to have:

CKA_DECRYPT = CK_FALSE
CKA_UNWRAP = CK_FALSE
CKA_SIGN_RECOVER 
CKA_ALWAYS_AUTHENTICATE

Let me know.

Roy Arends
Sr. Researcher
Nominet UK

[1] The CKA_ID can have any value and is said to be of an array of 
unsigned 8-bit characters. We have noticed that different vendors have 
different length of this array. We have seen silliness that when we 
specify a value of 1, it is often stored as the ascii value for "1", where 
other HSMs store it as value 1. Also we see restrictions that ID can only 
be numerical, while others allow it to be anything.




From rick at openfortress.nl  Tue Dec  2 12:53:21 2008
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 2 Dec 2008 12:53:21 +0000
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>
	<A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>
	<13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>
Message-ID: <20081202125321.GE28552@phantom.vanrein.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

> >>And again, here I can see a many zones using one private key. [...]
> >>
> >If you share keys do you need to coordinate key roll overs? [...]
> >
> Yes, all zones that share the same private key will need to roll at  
> the same time.

Sharing of key pairs makes bundles of sense to me.

Using PKCS #11 as a generic HSM interface, will give rise to deployment
models that use simple USB tokens as a low-cost keystore.  This could be
used by owners of a few zones, such as the administrator of a company's
single/few domains.  I suspect many companies will want to be "in control"
of their "vital square on the net", based on such a thrifty setup.

USB tokens cannot store very many key pairs, think of 10 to get an idea.
It could become a nuisance to be constrained in the number of zones one
manages if the token cannot cope, and it will at some point cause a new
domain number 11 to remain unsigned "for now", however long that lasts.
Being able to share key pairs among zones would be totally reasonable in
such situations, in my opinion.

This is not even counting the fact that we would like to have some room
to move in a token, for overlapping key validity periods.  It would be
dead wrong to have to deny a KSK rollover to a signer using a USB-token
for reasons like a slow parent DS pickup on a previous one.  Or worse,
to be unable to rollover in case of compromise.  We'll need the space
for a variable few KSK at the same time in such a token, and that is
enough demand to roughly fill up an average one.

	But do we believe OpenDNSSEC should be the solution for such
	few-domain admins?  Or should they be redirected to a tool like
	Holger's ZKT, which does well for smaller roll-out scenarios?
	I think the dynamic-signer properties and use of PKCS #11 can
	make OpenDNSSEC useful in places where ZKT is not active (yet).

The next question then, is when key pairs could be shared?  Since a key
coincides with responsibility to manage it, I suppose most deployments
would stipulate that key pairs SHOULD at most be shared among zones
administered by the same party.  As is the case with the example of the
admin before.  As is the case with .co.uk and .org.uk.  But as is not the
case when we are looking at nlnetlabs.nl, surfnet.nl and openfortress.nl.
The latter three MUST NOT share a key pair.

> For a KSK rollover that is most tricky since you have  
> to wait until all DS RRs at the parents are replaced, and then wait a  
> little more, but I do not think that is not doable.

I also think it is doable.  It is very likely that there will be a sort
of service level agreement about DS update times, because without that
it is impossible to predict when to start rolling over.  (We could choose
the times in RFC 4641, but it would be a matter of faith that the parent
would adhere to it as well.)  Taking the worst-case DS update time should
suffice to predict the key rollover preparation time.

> >>Not that one priv-key to many zones excludes many-to-many.

I do not think it is prudent to share keys among different parties, which
would call for multiple keys on one OpenDNSSEC deployment.  However, I've
been wondering when this would happen, and found only a somewhat contrived
example.  A hoster (like SURFnet) could be willing to sign DNSSEC domains
in an HSM for its constituents/customers.  There are probably legal
considerations that make it necessary to have different keys for each
customer/constituent, and enable local backup procedures by each of them.
In such cases, it would be required to support different key pairs.


In summary, I believe
* that USB tokens make it necessary to share key pairs among zones
* that provider-signing makes it necessary to support multiple key pairs


Cheers,

Rick van Rein
OpenFortress Digital signatures
http://openfortress.nl/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: New to PGP? http://openfortress.nl/doc/essay/OpenPGP/index.nl.html

iD8DBQFJNS+8FBGpwol1RgYRApnpAJ9DDhccF8lgYKXY7Ny7gvzkehIUJwCcCr1e
53L+Awjo1GOieYFFf3edO8c=
=iVIJ
-----END PGP SIGNATURE-----


From roland.vanrijswijk at surfnet.nl  Tue Dec  2 12:58:15 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Tue, 02 Dec 2008 13:58:15 +0100
Subject: [Opendnssec-develop] HSM vendors and common key attributes
In-Reply-To: <OFC9A4F133.4BC0EC55-ON80257513.004272D8-C1257513.00463688@nominet.org.uk>
References: <OFC9A4F133.4BC0EC55-ON80257513.004272D8-C1257513.00463688@nominet.org.uk>
Message-ID: <493530E7.7070604@surfnet.nl>

Hi Roy,

I've taken the liberty of quickly answering the question for some of the
 attributes in your list below:

Roy Arends wrote:

> Consequently, we can create a simple matrix that contains CKA_XXX 
> compliance and vendor.
> 
> What follows is a list of attributes I require:
> 
> CKA_ID (but see note [1] below)

Is supported by all PKCS #11 modules I know of (including nCipher
netHSM, Safenet Luna). This is such a basic attribute that a module
cannot be called PKCS #11 compliant if it doesn't support this attribute.

I think CKA_TOKEN should also be in the 'mandatory' list.

> And here the attributes I'd recommend to have:
> 
> CKA_KEY_TYPE
> CKA_LOCAL = CK_TRUE
> CKA_SIGN = CK_TRUE
> CKA_EXTRACTABLE = CK_FALSE
> CKA_NEVER_EXTRACTABLE = CK_TRUE
> CKA_SENSITIVE = CK_TRUE
> CKA_ALWAYS_SENSITIVE = CK_TRUE

Again, these are such basic attributes that any module should support
them. The HSMs I've worked with all support these attributes.

> And here the attibutes I think are nice to have:
> 
> CKA_DECRYPT = CK_FALSE
> CKA_UNWRAP = CK_FALSE

These first two are - again - basic attributes that any module should
support. The HSMs I've worked with all support these attributes.

> CKA_SIGN_RECOVER 
> CKA_ALWAYS_AUTHENTICATE

These two are a bit trickier, especially the last one. I'm pretty
certain that most smart card PKCS #11 modules have problems with
CKA_ALWAYS_AUTHENTICATE and I also know that many applications that
support PKCS #11 such as Firefox, etc. have problems with this
attribute. I would not rely on either of these attributes being supported.

Cheers,

Roland.

-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From rick at openfortress.nl  Tue Dec  2 12:59:02 2008
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 2 Dec 2008 12:59:02 +0000
Subject: [Opendnssec-develop] SoftHSM
In-Reply-To: <493524A1.6040708@surfnet.nl>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>
	<OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk>
	<20081202115315.GD28552@phantom.vanrein.org>
	<493524A1.6040708@surfnet.nl>
Message-ID: <20081202125902.GF28552@phantom.vanrein.org>

Hi,

> In my experience, HSM manufacturers generally do a better job of
> implementing PKCS #11 libraries than smart card manufacturers.

Glad to hear it.  Even though I believe USB tokens should be taken
into consideration, they are so widespread that one that works will
suffice.

> Keep in
> mind that HSMs are an order of magnitude more expensive and complex than
> smart cards so they _need_ to support more CKA_xyz attributes.

I considered it, but wondered if their total income would be higher than
that of token manufacturers.  Alas, I have no experience with HSMs.

> On another note: even the worst smart card manufacturers implement the
> common CKA_xyz attributes. Though I agree with Rick that there are many
> bad implementations, this should not deter you from correctly using PKCS
> #11 attributes. Maybe it is a good idea to give an insight into which
> flags and attributes you want to use. I - and I believe Rick as well -
> should be able to tell you what the correct usage of these attributes is
> and whether or not they are commonly used...

Yes, indeed.

-Rick


From rick at openfortress.nl  Tue Dec  2 13:10:31 2008
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 2 Dec 2008 13:10:31 +0000
Subject: [Opendnssec-develop] HSM vendors and common key attributes
In-Reply-To: <OFC9A4F133.4BC0EC55-ON80257513.004272D8-C1257513.00463688@nominet.org.uk>
References: <OFC9A4F133.4BC0EC55-ON80257513.004272D8-C1257513.00463688@nominet.org.uk>
Message-ID: <20081202131031.GG28552@phantom.vanrein.org>

Hi,

> In order to gauge how strict, please list the type of HSM to your avail 
> that you will be able to test OpenDNSSEC against.

I have a pile of USB tokens that I've worked with, from all sorts of make.
As Roland wrote, they are not as compatible as HSMs are.  Still, I think
it is good to document the trouble I've seen.

> And here the attributes I'd recommend to have:
> 
> CKA_KEY_TYPE
> CKA_LOCAL = CK_TRUE
  -> I have had trouble with this one
> CKA_SIGN = CK_TRUE
> CKA_EXTRACTABLE = CK_FALSE
> CKA_NEVER_EXTRACTABLE = CK_TRUE
  -> I have had trouble with this one
> CKA_SENSITIVE = CK_TRUE
> CKA_ALWAYS_SENSITIVE = CK_TRUE
  -> I have had trouble with this one

Token middleware that solved the mentioned trouble: SafeSign and EnterSafe.
SafeSign is used for G&D STARCOS, Utimaco tokens.
EnterSafe is used for ePass tokens.


Cheers,
 -Rick


From roy at nominet.org.uk  Tue Dec  2 13:11:51 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Tue, 2 Dec 2008 14:11:51 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <20081202125321.GE28552@phantom.vanrein.org>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>	<A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>
	<13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>
	<20081202125321.GE28552@phantom.vanrein.org>
Message-ID: <OF830CA32B.854D3F35-ON80257513.00471BBB-C1257513.00487ECA@nominet.org.uk>

Rick van Rein wrote on 12/02/2008 01:53:21 PM:

> Hello,
> 
> > >>And again, here I can see a many zones using one private key. [...]
> > >>
> > >If you share keys do you need to coordinate key roll overs? [...]
> > >
> > Yes, all zones that share the same private key will need to roll at 
> > the same time.
> 
> Sharing of key pairs makes bundles of sense to me.
> 
> Using PKCS #11 as a generic HSM interface, will give rise to deployment
> models that use simple USB tokens as a low-cost keystore.  This could be
> used by owners of a few zones, such as the administrator of a company's
> single/few domains.  I suspect many companies will want to be "in 
control"
> of their "vital square on the net", based on such a thrifty setup.
> 
> USB tokens cannot store very many key pairs, think of 10 to get an idea.
> It could become a nuisance to be constrained in the number of zones one
> manages if the token cannot cope, and it will at some point cause a new
> domain number 11 to remain unsigned "for now", however long that lasts.
> Being able to share key pairs among zones would be totally reasonable in
> such situations, in my opinion.
> 
> This is not even counting the fact that we would like to have some room
> to move in a token, for overlapping key validity periods.  It would be
> dead wrong to have to deny a KSK rollover to a signer using a USB-token
> for reasons like a slow parent DS pickup on a previous one.  Or worse,
> to be unable to rollover in case of compromise.  We'll need the space
> for a variable few KSK at the same time in such a token, and that is
> enough demand to roughly fill up an average one.
> 
>    But do we believe OpenDNSSEC should be the solution for such
>    few-domain admins?  Or should they be redirected to a tool like
>    Holger's ZKT, which does well for smaller roll-out scenarios?
>    I think the dynamic-signer properties and use of PKCS #11 can
>    make OpenDNSSEC useful in places where ZKT is not active (yet).

OpenDNSSEC should be _the_ solution for such few-domain admins. The 
mandate that we have is that OpenDNSSEC should be the common tool for 
managing signed domains. If you have one domain, and want it signed, use 
OpenDNSSEC.

Fwiw I do not see a market for USB tokens as a keystore in this sense. USB 
tokens tend to get lost, stolen, or left connected to a device (or left in 
a bar or taxi, if you work for British Government). Note that data needs 
to be signed periodically and regularly. If you have a high value domain, 
use a proper fips-140-2 level 4 HSM. If you have huge number of highly 
volatile domains, use an HSM that is specifically build for acceleration. 
I think it is fine, in the general case, to have a softtoken.

> The next question then, is when key pairs could be shared?  Since a key
> coincides with responsibility to manage it, I suppose most deployments
> would stipulate that key pairs SHOULD at most be shared among zones
> administered by the same party.  As is the case with the example of the
> admin before.  As is the case with .co.uk and .org.uk.  But as is not 
the
> case when we are looking at nlnetlabs.nl, surfnet.nl and 
openfortress.nl.
> The latter three MUST NOT share a key pair.
> 
> > For a KSK rollover that is most tricky since you have 
> > to wait until all DS RRs at the parents are replaced, and then wait a 
> > little more, but I do not think that is not doable.
> 
> I also think it is doable.  It is very likely that there will be a sort
> of service level agreement about DS update times, because without that
> it is impossible to predict when to start rolling over.  (We could 
choose
> the times in RFC 4641, but it would be a matter of faith that the parent
> would adhere to it as well.)  Taking the worst-case DS update time 
should
> suffice to predict the key rollover preparation time.
> 
> > >>Not that one priv-key to many zones excludes many-to-many.
> 
> I do not think it is prudent to share keys among different parties, 
which
> would call for multiple keys on one OpenDNSSEC deployment.  However, 
I've
> been wondering when this would happen, and found only a somewhat 
contrived
> example.  A hoster (like SURFnet) could be willing to sign DNSSEC 
domains
> in an HSM for its constituents/customers.  There are probably legal
> considerations that make it necessary to have different keys for each
> customer/constituent, and enable local backup procedures by each of 
them.
> In such cases, it would be required to support different key pairs.
> 
> 
> In summary, I believe
> * that USB tokens make it necessary to share key pairs among zones
> * that provider-signing makes it necessary to support multiple key pairs

I see no issue with using a key for multiple domains. I see no issue with 
using a key per domain. Both policies can be implemented. 

Note though that I do not believe that USB tokens make it nec'cy to share 
key pairs among zones. See my earlier point.

Roy Arends
Sr. Researcher
Nominet UK




From roland.vanrijswijk at surfnet.nl  Tue Dec  2 13:18:46 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Tue, 02 Dec 2008 14:18:46 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <OF830CA32B.854D3F35-ON80257513.00471BBB-C1257513.00487ECA@nominet.org.uk>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>	<A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>	<13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>	<20081202125321.GE28552@phantom.vanrein.org>
	<OF830CA32B.854D3F35-ON80257513.00471BBB-C1257513.00487ECA@nominet.org.uk>
Message-ID: <493535B6.4020701@surfnet.nl>

Hi Roy,

> Fwiw I do not see a market for USB tokens as a keystore in this sense. USB 
> tokens tend to get lost, stolen, or left connected to a device (or left in 
> a bar or taxi, if you work for British Government). Note that data needs 
> to be signed periodically and regularly. If you have a high value domain, 
> use a proper fips-140-2 level 4 HSM. If you have huge number of highly 
> volatile domains, use an HSM that is specifically build for acceleration. 
> I think it is fine, in the general case, to have a softtoken.

I think a USB token could add something in some cases, as it provides
better security than a softtoken. And there is of course no reason why
the USB token could not be connected to the signer machine permanently
(in which case it cannot easily be misplaced).

Another way to use a USB token could be as a master key for a soft token.

I think we should not dismiss the possibility of using USB tokens in the
scenario's described, they are a cheap intermediate solution for
hardware security...

On the other hand good arguments for not using USB tokens could be:

- Less durable than HSMs
- Much slower than HSMs or a soft token (many orders of magnitude!)
- Much harder (or even impossible) to back up

Just my 2 cents there.

Cheers,

Roland.

-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From patrik.wallstrom at iis.se  Tue Dec  2 13:21:10 2008
From: patrik.wallstrom at iis.se (Patrik Wallstrom)
Date: Tue, 2 Dec 2008 14:21:10 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <OF830CA32B.854D3F35-ON80257513.00471BBB-C1257513.00487ECA@nominet.org.uk>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>	<A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>
	<13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>
	<20081202125321.GE28552@phantom.vanrein.org>
	<OF830CA32B.854D3F35-ON80257513.00471BBB-C1257513.00487ECA@nominet.org.uk>
Message-ID: <C6C292FD-B7F5-4762-AF75-AFE907C47FD4@iis.se>


On Dec 2, 2008, at 2:11 PM, Roy Arends wrote:

>>   But do we believe OpenDNSSEC should be the solution for such
>>   few-domain admins?  Or should they be redirected to a tool like
>>   Holger's ZKT, which does well for smaller roll-out scenarios?
>>   I think the dynamic-signer properties and use of PKCS #11 can
>>   make OpenDNSSEC useful in places where ZKT is not active (yet).
>
> OpenDNSSEC should be _the_ solution for such few-domain admins. The
> mandate that we have is that OpenDNSSEC should be the common tool for
> managing signed domains. If you have one domain, and want it signed,  
> use
> OpenDNSSEC.
>
> Fwiw I do not see a market for USB tokens as a keystore in this  
> sense. USB
> tokens tend to get lost, stolen, or left connected to a device (or  
> left in
> a bar or taxi, if you work for British Government). Note that data  
> needs
> to be signed periodically and regularly. If you have a high value  
> domain,
> use a proper fips-140-2 level 4 HSM. If you have huge number of highly
> volatile domains, use an HSM that is specifically build for  
> acceleration.
> I think it is fine, in the general case, to have a softtoken.

I must agree with Roy here. If you have such security requirements  
that mandate that you must store your keys in a hardware device, I  
don't think a USB token is a reasonable solution in the long run. The  
cost of using a real HSM is lowered each year and the administrative  
costs of handling USB tokens are soon possibly at the same level.

>> In summary, I believe
>> * that USB tokens make it necessary to share key pairs among zones
>> * that provider-signing makes it necessary to support multiple key  
>> pairs
>
> I see no issue with using a key for multiple domains. I see no issue  
> with
> using a key per domain. Both policies can be implemented.

Yes. But how do we specify this in the policy?

-- 
Patrik Wallstr?m
Project Manager, R&D
.SE (Stiftelsen f?r Internetinfrastruktur)
E-mail: patrik.wallstrom at iis.se
Web: http://www.iis.se/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081202/6ac97d3f/attachment.bin>

From roy at nominet.org.uk  Tue Dec  2 13:21:22 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Tue, 2 Dec 2008 14:21:22 +0100
Subject: [Opendnssec-develop] HSM vendors and common key attributes
In-Reply-To: <493530E7.7070604@surfnet.nl>
References: <OFC9A4F133.4BC0EC55-ON80257513.004272D8-C1257513.00463688@nominet.org.uk>
	<493530E7.7070604@surfnet.nl>
Message-ID: <OF8F380D0B.4D0846C8-ON80257513.0048F22A-C1257513.00495E2F@nominet.org.uk>

Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote on 12/02/2008 
01:58:15 PM:

> Hi Roy,
> 
> I've taken the liberty of quickly answering the question for some of the
>  attributes in your list below:
> 
> Roy Arends wrote:
> 
> > Consequently, we can create a simple matrix that contains CKA_XXX 
> > compliance and vendor.
> > 
> > What follows is a list of attributes I require:
> > 
> > CKA_ID (but see note [1] below)
> 
> Is supported by all PKCS #11 modules I know of (including nCipher
> netHSM, Safenet Luna). This is such a basic attribute that a module
> cannot be called PKCS #11 compliant if it doesn't support this 
attribute.

I agree.

> I think CKA_TOKEN should also be in the 'mandatory' list.

Yes.

> > And here the attributes I'd recommend to have:
> > 
> > CKA_KEY_TYPE
> > CKA_LOCAL = CK_TRUE
> > CKA_SIGN = CK_TRUE
> > CKA_EXTRACTABLE = CK_FALSE
> > CKA_NEVER_EXTRACTABLE = CK_TRUE
> > CKA_SENSITIVE = CK_TRUE
> > CKA_ALWAYS_SENSITIVE = CK_TRUE
> 
> Again, these are such basic attributes that any module should support
> them. The HSMs I've worked with all support these attributes.
> 
> > And here the attibutes I think are nice to have:
> > 
> > CKA_DECRYPT = CK_FALSE
> > CKA_UNWRAP = CK_FALSE
> 
> These first two are - again - basic attributes that any module should
> support. The HSMs I've worked with all support these attributes.
> 
> > CKA_SIGN_RECOVER 
> > CKA_ALWAYS_AUTHENTICATE
> 
> These two are a bit trickier, especially the last one. I'm pretty
> certain that most smart card PKCS #11 modules have problems with
> CKA_ALWAYS_AUTHENTICATE and I also know that many applications that
> support PKCS #11 such as Firefox, etc. have problems with this
> attribute. I would not rely on either of these attributes being 
supported.

Thanks for that Roland,

Are you able to list, and maybe eventually participate to test, the HSMs 
that you currently have at your disposal? 

Thanks,

Roy Arends
Sr. Researcher
Nominet UK



From Rickard.Bondesson at iis.se  Tue Dec  2 13:22:11 2008
From: Rickard.Bondesson at iis.se (Rickard Bondesson)
Date: Tue, 2 Dec 2008 14:22:11 +0100
Subject: SV: [Opendnssec-develop] SoftHSM
In-Reply-To: <49352E1C.4090705@surfnet.nl>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>	<OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk><20081202115315.GD28552@phantom.vanrein.org>
	<493524A1.6040708@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645EFB@EXCHANGE.office.nic.se>
	<49352E1C.4090705@surfnet.nl>
Message-ID: <69830D4127201D4EBD146B9041199718645F07@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Then the question comes back to:

Should this be a general software implementation of a HSM or should it aim at the OpenDNSSEC project?

If we want the user to be able to specify different attributes, then we have to use a more complex background which can maintain these attributes from time to time. As of now, I just give default values back to user. These values are similar to those given by Roy in another email thread (and can be adapted to what ever we conform to). But what difference does it make to our project (with the SoftHSM in mind) if we can assign attributes? The main objective for the HSM in our project is to generate keys and sign data. Then I see no point of having the possibility to disallow certain activities other than specified by the defaults.

"If none are specified, none are supposed to be set on the object; this means that no default values should be assigned"

If for example CKA_SIGN is not set by the user, how should we as a library act when a call comes to C_SignInit if no default values can be assigned by our self? If we continue to sign with the given key, then we could as easily just assign CKA_SIGN = CK_TRUE as a default in this case.

- -----Ursprungligt meddelande-----
Fr?n: Roland van Rijswijk [mailto:roland.vanrijswijk at surfnet.nl] 
Skickat: den 2 december 2008 13:46
Till: Rickard Bondesson
Kopia: Rick van Rein; Opendnssec-develop at lists.opendnssec.org
?mne: Re: SV: [Opendnssec-develop] SoftHSM

Hi Rickard,

Rickard Bondesson wrote:
> Does the quotation below imply that you HAVE to assign the other 
> values, given by the user, to the generated key?
> 
> "Other attributes supported by the RSA public and private key types 
> (specifically, the flags indicating which functions the keys support) 
> may also be specified in the templates for the keys, or else are 
> assigned default initial values."
> 
> With for example CKM_RSA_PKCS_KEY_PAIR_GEN: Is it ok to just take the 
> CKA_MODULUS_BITS and CKA_PUBLIC_EXPONENT (default 65537) from the 
> template and ignore the the other values? Then for example assign 
> CKA_SIGN = TRUE in our case, since that is what the purpose is with 
> the generated keys in the SoftHSM.

The correct way to implement it is as follows:

- - It is not mandatory to specify any key attributes. If none are specified, none are supposed to be set on the object; this means that no default values should be assigned

- - The values specified by the user should not be overridden; you should copy the values that the user specifies

- - The attributes must be enforced by the PKCS #11 module when calls to functions like C_SignInit are made

- - It is up to the implementor of the module whether or not changes are allowed to these attributes once the object has been created

Summarising: you should not assign a value yourself and you should not ignore what is in the template. This would go against the PKCS #11 specification.

I hope this answers your question.

Cheers,

Roland.

- -- 

- -- Roland M. van Rijswijk
- -- SURFnet Middleware Services
- -- t: +31-30-2305388
- -- e: roland.vanrijswijk at surfnet.nl

-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSTU2g+CjgaNTdVjaAQiTQgf/e3hHFMpjSUql7xXr3pSJWpjSlRFovI/1
CEUndyIyXMlb9VrIFV4pTPRrhOXgCi9l7105lkK21Wi8zUqlsqhEQNq2sL8Fqspy
RpI8kN9pIySkA9tNj+UvzTOW+vmJwjnY7/yMGXvLUlQbbmcWim2fV72W3ejLG/dN
tZNgr43bqNaxawjuVD2iozFLbJVxZahL/jzARb5CdOlfYSM1M18PZinSyMnx3Rj+
nR9HBgED2tiGaLbfV51+eSiEuWp9sU4Dtq+IGAq6oJRKtEWUo2iiitFDw7+HPU0d
Iix7SFPdSc687T6wxhtw/stiSHNf7XKuUIWiLe9g8Ih6iKUjpbLCDA==
=WIRv
-----END PGP SIGNATURE-----


From roland.vanrijswijk at surfnet.nl  Tue Dec  2 13:25:21 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Tue, 02 Dec 2008 14:25:21 +0100
Subject: [Opendnssec-develop] HSM vendors and common key attributes
In-Reply-To: <OF8F380D0B.4D0846C8-ON80257513.0048F22A-C1257513.00495E2F@nominet.org.uk>
References: <OFC9A4F133.4BC0EC55-ON80257513.004272D8-C1257513.00463688@nominet.org.uk>
	<493530E7.7070604@surfnet.nl>
	<OF8F380D0B.4D0846C8-ON80257513.0048F22A-C1257513.00495E2F@nominet.org.uk>
Message-ID: <49353741.3060209@surfnet.nl>

Hi Roy,

> Are you able to list, and maybe eventually participate to test, the HSMs 
> that you currently have at your disposal? 

Unfortunately, the only PKCS #11 compliant devices I have at my disposal
at the moment are:

- An NXP JCOP USB token from AET (SafeSign PKCS #11)
- An Alladin eToken USB token

Since I participated in writing the PKCS #11 for the first one mentioned
I can pretty much tell you anything about that one ;-). As for the
second one, I can give it a try, to see which attributes it supports.

I can supply you with some tokens to test with as they are good cheap
alternatives to HSMs.

I've been looking at purchasing a Luna HSM for next year when we start
deploying DNSSEC. If and when this purchase is made, I would be happy to
give you guys access to it during the development phase to test with.

Cheers,

Roland.

-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From rick at openfortress.nl  Tue Dec  2 13:26:29 2008
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 2 Dec 2008 13:26:29 +0000
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <493535B6.4020701@surfnet.nl>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>
	<A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>
	<13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>
	<20081202125321.GE28552@phantom.vanrein.org>
	<OF830CA32B.854D3F35-ON80257513.00471BBB-C1257513.00487ECA@nominet.org.uk>
	<493535B6.4020701@surfnet.nl>
Message-ID: <20081202132629.GB31764@phantom.vanrein.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

> I think a USB token could add something in some cases, as it provides
> better security than a softtoken.

Yes.  Think of the need to enter a PIN after reboot.  Won't work if
someone tries to assault your system by booting off a Live CD.

> And there is of course no reason why
> the USB token could not be connected to the signer machine permanently
> (in which case it cannot easily be misplaced).

Blade systems often have an internal USB port intended for this purpose.
This could be useful for rack-stored solutions at low (extra) cost.


Best,
 -Rick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: New to PGP? http://openfortress.nl/doc/essay/OpenPGP/index.nl.html

iD8DBQFJNTeDFBGpwol1RgYRAq0jAJ0dVicI2Fl/t6cHRbb7BFA4KQMocgCfTVbJ
A8/OnpuEc1A5Pw8RyXMretI=
=qfQg
-----END PGP SIGNATURE-----


From roland.vanrijswijk at surfnet.nl  Tue Dec  2 13:32:15 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Tue, 02 Dec 2008 14:32:15 +0100
Subject: SV: [Opendnssec-develop] SoftHSM
In-Reply-To: <69830D4127201D4EBD146B9041199718645F07@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>	<OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk><20081202115315.GD28552@phantom.vanrein.org>
	<493524A1.6040708@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645EFB@EXCHANGE.office.nic.se>
	<49352E1C.4090705@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645F07@EXCHANGE.office.nic.se>
Message-ID: <493538DF.1080207@surfnet.nl>

Hi Rickard,

Rickard Bondesson wrote:
> Then the question comes back to:
> 
> Should this be a general software implementation of a HSM or should
> it aim at the OpenDNSSEC project?

That depends on how much time there is to spend on writing the PKCS #11
module. I think it would be very helpful to have a good PKCS #11 soft
token in the public domain, but I would be the first to admit that I'm
biased. I tend to concur with you that it may be out of the scope of
OpenDNSSEC to provide this good PKCS #11 implementation... Maybe one day
if I find some time somewhere I'll lock myself up for a couple of days
and... :-)

> If we want the user to be able to specify different attributes, then
> we have to use a more complex background which can maintain these
> attributes from time to time. As of now, I just give default values
> back to user. These values are similar to those given by Roy in
> another email thread (and can be adapted to what ever we conform to).
> But what difference does it make to our project (with the SoftHSM in
> mind) if we can assign attributes? The main objective for the HSM in
> our project is to generate keys and sign data. Then I see no point of
> having the possibility to disallow certain activities other than
> specified by the defaults.

Point taken. If you want the soft token module to be as small in
footprint as possible and as simple as possible, you could chose to do
it that way. But you should at least try to make the design generic
enough that it allows for changing this to a better PKCS #11
implementation in the future, and most of all: document the choices you
make so others don't make wrong assumptions about the functionality in
the module and so they don't assume that this is normal behaviour for a
PKCS #11 module.

> "If none are specified, none are supposed to be set on the object;
> this means that no default values should be assigned"
> 
> If for example CKA_SIGN is not set by the user, how should we as a
> library act when a call comes to C_SignInit if no default values can
> be assigned by our self? If we continue to sign with the given key,
> then we could as easily just assign CKA_SIGN = CK_TRUE as a default
> in this case.

Strictly speaking, the call to C_SignInit should return
CKR_KEY_FUNCTION_NOT_PERMITTED in this case.

Cheers,

Roland.
-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From roy at nominet.org.uk  Tue Dec  2 13:39:42 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Tue, 2 Dec 2008 14:39:42 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <493535B6.4020701@surfnet.nl>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>	<A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>
	<13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>	<20081202125321.GE28552@phantom.vanrein.org>
	<OF830CA32B.854D3F35-ON80257513.00471BBB-C1257513.00487ECA@nominet.org.uk>
	<493535B6.4020701@surfnet.nl>
Message-ID: <OF440EA620.7443F02B-ON80257513.00497238-C1257513.004B0BCC@nominet.org.uk>

Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote on 12/02/2008 
02:18:46 PM:

> Hi Roy,
> 
> > Fwiw I do not see a market for USB tokens as a keystore in this sense. 
USB 
> > tokens tend to get lost, stolen, or left connected to a device (or 
left in 
> > a bar or taxi, if you work for British Government). Note that data 
needs 
> > to be signed periodically and regularly. If you have a high value 
domain, 
> > use a proper fips-140-2 level 4 HSM. If you have huge number of highly 

> > volatile domains, use an HSM that is specifically build for 
acceleration. 
> > I think it is fine, in the general case, to have a softtoken.
> 
> I think a USB token could add something in some cases, as it provides
> better security than a softtoken. And there is of course no reason why
> the USB token could not be connected to the signer machine permanently
> (in which case it cannot easily be misplaced).
> 
> Another way to use a USB token could be as a master key for a soft 
token.
> 
> I think we should not dismiss the possibility of using USB tokens in the
> scenario's described, they are a cheap intermediate solution for
> hardware security...
> 
> On the other hand good arguments for not using USB tokens could be:
> 
> - Less durable than HSMs
> - Much slower than HSMs or a soft token (many orders of magnitude!)
> - Much harder (or even impossible) to back up
> 
> Just my 2 cents there.

Thanks Roland,

A view observations:

I want OpenDNSSEC to be PKCS11 compliant. 
It seems that we must have a discussion on what compliancy actually 
entails. One extreme is full v2.20 with all the tidbits, bells and 
whistles, and the other extreme is solely the very few functions, methods 
and attributes of the pkcs11 library that we need for OpenDNSSEC. 

However, what I'd like to avoid is that we restrict PKCS11 compliance to 
the least compliant device. 

Though USB tokens are very cheap and common, can be glued to a box and 
does comply with PKCS11, I would not like it to be exemplary. 

Roy Arends
Sr. Researcher
Nominet UK


From Rickard.Bondesson at iis.se  Tue Dec  2 13:44:11 2008
From: Rickard.Bondesson at iis.se (Rickard Bondesson)
Date: Tue, 2 Dec 2008 14:44:11 +0100
Subject: SV: SV: [Opendnssec-develop] SoftHSM
In-Reply-To: <493538DF.1080207@surfnet.nl>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>	<OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk><20081202115315.GD28552@phantom.vanrein.org>
	<493524A1.6040708@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645EFB@EXCHANGE.office.nic.se>
	<49352E1C.4090705@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645F07@EXCHANGE.office.nic.se>
	<493538DF.1080207@surfnet.nl>
Message-ID: <69830D4127201D4EBD146B9041199718645F15@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

"Point taken. If you want the soft token module to be as small in footprint as possible and as simple as possible, you could chose to do it that way. But you should at least try to make the design generic enough that it allows for changing this to a better PKCS #11 implementation in the future, and most of all: document the choices you make so others don't make wrong assumptions about the functionality in the module and so they don't assume that this is normal behaviour for a PKCS #11 module."

I agree

"Strictly speaking, the call to C_SignInit should return CKR_KEY_FUNCTION_NOT_PERMITTED in this case."

True, but as I mentioned earlier:

PKCS-11v2-20 page 196 specifies that you (SoftHSM) can assign default values to attributes not specified.
- - "or else are assigned default initial values"
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSTU7q+CjgaNTdVjaAQiUCwf+Il9Fix8ja0CgZQuVoaMcpJUSp/ZUO/9e
W064UIlFwrKyuVFeT4Ns/uaDS+Ytaf4rvcreNz3GUJaS5aGkgD9cZqYFz+D0Ea06
ktuWqmPlk+jhLhX2bT0mEvT3NZjPwKuhOjwhP6Ut9Abu3o96/Oq2wKbqsyX55Db+
UwGMYyZedmWrxTRuxtsWv2b7c8zVK5xH4uBYYjkgrNE0CPXPDjFJbr6+FE+si40o
S9ltFMbbOyG7a416++iEN2I9w1s4uV0clKNl0S8lt+oEczGO9HOd4Z4SNhsBk2QY
N4XvJ6lGVx7eNN7Fpdg9MOZ2kvAD0nYrFn57uWS7YASsWdDgFS6h4Q==
=zB1s
-----END PGP SIGNATURE-----


From roland.vanrijswijk at surfnet.nl  Tue Dec  2 13:45:43 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Tue, 02 Dec 2008 14:45:43 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <OF440EA620.7443F02B-ON80257513.00497238-C1257513.004B0BCC@nominet.org.uk>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>	<A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>	<13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>	<20081202125321.GE28552@phantom.vanrein.org>
	<OF830CA32B.854D3F35-ON80257513.00471BBB-C1257513.00487ECA@nominet.org.uk>
	<493535B6.4020701@surfnet.nl>
	<OF440EA620.7443F02B-ON80257513.00497238-C1257513.004B0BCC@nominet.org.uk>
Message-ID: <49353C07.9010300@surfnet.nl>

Hi Roy,

> A view observations:
> 
> I want OpenDNSSEC to be PKCS11 compliant. 
> It seems that we must have a discussion on what compliancy actually 
> entails. One extreme is full v2.20 with all the tidbits, bells and 
> whistles, and the other extreme is solely the very few functions, methods 
> and attributes of the pkcs11 library that we need for OpenDNSSEC. 

Having written quite a few applications that used a PKCS #11 module
(both for HSMs as well as for simpler devices liken USB tokens), I can
tell you you probably won't be needing the bells and whistles. As I
stated in another mail on the list, most attributes you think we need
are such basic attributes that a device cannot be called PKCS #11
compliant if it doesn't support them.

So I'd like to look at it from another viewpoint: in my opinion, any
PKCS #11 compliant module that supports the attributes we need should
work with OpenDNSSEC.

> However, what I'd like to avoid is that we restrict PKCS11 compliance to 
> the least compliant device. 

Agreed. It should be restricted to those devices that meet our needs.

> Though USB tokens are very cheap and common, can be glued to a box and 
> does comply with PKCS11, I would not like it to be exemplary. 

True, but I think Rick may have been a tad pessimistic about the state
of PKCS #11 modules for USB tokens. On another note though: many token
vendors don't support OSes other than Windows. If you're lucky they
support some Linux distributions and Mac OS X, very few support Solaris
or BSD.

I have a proposal for a different approach: I think it makes sense to
create a simple compliancy tool that tests for the attributes and PKCS
#11 functions that OpenDNSSEC needs. Any module that passes is
supported, any module that doesn't isn't. How does that sound to you?

Cheers,

Roland.


-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From roy at nominet.org.uk  Tue Dec  2 13:49:23 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Tue, 2 Dec 2008 14:49:23 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <20081202132629.GB31764@phantom.vanrein.org>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>	<A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>
	<13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>	<20081202125321.GE28552@phantom.vanrein.org>
	<OF830CA32B.854D3F35-ON80257513.00471BBB-C1257513.00487ECA@nominet.org.uk>
	<493535B6.4020701@surfnet.nl>
	<20081202132629.GB31764@phantom.vanrein.org>
Message-ID: <OF8BFB69C3.A52222D4-ON80257513.004B44B0-C1257513.004BEE85@nominet.org.uk>

Rick van Rein wrote on 12/02/2008 02:26:29 PM:

> Hello,
> 
> > I think a USB token could add something in some cases, as it provides
> > better security than a softtoken.
> 
> Yes.  Think of the need to enter a PIN after reboot.  Won't work if
> someone tries to assault your system by booting off a Live CD.
> 
> > And there is of course no reason why
> > the USB token could not be connected to the signer machine permanently
> > (in which case it cannot easily be misplaced).
> 
> Blade systems often have an internal USB port intended for this purpose.
> This could be useful for rack-stored solutions at low (extra) cost.

I apologize for treating USB tokens as a second rate citizen. They have 
dibs on HSM tags as well ;-) 

Lets continue to help Rickard getting the softtoken both pkcs11 and 
OpenDNSSEC compliant.

Roy


From roland.vanrijswijk at surfnet.nl  Tue Dec  2 13:49:43 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Tue, 02 Dec 2008 14:49:43 +0100
Subject: SV: SV: [Opendnssec-develop] SoftHSM
In-Reply-To: <69830D4127201D4EBD146B9041199718645F15@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>	<OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk><20081202115315.GD28552@phantom.vanrein.org>
	<493524A1.6040708@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645EFB@EXCHANGE.office.nic.se>
	<49352E1C.4090705@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645F07@EXCHANGE.office.nic.se>
	<493538DF.1080207@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645F15@EXCHANGE.office.nic.se>
Message-ID: <49353CF7.5070105@surfnet.nl>

Hi Rickard,

Rickard Bondesson wrote:

> "Strictly speaking, the call to C_SignInit should return
> CKR_KEY_FUNCTION_NOT_PERMITTED in this case."
> 
> True, but as I mentioned earlier:
> 
> PKCS-11v2-20 page 196 specifies that you (SoftHSM) can assign default
> values to attributes not specified. - "or else are assigned default
> initial values"

The reason they put this in the standard is that many vendors chose to
do this while implementing modules compliant with v2.11 of the spec.
Personally, I think one shouldn't provide default values as applications
that use PKCS #11 will come to rely on this thus making them
incompatible with more strict implementations of PKCS #11... But this is
not a discussion to have on the OpenDNSSEC list, this is a more general
annoyance I have with some PKCS #11 module vendors ;-)

Cheers,

Roland.

-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From roy at nominet.org.uk  Tue Dec  2 13:56:29 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Tue, 2 Dec 2008 14:56:29 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <49353C07.9010300@surfnet.nl>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>	<A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>
	<13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>	<20081202125321.GE28552@phantom.vanrein.org>
	<OF830CA32B.854D3F35-ON80257513.00471BBB-C1257513.00487ECA@nominet.org.uk>
	<493535B6.4020701@surfnet.nl>
	<OF440EA620.7443F02B-ON80257513.00497238-C1257513.004B0BCC@nominet.org.uk>
	<49353C07.9010300@surfnet.nl>
Message-ID: <OF43F9D9A8.180A690E-ON80257513.004BFDB6-C1257513.004C9516@nominet.org.uk>

Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote on 12/02/2008 
02:45:43 PM:

> Hi Roy,
> 
> > A view observations:
> > 
> > I want OpenDNSSEC to be PKCS11 compliant. 
> > It seems that we must have a discussion on what compliancy actually 
> > entails. One extreme is full v2.20 with all the tidbits, bells and 
> > whistles, and the other extreme is solely the very few functions, 
methods 
> > and attributes of the pkcs11 library that we need for OpenDNSSEC. 
> 
> Having written quite a few applications that used a PKCS #11 module
> (both for HSMs as well as for simpler devices liken USB tokens), I can
> tell you you probably won't be needing the bells and whistles. 

I agree.

> As I
> stated in another mail on the list, most attributes you think we need
> are such basic attributes that a device cannot be called PKCS #11
> compliant if it doesn't support them.

I agree.

> So I'd like to look at it from another viewpoint: in my opinion, any
> PKCS #11 compliant module that supports the attributes we need should
> work with OpenDNSSEC.
>
> > However, what I'd like to avoid is that we restrict PKCS11 compliance 
to 
> > the least compliant device. 
> 
> Agreed. It should be restricted to those devices that meet our needs.
> 
> > Though USB tokens are very cheap and common, can be glued to a box and 

> > does comply with PKCS11, I would not like it to be exemplary. 
> 
> True, but I think Rick may have been a tad pessimistic about the state
> of PKCS #11 modules for USB tokens. On another note though: many token
> vendors don't support OSes other than Windows. If you're lucky they
> support some Linux distributions and Mac OS X, very few support Solaris
> or BSD.

ok.

> I have a proposal for a different approach: I think it makes sense to
> create a simple compliancy tool that tests for the attributes and PKCS
> #11 functions that OpenDNSSEC needs. Any module that passes is
> supported, any module that doesn't isn't. How does that sound to you?

Sounds good. This will not be core-OpenDNSSEC, but would be a contrib tool 
so to speak. Anyone on the list care to write such a thingy? 

(if not, I could write it and add it to the hsm-tools set at 
http://download.nominet.org.uk/hsm-tools/hsm-tools.tar.gz )

Roy Arends
Sr. Researcher
Nominet UK


From roland.vanrijswijk at surfnet.nl  Tue Dec  2 14:00:34 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Tue, 02 Dec 2008 15:00:34 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <OF43F9D9A8.180A690E-ON80257513.004BFDB6-C1257513.004C9516@nominet.org.uk>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>	<A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>	<13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>	<20081202125321.GE28552@phantom.vanrein.org>
	<OF830CA32B.854D3F35-ON80257513.00471BBB-C1257513.00487ECA@nominet.org.uk>
	<493535B6.4020701@surfnet.nl>
	<OF440EA620.7443F02B-ON80257513.00497238-C1257513.004B0BCC@nominet.org.uk>
	<49353C07.9010300@surfnet.nl>
	<OF43F9D9A8.180A690E-ON80257513.004BFDB6-C1257513.004C9516@nominet.org.uk>
Message-ID: <49353F82.3050605@surfnet.nl>

Hi Roy,

Roy Arends wrote:
> Sounds good. This will not be core-OpenDNSSEC, but would be a contrib tool 
> so to speak. Anyone on the list care to write such a thingy? 

I could do that though I cannot guarantee that I have the time to do it
at short notice. When do you envisage this tool would be needed?

I'd suggest writing it on the basis of a test framework like CPPunit
which has excellent support for reporting, retesting, selectively
turning tests on and off.

Cheers,

Roland.

-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From roy at nominet.org.uk  Tue Dec  2 14:05:45 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Tue, 2 Dec 2008 15:05:45 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <49353F82.3050605@surfnet.nl>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>	<A59A2E52-B384-43FD-AE3C-4723F719BC04@jadickinson.co.uk>
	<13E485BC-13B6-4397-A627-900AF69C64E9@NLnetLabs.nl>	<20081202125321.GE28552@phantom.vanrein.org>
	<OF830CA32B.854D3F35-ON80257513.00471BBB-C1257513.00487ECA@nominet.org.uk>
	<493535B6.4020701@surfnet.nl>
	<OF440EA620.7443F02B-ON80257513.00497238-C1257513.004B0BCC@nominet.org.uk>
	<49353C07.9010300@surfnet.nl>
	<OF43F9D9A8.180A690E-ON80257513.004BFDB6-C1257513.004C9516@nominet.org.uk>
	<49353F82.3050605@surfnet.nl>
Message-ID: <OF84A86319.EB46F80A-ON80257513.004D16C7-C1257513.004D6E57@nominet.org.uk>

Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote on 12/02/2008 
03:00:34 PM:

> Hi Roy,
> 
> Roy Arends wrote:
> > Sounds good. This will not be core-OpenDNSSEC, but would be a contrib 
tool 
> > so to speak. Anyone on the list care to write such a thingy? 
> 
> I could do that though I cannot guarantee that I have the time to do it
> at short notice. When do you envisage this tool would be needed?

It would be nice to have when we go live with OpenDNSSEC, so folks can 
test their stuff, report back, and have us list it under some "tested ok!" 
area on the OpenDNSSEC website.

> I'd suggest writing it on the basis of a test framework like CPPunit
> which has excellent support for reporting, retesting, selectively
> turning tests on and off.

I have no prefs. CPPunit is fine with me.

Thanks for the offer!

Roy Arends
Sr. Researcher
Nominet UK


From rick at openfortress.nl  Tue Dec  2 20:26:16 2008
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 2 Dec 2008 20:26:16 +0000
Subject: [Opendnssec-develop] Signing two-faced domains
Message-ID: <20081202202616.GA3713@phantom.vanrein.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

There is one more anomaly in DNS usage patterns that I think is valuable
to discuss early in the design of OpenDNSSEC.


High-profile domains will run on multiple locations, and employ DNS to
make a quick switch from the primary location to a backup if the primary
fails.  This usually means that more than one view on a zone is valid
at the same time.  There are a few ways of supporting this under DNSSEC:

1. Publish a DS record per view.  Not likely that a zone's parent is
   going to want this though.  Parents are usually the kind of people
   that enviously try to give all children an equal treat.

2. Use the same KSK for each view on a domain.  Synchronise key roll-over
   (which is fairly trivial as the same parent is being watched for the
   same domain) and simply don't publish the backup views until they are
   needed.  This seems to be the most likely scenario.

3. Quickly update DNS and re-sign when there is a need to switch to a
   backup location.  This alternative has a few disadvantages that
   conflict with the desires at the time of primary site failure,
   namely (1) that it takes time and (2) that it uses more resources
   and is thus more likely to break during a time of crisis.

This is another reason to allow signing of multiple zones with a shared
key.  But there's another exceptional issue happening here: there may
be two or more concurrent versions of the same zone, and each will have
to be signed.  In terms of programming, the name of a SOA record cannot
be treated as an identity for a zone to sign!


A similar problem applies to multiple-view domains, such as those with
a different internal/external view.  Those are more trivial however,
as internal settings in the vicinity of the secure resolver can easily
be overridden without doing DNSSEC (at least until each desktop resolves
securely on its own).


I don't know if this has been discussed before, since we've just landed
on the list and since there's no public archive available.


Cheers,

Rick van Rein
OpenFortress Digital signatures
http://openfortress.nl/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: New to PGP? http://openfortress.nl/doc/essay/OpenPGP/index.nl.html

iD8DBQFJNZnYFBGpwol1RgYRAmB0AJ9hwKUQVnc4qWUvkEE4b1RY6cRDlACbBMD/
Ond6MmissbsGIf1PyfvFpuI=
=+d1v
-----END PGP SIGNATURE-----


From roy at nominet.org.uk  Tue Dec  2 20:47:51 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Tue, 2 Dec 2008 21:47:51 +0100
Subject: [Opendnssec-develop] Signing two-faced domains
In-Reply-To: <20081202202616.GA3713@phantom.vanrein.org>
References: <20081202202616.GA3713@phantom.vanrein.org>
Message-ID: <OF3946E7B3.57122CB9-ON80257513.00709F53-C1257513.00723E8D@nominet.org.uk>

Rick van Rein wrote on 12/02/2008 09:26:16 PM:

> Hello,
> 
> There is one more anomaly in DNS usage patterns that I think is valuable
> to discuss early in the design of OpenDNSSEC.
> 
> High-profile domains will run on multiple locations, and employ DNS to
> make a quick switch from the primary location to a backup if the primary
> fails.  This usually means that more than one view on a zone is valid
> at the same time.  There are a few ways of supporting this under DNSSEC:
> 
> 1. Publish a DS record per view.  Not likely that a zone's parent is
>    going to want this though.  Parents are usually the kind of people
>    that enviously try to give all children an equal treat.
> 
> 2. Use the same KSK for each view on a domain.  Synchronise key 
roll-over
>    (which is fairly trivial as the same parent is being watched for the
>    same domain) and simply don't publish the backup views until they are
>    needed.  This seems to be the most likely scenario.
> 
> 3. Quickly update DNS and re-sign when there is a need to switch to a
>    backup location.  This alternative has a few disadvantages that
>    conflict with the desires at the time of primary site failure,
>    namely (1) that it takes time and (2) that it uses more resources
>    and is thus more likely to break during a time of crisis.

I see no problem here, as long as these views are reachable from the 
public internet, and as long as the KSK that was used to create the DS 
record at the parent does not change. There is a slight issue when view 
specific NSEC or NSEC3 chains are mutual exclusive, but that is unlikely.
 
> This is another reason to allow signing of multiple zones with a shared
> key.

I disagree. These are not multiple zones. These are multiple views of a 
single zone. I'm not splitting hairs, these are different concepts.

> But there's another exceptional issue happening here: there may
> be two or more concurrent versions of the same zone, and each will have
> to be signed.  In terms of programming, the name of a SOA record cannot
> be treated as an identity for a zone to sign!

Yes. Good point.

> A similar problem applies to multiple-view domains, such as those with
> a different internal/external view.  Those are more trivial however,
> as internal settings in the vicinity of the secure resolver can easily
> be overridden without doing DNSSEC (at least until each desktop resolves
> securely on its own). 
> 
> I don't know if this has been discussed before, since we've just landed
> on the list and since there's no public archive available.

Actually, there is a public archive:

http://lists.opendnssec.org/pipermail/opendnssec-develop/
 
but the url is not public.

Regards,

Roy Arends
Sr. Researcher
Nominet UK


From Rickard.Bondesson at iis.se  Wed Dec  3 12:18:39 2008
From: Rickard.Bondesson at iis.se (Rickard Bondesson)
Date: Wed, 3 Dec 2008 13:18:39 +0100
Subject: [Opendnssec-develop] Thread safety
Message-ID: <69830D4127201D4EBD146B9041199718645F8A@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

One comment in hsm-speed.c says:

// Initialize Library
// Note that we do not need mutex locking for thread safety,
// since we're using one session per thread.

But PKCS11 says:

"A call to C_Initialize with pInitArgs set to NULL_PTR is treated like a call to
C_Initialize with pInitArgs pointing to a CK_C_INITIALIZE_ARGS which has the
CreateMutex, DestroyMutex, LockMutex, UnlockMutex, and pReserved fields set to
NULL_PTR, and has the flags field set to 0."

And

"1. If the flag isn?t set, and the function pointer fields aren?t supplied (i.e., they all have
the value NULL_PTR), that means that the application won?t be accessing the
Cryptoki library from multiple threads simultaneously."

This means that the HSM will not create any locking mechanisms for its crucial components like its object store, which in my case are shared between the sessions.

My SoftHSM will because of this fail, when the hsm-speed.c runs multiple threads, due to multiple accesses to a single object. (The failure is in the crypto lib when it accesses its key objects. The lib is thread safe but not for a single object.)

Which is the appropriate action? Should I, as a HSM, create locks although the external application did not want me to do that? Or should the hsm-speed.c be modified so that it either provides mutex functions or tell the HSM to use its own mutex functions.

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSTZ5H+CjgaNTdVjaAQgttgf/a+ePbBbnsOqp88qOoG6wjl28ta3LoJoc
qesDBhDQfC8tjCOvbRj1ey7C5J5slzQYLCxlfR24ob/QZL7jjwHgXw74dwEDHSUC
5w2RrnoJefKdWkCcSCnWWlrEE9KP30TRH7rbIMf41w+t+jsFx12ywKLYx1rfzzoe
hcwPJUMUIyxsQLdv1BNkUlbc6FRHwatMY8TXM1TnUUMMyNohwxwz1LM8nmzXl/kw
wyz82Blj9lbPTuAM+3SQ+yXpUcVKR6dRveq1azOE3t5g7CPLAFB8hFaVjdKtMWpW
JCQ3ZAIKmQLckMy54xvg2Ha8pbheXyvNpgy2D0CvqAE5cELb+y/C6w==
=44rA
-----END PGP SIGNATURE-----


From roland.vanrijswijk at surfnet.nl  Wed Dec  3 19:39:24 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Wed, 03 Dec 2008 20:39:24 +0100
Subject: [Opendnssec-develop] Thread safety
In-Reply-To: <69830D4127201D4EBD146B9041199718645F8A@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718645F8A@EXCHANGE.office.nic.se>
Message-ID: <4936E06C.7010300@surfnet.nl>

Hi Rickard,

It is up to an application that uses a PKCS #11 module to specify which 
threading model it uses. Section 6.6.2 specifies which options there 
are, I'll summarise here:

1. No multithreading
2. Multithreading using OS primitives
3. Multithreading using application supplied primitives
4. Multithreading using either OS primitives or app-supplied primitives

If the application indicates that "OS locking is OK", then that means 
that the PKCS #11 module must make sure that any calls to it are thread 
safe by protecting access to shared resources using standard OS calls 
for locking. So that means you have to implement locking behaviour. The 
best way to do this is to create an abstract interface for locking which 
either calls OS locking services or application supplied services based 
on the settings supplied in the call to C_Initialize or performs no 
locking at all if C_Initialize was called with a NULL_PTR parameter.

Does that help?

Cheers,

Roland.

Rickard Bondesson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> One comment in hsm-speed.c says:
> 
> // Initialize Library
> // Note that we do not need mutex locking for thread safety,
> // since we're using one session per thread.
> 
> But PKCS11 says:
> 
> "A call to C_Initialize with pInitArgs set to NULL_PTR is treated like a call to
> C_Initialize with pInitArgs pointing to a CK_C_INITIALIZE_ARGS which has the
> CreateMutex, DestroyMutex, LockMutex, UnlockMutex, and pReserved fields set to
> NULL_PTR, and has the flags field set to 0."
> 
> And
> 
> "1. If the flag isn?t set, and the function pointer fields aren?t supplied (i.e., they all have
> the value NULL_PTR), that means that the application won?t be accessing the
> Cryptoki library from multiple threads simultaneously."
> 
> This means that the HSM will not create any locking mechanisms for its crucial components like its object store, which in my case are shared between the sessions.
> 
> My SoftHSM will because of this fail, when the hsm-speed.c runs multiple threads, due to multiple accesses to a single object. (The failure is in the crypto lib when it accesses its key objects. The lib is thread safe but not for a single object.)
> 
> Which is the appropriate action? Should I, as a HSM, create locks although the external application did not want me to do that? Or should the hsm-speed.c be modified so that it either provides mutex functions or tell the HSM to use its own mutex functions.
> 
> // Rickard
> -----BEGIN PGP SIGNATURE-----
> Version: 9.8.3 (Build 4028)
> Charset: utf-8
> 
> wsBVAwUBSTZ5H+CjgaNTdVjaAQgttgf/a+ePbBbnsOqp88qOoG6wjl28ta3LoJoc
> qesDBhDQfC8tjCOvbRj1ey7C5J5slzQYLCxlfR24ob/QZL7jjwHgXw74dwEDHSUC
> 5w2RrnoJefKdWkCcSCnWWlrEE9KP30TRH7rbIMf41w+t+jsFx12ywKLYx1rfzzoe
> hcwPJUMUIyxsQLdv1BNkUlbc6FRHwatMY8TXM1TnUUMMyNohwxwz1LM8nmzXl/kw
> wyz82Blj9lbPTuAM+3SQ+yXpUcVKR6dRveq1azOE3t5g7CPLAFB8hFaVjdKtMWpW
> JCQ3ZAIKmQLckMy54xvg2Ha8pbheXyvNpgy2D0CvqAE5cELb+y/C6w==
> =44rA
> -----END PGP SIGNATURE-----
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop


-- 
-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From roy at nominet.org.uk  Wed Dec  3 23:51:44 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Thu, 4 Dec 2008 00:51:44 +0100
Subject: [Opendnssec-develop] Thread safety
In-Reply-To: <69830D4127201D4EBD146B9041199718645F8A@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718645F8A@EXCHANGE.office.nic.se>
Message-ID: <OF0C7FD62E.5BF19050-ON80257514.0065B94D-C1257514.0083143B@nominet.org.uk>

Rickard Bondesson wrote on 12/03/2008 01:18:39 PM:

> One comment in hsm-speed.c says:
> 
> // Initialize Library
> // Note that we do not need mutex locking for thread safety,
> // since we're using one session per thread.
> 
> But PKCS11 says:
> 
> "A call to C_Initialize with pInitArgs set to NULL_PTR is treated 
> like a call to
> C_Initialize with pInitArgs pointing to a CK_C_INITIALIZE_ARGS which has 
the
> CreateMutex, DestroyMutex, LockMutex, UnlockMutex, and pReserved fields 
set to
> NULL_PTR, and has the flags field set to 0."
> 
> And
> 
> "1. If the flag isn?t set, and the function pointer fields aren?t 
> supplied (i.e., they all have
> the value NULL_PTR), that means that the application won?t be accessing 
the
> Cryptoki library from multiple threads simultaneously."
> 
> This means that the HSM will not create any locking mechanisms for 
> its crucial components like its object store, which in my case are 
> shared between the sessions.

In general, when you have multiple threads, and all threads use the same 
object X and there is only one global session, you'd need to set a lock 
before calling C_SignInit and unlock it after C_SignFinal. Otherwise 
things go completely haywire.

However, using a session per thread makes sure that the call serie 
(C_SignInit, C_Sign) is orthogonal and independent from other call series. 
This is needed when you want to optimize the use of HSMs for speed. 
Needless to say, using mutex concepts will bog down performance 
significantly. Also see the section "Notes on PKCS11" from this article: 
http://blog.nominet.org.uk/tech/2008/06/02/40k-signatures-second-on-fips-140-2-level-3-hardware/

> My SoftHSM will because of this fail, when the hsm-speed.c runs 
> multiple threads, due to multiple accesses to a single object. (The 
> failure is in the crypto lib when it accesses its key objects. The 
> lib is thread safe but not for a single object.)
> 
> Which is the appropriate action? Should I, as a HSM, create locks 
> although the external application did not want me to do that? Or 
> should the hsm-speed.c be modified so that it either provides mutex 
> functions or tell the HSM to use its own mutex functions.

Modifying hsm-speed.c is always an option (since it is my code anyway), 
but consider that hsm-speed.c works, without exception on 5 different, 
completely independent PKCS11 libraries. 

This is what I can offer from the standard: section 6.7.6:

"... an application should never make multiple simultaneous function calls 
to Cryptoki which use a common session.  If multiple threads of an 
application attempt to use a common session concurrently in this fashion, 
Cryptoki does not define what happens."

(this implicitly says don't use multiple threads per session, use at most 
one thread per session.)

" This means that if multiple threads of an application all need to use 
Cryptoki to access a particular token, it might be appropriate for each 
thread to have its own session with the token, unless the application can 
ensure by some other means (e.g., by some locking mechanism) that no 
sessions are ever used by multiple threads simultaneously."

(Since I do not want to use a locking mechanism to avoid impact on 
performance, I was left with using a session per thread)

" This is true regardless of whether or not the Cryptoki library was 
initialized in a fashion which permits safe multi-threaded access to it. 
Even if it is safe to access the library from multiple threads 
simultaneously, it is still not necessarily safe to use a particular 
session from multiple threads simultaneously. "

(This actually shows that sharing a session across multiple threads is not 
recommended, not even safe).

Hope this helps a bit.

Regards,

Roy Arends
Sr. Researcher
Nominet UK


From Rickard.Bondesson at iis.se  Thu Dec  4 07:50:14 2008
From: Rickard.Bondesson at iis.se (Rickard Bondesson)
Date: Thu, 4 Dec 2008 08:50:14 +0100
Subject: SV: [Opendnssec-develop] Thread safety
In-Reply-To: <OF0C7FD62E.5BF19050-ON80257514.0065B94D-C1257514.0083143B@nominet.org.uk>
References: <69830D4127201D4EBD146B9041199718645F8A@EXCHANGE.office.nic.se>
	<OF0C7FD62E.5BF19050-ON80257514.0065B94D-C1257514.0083143B@nominet.org.uk>
Message-ID: <69830D4127201D4EBD146B9041199718645FDC@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I agree about the different use cases for the HSM initializing and a good interface for mutex support is implemented on the SoftHSM. I also agree on the one thread per session. So you mean that nothing should be shared between sessions? Each session should for example have its own copy of the object store? And all objects should be CKA_TOKEN = CK_FALSE, meaning that they are session objects and not token objects.

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSTeLtuCjgaNTdVjaAQhhKQf+MPpcDf1ISRSPOAibCMV28Dty2KZZrpuC
cLQ7cbYVK/xI+Q+L+S4JPOx8u/wqkSp+54kGKkijSAUx+kWmRSf/SEAvT6TBmxmx
IJegFe2u59Y7bWXa4tAbVZWreP5ectpLauiiukorY5wA1q+JXJEopCAphQHcmQlp
itJcv3XXsL7xPkHYdtUk66lhaAqOK/0Ddh6LvEwcaj2Pg3EFJ1NRgIdhYrPdjg2Z
hzQFssc7tCOkFYhE8Dcop7Lk9ItWkIFVbpOkReQL0c0qJdkZg+YhXurEg43UaQpH
/Ai1hVJgHM8cBMxAaQ/tDOmGjGMnvVytlrYl8fxYQVgw1RZJmRsR3g==
=HSYh
-----END PGP SIGNATURE-----


From rick at openfortress.nl  Thu Dec  4 09:37:29 2008
From: rick at openfortress.nl (Rick van Rein)
Date: Thu, 4 Dec 2008 09:37:29 +0000
Subject: [Opendnssec-develop] Domain transfers under DNSSEC
Message-ID: <20081204093729.GC22871@phantom.vanrein.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I am pondering how domain transfers would take place under DNSSEC.
As expected, SIDN worries about it, and it also touches on OpenDNSSEC
(evntually) when the platform is used by a hosting provider.

We would not want to share private key material between an old and new
signer, since these will usually be different parties and because the
same key may (according to some on this list at least) be shared among
multiple zones.

A transfer is effectively a NS change in a TLD server.  Since NS and DS
records are presented at the same time, it is possible AFAIK to do a
simultaneous DS changeover, in such a way that no cache will ever hold
NS from one generation, and DS from another.

Given this, it should be possible to do a key rollover, even with a single
DS at the parent, by performing a variation on the KSK rollover procedure,
using temporary double KSK signatures:

1. Setup DNSSEC on the new signer
2. Move the old KSK to the new signer and move the new KSK to the old signer
3. Sign the zone on the old and new signer and hold off auto-resigning
4. Append old RRSig(KSK) in the new zone and new RRSig(KSK) in the old zone
5. Allow time for caches to pick up on the new zone data
6. Ask the parent to switch to the new DS+NS records simultaneously
7. Wait for the parent to publish the new DS+NS records
8. Wait for caches to pick up on the new DS+NS records and shutdown old signer
9. Remove the old DNSKEY from the new zone and resign at your leasure

I think this should work based on the following principles/assumptions:

1. DS and NS changes can be made at the same time

2. DNSKEY records should simply be added to the pre-signing zone

3. RRSig records can simply be appended to a signed zone (wow, hack!)

4. NSEC3 calculations do not have to be redone when RRSig records are added
   as long as the name of the newly added RRSig already has an RRSig on it.

5. The loosing registrar cooperates, by incorporating the new key material
   and signatures.  This has legal implications (making registrars cooperate),
   technical (making registrars synchronise on the procedure) and security
   (the old registrar must be convinced the transfer is proper, which probably
   applies to any transfer scheme without downtime).  Although cooperation
   could be enforced by registry ruling, it is probably the weak point of
   this scheme.  Note however, that the information exchanged between the
   old and new registrar is all public.


Could this be a useful aspect to take into account for v2 of OpenDNSSEC?
I think it could dramatically ease the worries of a TLD.  Also, it points
out a form of cooperation that TLDs may want to use as an obligation to
registrars who support DNSSEC.


Hope this helps,
 -Rick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: New to PGP? http://openfortress.nl/doc/essay/OpenPGP/index.nl.html

iD8DBQFJN6TZFBGpwol1RgYRAsmQAKCNkJsmM4hSBNZG6f0xluHz3Rp/lACdELln
jKNTCmGjoJNtEnDQLz+xZCU=
=Cszr
-----END PGP SIGNATURE-----


From Rickard.Bondesson at iis.se  Thu Dec  4 16:27:01 2008
From: Rickard.Bondesson at iis.se (Rickard Bondesson)
Date: Thu, 4 Dec 2008 17:27:01 +0100
Subject: [Opendnssec-develop] SoftHSM back-end database
Message-ID: <69830D4127201D4EBD146B9041199718646039@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi

I have designed a back-end database for the SoftHSM which will remember the keys and its attributes from time to time. The current implementation of SoftHSM store the keys directly on the disc and auto generate the attributes. But we had a discussion about having a possibility to specify the attributes. So, attached is my design of the database with tables and columns. It presents all the possible attributes, but some of them are chosen not to be stored in the database.

Any comments or questions?

(The HSM speed test shows 820 signatures per second)

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSTgE1eCjgaNTdVjaAQhCswf/dkb4n4HM4jG8dwIKCSIrzdGCzfbBhaQ6
E90/a9r17639z4aI9hzq/9f1EAS4IIj3TYrtSYgtFRm8pmQRXbl5dNXoAxrLxv3R
naurn/HEK4wmkrJrDksdB3TLFjM0Z7DLyCz5S0VJiaVcqo7abcm8Ki5eZWnHuofw
ejjrJYJX4id8avUp6kNz0UHniu2QXYDRUaaky1uectnwHmAZOX7BIyixgASDWI5A
IeTjFgV0qiv2rDdKzEMtaryt8mmCdXZ0rZPXKio/9Wt0Axdj3xj/Qa6ZPyeToe1G
XN9/Gf5weJF51gXL6TrhWCgtHdyYhEAMDuyXeGlnzQ1Nr1RUc0FK1w==
=MmY+
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SoftHSM_database.pdf
Type: application/octet-stream
Size: 33910 bytes
Desc: SoftHSM_database.pdf
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081204/0d8aec22/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SoftHSM_database.pdf.sig
Type: application/octet-stream
Size: 486 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081204/0d8aec22/attachment-0001.obj>

From roy at nominet.org.uk  Fri Dec  5 11:13:31 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Fri, 5 Dec 2008 12:13:31 +0100
Subject: [Opendnssec-develop] Domain transfers under DNSSEC
In-Reply-To: <20081204093729.GC22871@phantom.vanrein.org>
References: <20081204093729.GC22871@phantom.vanrein.org>
Message-ID: <OF119A3212.2307E1E3-ON80257515.0036C366-C1257516.003DA8FB@nominet.org.uk>

Rick van Rein wrote on 12/04/2008 10:37:29 AM:

> Hello,
> 
> I am pondering how domain transfers would take place under DNSSEC.
> As expected, SIDN worries about it, and it also touches on OpenDNSSEC
> (evntually) when the platform is used by a hosting provider.
> 
> We would not want to share private key material between an old and new
> signer, since these will usually be different parties and because the
> same key may (according to some on this list at least) be shared among
> multiple zones.
> 
> A transfer is effectively a NS change in a TLD server.  Since NS and DS
> records are presented at the same time, it is possible AFAIK to do a
> simultaneous DS changeover, in such a way that no cache will ever hold
> NS from one generation, and DS from another.
> 
> Given this, it should be possible to do a key rollover, even with a 
single
> DS at the parent, by performing a variation on the KSK rollover 
procedure,
> using temporary double KSK signatures:
> 
> 1. Setup DNSSEC on the new signer
> 2. Move the old KSK to the new signer and move the new KSK to the old 
signer
> 3. Sign the zone on the old and new signer and hold off auto-resigning
> 4. Append old RRSig(KSK) in the new zone and new RRSig(KSK) in the old 
zone
> 5. Allow time for caches to pick up on the new zone data
> 6. Ask the parent to switch to the new DS+NS records simultaneously
> 7. Wait for the parent to publish the new DS+NS records
> 8. Wait for caches to pick up on the new DS+NS records and shutdown old 
signer
> 9. Remove the old DNSKEY from the new zone and resign at your leasure

This assumes that the transferring parties are highly cooperative, which 
is not the general case. When 'hostile' parties transfer a domain, it will 
probably fall back to unsigned (ie. no DS record at parent). When 
'friendly' parties transfer a domain, the new owner can present the DS+NS 
record. The scheduling for this scenario is the same as a standard domain 
transfer, though the impact is bigger when either party (or the parent) 
screws up.
 
> I think this should work based on the following principles/assumptions:
> 
> 1. DS and NS changes can be made at the same time
> 
> 2. DNSKEY records should simply be added to the pre-signing zone
> 
> 3. RRSig records can simply be appended to a signed zone (wow, hack!)
> 
> 4. NSEC3 calculations do not have to be redone when RRSig records are 
added
>    as long as the name of the newly added RRSig already has an RRSig on 
it.
> 
> 5. The loosing registrar cooperates, by incorporating the new key 
material
>    and signatures.  This has legal implications (making registrars 
cooperate),
>    technical (making registrars synchronise on the procedure) and 
security
>    (the old registrar must be convinced the transfer is proper, which 
probably
>    applies to any transfer scheme without downtime).  Although 
cooperation
>    could be enforced by registry ruling, it is probably the weak point 
of
>    this scheme.  Note however, that the information exchanged between 
the
>    old and new registrar is all public.
> 
> 
> Could this be a useful aspect to take into account for v2 of OpenDNSSEC?
> I think it could dramatically ease the worries of a TLD.  Also, it 
points
> out a form of cooperation that TLDs may want to use as an obligation to
> registrars who support DNSSEC.

It might be useful, but the possible scenarios of registrant/hosting 
farm/registrar/registry are so diverse, it is likely that whatever code we 
produce to ease that problem will only cause confusion to those who can't 
use it.

I do not want to declare it 'out of scope' though. Coming year, a few 
large registries will deploy DNSSEC, and we can gauge the community a bit 
and see where things converge.

Thanks.

Regards,

Roy Arends
Sr. Researcher
Nominet UK





From rick at openfortress.nl  Fri Dec  5 11:22:15 2008
From: rick at openfortress.nl (Rick van Rein)
Date: Fri, 5 Dec 2008 11:22:15 +0000
Subject: [Opendnssec-develop] Domain transfers under DNSSEC
In-Reply-To: <OF119A3212.2307E1E3-ON80257515.0036C366-C1257516.003DA8FB@nominet.org.uk>
References: <20081204093729.GC22871@phantom.vanrein.org>
	<OF119A3212.2307E1E3-ON80257515.0036C366-C1257516.003DA8FB@nominet.org.uk>
Message-ID: <20081205112215.GA6391@phantom.vanrein.org>

Hi Roy,

> This assumes that the transferring parties are highly cooperative, which 
> is not the general case.

I also think that a scheme with two DS records is simpler to run
Having to enforce rules legally simply isn't going to be fun

> It might be useful, but the possible scenarios of registrant/hosting 
> farm/registrar/registry are so diverse, it is likely that whatever code we 
> produce to ease that problem will only cause confusion to those who can't 
> use it.

My main aim is to be early in identifing exception domain actions
As it helps to identify concepts and split them into just the right fractions


-Rick


From olaf at NLnetLabs.nl  Mon Dec  8 14:59:51 2008
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Mon, 8 Dec 2008 15:59:51 +0100
Subject: [Opendnssec-develop] Domain transfers under DNSSEC
In-Reply-To: <OF119A3212.2307E1E3-ON80257515.0036C366-C1257516.003DA8FB@nominet.org.uk>
References: <20081204093729.GC22871@phantom.vanrein.org>
	<OF119A3212.2307E1E3-ON80257515.0036C366-C1257516.003DA8FB@nominet.org.uk>
Message-ID: <1998DCCE-368E-46BB-BED9-7528681628A2@NLnetLabs.nl>


On Dec 5, 2008, at 12:13 PM, Roy Arends wrote:

>
> This assumes that the transferring parties are highly cooperative,  
> which
> is not the general case. When 'hostile' parties transfer a domain,  
> it will
> probably fall back to unsigned (ie. no DS record at parent).

Or two DSs at the parents: the old and the new one. Only the new NS-es.

Note that if the uncooperative party puts a long TTL on both the NS  
and the security records a client may be retrieving old records for a  
very long time. In that case the new party may actually force  
validation failure for the old parties. Depending on how much harm the  
old party does.



--Olaf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081208/a9c7d4a5/attachment.bin>

From olaf at NLnetLabs.nl  Wed Dec 10 11:23:16 2008
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Wed, 10 Dec 2008 12:23:16 +0100
Subject: [Opendnssec-develop] project plan and SURFnet
In-Reply-To: <OFD7B3696C.4A0E4A01-ON8025750F.003EC220-C125750F.005A58C6@nominet.org.uk>
References: <OFD7B3696C.4A0E4A01-ON8025750F.003EC220-C125750F.005A58C6@nominet.org.uk>
Message-ID: <87601193-81E0-46DC-82D7-EE4548F76428@NLnetLabs.nl>


On Nov 28, 2008, at 5:26 PM, Roy Arends wrote:

> Dear OpenDNSSEC folk,
>
> I have yet to finish the project plan (I'm not slacking, just  
> swamped),
> but will dump here what I already have (see attached pdf) written. It
> contains the high level overview of components (which we already  
> assigned
> to different folk).

Roy,

I understand that you will be in Venuzuela as of tomorrow (vacation  
full time, or telecommuting too?). What does that mean for the  
development of the plan?


Just to be explicit about my expectations: What I really want to have  
out of a project plan is a set of milestones, how those milestones  
hang together and who is responsible for what?  Also the plan should  
be clear on the deliverables and the commitments after the work has  
been finished.

I have some idea on what the responsibilities for labs are but that is  
not clear in the current text.

So much for the managerial questions.


I have one technical question. How does the machinery deal with a zone  
which needs to be partially signed (e.g. one 10th of the records gets  
signed every 10 days)? I guess that the KASP would record such policy  
but it is not clear to me where in the design the intelligence lives  
to select those records?

--Olaf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081210/d8e7e2a6/attachment.bin>

From olaf at NLnetLabs.nl  Wed Dec 10 13:41:10 2008
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Wed, 10 Dec 2008 14:41:10 +0100
Subject: SV: [Opendnssec-develop] SoftHSM
In-Reply-To: <493538DF.1080207@surfnet.nl>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>	<OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk><20081202115315.GD28552@phantom.vanrein.org>
	<493524A1.6040708@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645EFB@EXCHANGE.office.nic.se>
	<49352E1C.4090705@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645F07@EXCHANGE.office.nic.se>
	<493538DF.1080207@surfnet.nl>
Message-ID: <4E5863E4-2BE8-4D70-849C-D2D5462DFB0C@NLnetLabs.nl>


On Dec 2, 2008, at 2:32 PM, Roland van Rijswijk wrote:

> Point taken. If you want the soft token module to be as small in
> footprint as possible and as simple as possible,


clarification question: are we assuming these are requirements for the  
softtoken in OpenDNSSEC or is this an observation about the needs of  
smartcard builders?

I read the latter but if the former I want to understand the arguments  
for the requirements.


--Olaf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081210/c451bebb/attachment.bin>

From roland.vanrijswijk at surfnet.nl  Wed Dec 10 16:09:09 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Wed, 10 Dec 2008 17:09:09 +0100
Subject: SV: [Opendnssec-develop] SoftHSM
In-Reply-To: <4E5863E4-2BE8-4D70-849C-D2D5462DFB0C@NLnetLabs.nl>
References: <69830D4127201D4EBD146B9041199718645E85@EXCHANGE.office.nic.se>	<OFDBD1CFD8.A4BC579A-ON80257512.0043903A-C1257512.0044B05D@nominet.org.uk><20081202115315.GD28552@phantom.vanrein.org>
	<493524A1.6040708@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645EFB@EXCHANGE.office.nic.se>
	<49352E1C.4090705@surfnet.nl>
	<69830D4127201D4EBD146B9041199718645F07@EXCHANGE.office.nic.se>
	<493538DF.1080207@surfnet.nl>
	<4E5863E4-2BE8-4D70-849C-D2D5462DFB0C@NLnetLabs.nl>
Message-ID: <493FE9A5.30004@surfnet.nl>

Hi Olaf, Rickard,

Olaf Kolkman wrote:
> 
> On Dec 2, 2008, at 2:32 PM, Roland van Rijswijk wrote:
> 
>> Point taken. If you want the soft token module to be as small in
>> footprint as possible and as simple as possible,
> 
> 
> clarification question: are we assuming these are requirements for the
> softtoken in OpenDNSSEC or is this an observation about the needs of
> smartcard builders?

>From my point of view, having as small a footprint as possible and as
little functionality as strictly necessary is not a hard requirement. It
depends on the effect this has on the development time. If it takes too
long to build a more function rich module, then this would be an
argument to keep it _very_ simple. Otherwise I would say: keep it simple
but sensible and if possible extensible.

I cannot judge what impact this has on the overall project, since I
don't know the timelines yet though.

>From my perspective, it is risky to write any PKCS #11 implementation
that imposes restrictions on functionality that cannot be expressed in
capabilities that the module reports to the users. In other words: if
the standard doesn't provide you with a way to tell users that you don't
support certain things you should implement them. And if you really feel
that you cannot implement them then this should be documented very well...

Does that answer your question?

Cheers,

Roland.

-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From Rickard.Bondesson at iis.se  Thu Dec 11 16:22:27 2008
From: Rickard.Bondesson at iis.se (Rickard Bondesson)
Date: Thu, 11 Dec 2008 17:22:27 +0100
Subject: [Opendnssec-develop] SoftHSM - Signing speed
Message-ID: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The SoftHSM can now produce 2200 sig/sec (RSA768) with the hsm-speed-test:

./hsm-speed -t 9 -s 1 -p apaapa123 -i 20000 081211153928020162

And RSA1024 gives 1700 sig/sec
And RSA2048 gives 380 sig/sec

This is without any compiler optimizations.

What do you think about the speeds? Are they reasonable?

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSUE+Q+CjgaNTdVjaAQhngAgAp8i5BHMJMG/3NmovDahQn+zvzHqiMyJt
tgKNZoxe2lXKjFQL2Yn3HVjkgASgYBwjJ7KRWEUQHfpS9hKgul/VyapyqCoC6Fog
NVtrzsCFeVmZWqIVwy2kPUpoIKRPeNo5w3hysa8ZNuQmwAMsFjNHlHdwxucdFyrN
RgU8Ww790ouxXyLAB+2fpbX1xfb9G6/kwX9dH1NnUb7RcbTF+EZF1F/T3uB6z5Dk
20KbDuR3a4PKqqjUgRTDW8N4+EBiFX6SPIdyLogtULQ9+40tO4VRVwQklYEEqEGx
pi55E1W94C157lU6QbTt5BxGzaR+U3GF0OMnamuL0GLkvicxHKSOfw==
=9int
-----END PGP SIGNATURE-----


From roy at nominet.org.uk  Thu Dec 11 17:16:26 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Thu, 11 Dec 2008 18:16:26 +0100
Subject: [Opendnssec-develop] SoftHSM - Signing speed
In-Reply-To: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se>
Message-ID: <OFD399614D.D1776874-ON8025751C.005E858B-C125751C.005EE282@nominet.org.uk>

Rickard Bondesson wrote on 12/11/2008 05:22:27 PM:

> The SoftHSM can now produce 2200 sig/sec (RSA768) with the 
hsm-speed-test:
> 
> ./hsm-speed -t 9 -s 1 -p apaapa123 -i 20000 081211153928020162
> 
> And RSA1024 gives 1700 sig/sec
> And RSA2048 gives 380 sig/sec
> 
> This is without any compiler optimizations.
> 
> What do you think about the speeds? Are they reasonable?

Very reasonable!

I assume that SoftHSM is using OpenSSL, right? Could you issue the OpenSSL 
speed command? "$ openssl speed rsa1024" for instance. This way you could 
kind of measure the additional overhead.

Good work, Rickard!

Regards,

Roy Arends
Sr. Researcher
Nominet UK


From jakob at kirei.se  Thu Dec 11 20:07:23 2008
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 11 Dec 2008 21:07:23 +0100
Subject: [Opendnssec-develop] SoftHSM - Signing speed
In-Reply-To: <OFD399614D.D1776874-ON8025751C.005E858B-C125751C.005EE282@nominet.org.uk>
References: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se>
	<OFD399614D.D1776874-ON8025751C.005E858B-C125751C.005EE282@nominet.org.uk>
Message-ID: <C53C219D-0792-4280-9BD0-24FE94852263@kirei.se>

On 11 dec 2008, at 18.16, Roy Arends wrote:

> I assume that SoftHSM is using OpenSSL, right? Could you issue the  
> OpenSSL
> speed command? "$ openssl speed rsa1024" for instance. This way you  
> could
> kind of measure the additional overhead.

SoftHSM is build with Botan (http://botan.randombit.net/) and  
completely free from openSSL.

	jakob



From jakob at kirei.se  Thu Dec 11 20:15:13 2008
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 11 Dec 2008 21:15:13 +0100
Subject: [Opendnssec-develop] SoftHSM - Signing speed
In-Reply-To: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se>
Message-ID: <8EDF6AF6-610D-4E82-AA19-A62719ABECD3@kirei.se>

On 11 dec 2008, at 17.22, Rickard Bondesson wrote:

> The SoftHSM can now produce 2200 sig/sec (RSA768) with the hsm-speed- 
> test:
>
> ./hsm-speed -t 9 -s 1 -p apaapa123 -i 20000 081211153928020162
>
> And RSA1024 gives 1700 sig/sec

is 9 threads the optimum? on what platform? kuriputo (the lab box) has  
4 cores.

	jakob



From roy at nominet.org.uk  Thu Dec 11 21:23:49 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Thu, 11 Dec 2008 22:23:49 +0100
Subject: [Opendnssec-develop] SoftHSM - Signing speed
In-Reply-To: <8EDF6AF6-610D-4E82-AA19-A62719ABECD3@kirei.se>
References: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se>
	<8EDF6AF6-610D-4E82-AA19-A62719ABECD3@kirei.se>
Message-ID: <OFC813D7B4.5C0D4225-ON8025751C.0073C73C-C125751C.00758991@nominet.org.uk>

Jakob Schlyter wrote on 12/11/2008 09:15:13 PM:

> On 11 dec 2008, at 17.22, Rickard Bondesson wrote:
> 
> > The SoftHSM can now produce 2200 sig/sec (RSA768) with the hsm-speed- 
> > test:
> >
> > ./hsm-speed -t 9 -s 1 -p apaapa123 -i 20000 081211153928020162
> >
> > And RSA1024 gives 1700 sig/sec
> 
> is 9 threads the optimum? on what platform? kuriputo (the lab box) has 
> 4 cores.

Jakob, Rickard,

A straightforward way of squeezing the last bit of juice out of hsm-speed 
is to do several runs, as follows:

Increase iterations (-i) until it does not improve performance.
Then increase threads (-t) until it does not improve performance.
Lastly increase forks (-f) until it does not improve performance.

increasing iterations adds the least overhead. Threading adds a bit more 
overhead, while forking adds the most overhead, per cryptographic 
operation. (because iterations are per thread, threads are per forked 
process).

It is a poor man's solution but it worked well with the SCA6000s

Hope this helps,

Regards,

Roy Arends
Sr. Researcher
Nominet UK 


From roy at nominet.org.uk  Thu Dec 11 21:24:31 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Thu, 11 Dec 2008 22:24:31 +0100
Subject: [Opendnssec-develop] SoftHSM - Signing speed
In-Reply-To: <C53C219D-0792-4280-9BD0-24FE94852263@kirei.se>
References: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se>
	<OFD399614D.D1776874-ON8025751C.005E858B-C125751C.005EE282@nominet.org.uk>
	<C53C219D-0792-4280-9BD0-24FE94852263@kirei.se>
Message-ID: <OFA815DC01.EDF6DF57-ON8025751C.00758E97-C125751C.00759A17@nominet.org.uk>

Jakob Schlyter <jakob at kirei.se> wrote on 12/11/2008 09:07:23 PM:

> On 11 dec 2008, at 18.16, Roy Arends wrote:
> 
> > I assume that SoftHSM is using OpenSSL, right? Could you issue the 
> > OpenSSL
> > speed command? "$ openssl speed rsa1024" for instance. This way you 
> > could
> > kind of measure the additional overhead.
> 
> SoftHSM is build with Botan (http://botan.randombit.net/) and 
> completely free from openSSL.

I stand corrected! Thanks guys.

Regards,

Roy Arends
Sr. Researcher
Nominet UK


From Rickard.Bondesson at iis.se  Fri Dec 12 10:46:13 2008
From: Rickard.Bondesson at iis.se (Rickard Bondesson)
Date: Fri, 12 Dec 2008 11:46:13 +0100
Subject: SV: [Opendnssec-develop] SoftHSM - Signing speed
In-Reply-To: <OFA815DC01.EDF6DF57-ON8025751C.00758E97-C125751C.00759A17@nominet.org.uk>
References: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se>
	<OFD399614D.D1776874-ON8025751C.005E858B-C125751C.005EE282@nominet.org.uk>
	<C53C219D-0792-4280-9BD0-24FE94852263@kirei.se>
	<OFA815DC01.EDF6DF57-ON8025751C.00758E97-C125751C.00759A17@nominet.org.uk>
Message-ID: <69830D4127201D4EBD146B9041199718646282@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

It is on a 4 core 64 bit Sun OS machine.

With SoftHSM:

RSA1024 key:
./hsm-speed -s 1 -p apaapa123 -f 3 -t 4 -i 100000 081212083059184661
2052.76 sig/s

RSA2048 key:
./hsm-speed -s 1 -p apaapa123 -f 3 -t 4 -i 20000 081212093603519314
386.54 sig/s

With 64-bit OpenSSL:

openssl speed rsa1024 -multi 4: 8239.2 sig/s
openssl speed rsa2048 -multi 4: 1368.9 sig/s

With 32-bit OpenSSL:

openssl speed rsa1024 -multi 4: 1301.8 sig/s
openssl speed rsa2048 -multi 4: 238.1 sig/s

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSUJA9eCjgaNTdVjaAQhB6gf/eXfSikiHMLTH6YurJyl4Q/h/GzzlYY5d
m/eQS24qf+dvx+58ZY1a97hQKyWsEkFQTfBsFtJVdMUd1+F9eBzms6aZJ4NLpBHY
4+7vfr8h9iK+X8nRz33I1cqPsRvf+Yv/DF3BI7lDTCGTpfbbSt+waujPPDbthJcY
rUSbza0O0DGUIqgmPKtCchHq55VCaoptOF2NVjvi2cDkCqRDYqZa6njAELLo3jG7
eeZJ+dumoE6LXLYJIzI0oOCS95kIKjDBauxxog/QGdJmEkIl4btt9FEKrQKC+jR3
qndAmMncDTKMPWjv+m5yXbOEhM1UgBBl8hZ9TpKnxzafW3FdrSaEzw==
=7VhW
-----END PGP SIGNATURE-----


From roy at nominet.org.uk  Fri Dec 12 12:21:58 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Fri, 12 Dec 2008 13:21:58 +0100
Subject: SV: [Opendnssec-develop] SoftHSM - Signing speed
In-Reply-To: <69830D4127201D4EBD146B9041199718646282@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se>
	<OFD399614D.D1776874-ON8025751C.005E858B-C125751C.005EE282@nominet.org.uk>
	<C53C219D-0792-4280-9BD0-24FE94852263@kirei.se>
	<OFA815DC01.EDF6DF57-ON8025751C.00758E97-C125751C.00759A17@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718646282@EXCHANGE.office.nic.se>
Message-ID: <OF9FCA4C00.996BA91B-ON8025751D.00436BE8-C125751D.0043EE2B@nominet.org.uk>

"Rickard Bondesson" <Rickard.Bondesson at iis.se> wrote on 12/12/2008 
11:46:13 AM:

> It is on a 4 core 64 bit Sun OS machine.
> 
> With SoftHSM:
> 
> RSA1024 key:
> ./hsm-speed -s 1 -p apaapa123 -f 3 -t 4 -i 100000 081212083059184661
> 2052.76 sig/s
> 
> RSA2048 key:
> ./hsm-speed -s 1 -p apaapa123 -f 3 -t 4 -i 20000 081212093603519314
> 386.54 sig/s
> 
> With 64-bit OpenSSL:
> 
> openssl speed rsa1024 -multi 4: 8239.2 sig/s
> openssl speed rsa2048 -multi 4: 1368.9 sig/s
> 
> With 32-bit OpenSSL:
> 
> openssl speed rsa1024 -multi 4: 1301.8 sig/s
> openssl speed rsa2048 -multi 4: 238.1 sig/s

Rickard, the -multi 4 does not really relate to 4 cpu's (though the 
documentation tells you differently). It basically spawns four processes 
of the openssl speed application (like the '-f' in hsm-speed). You might 
want to play with that value. Also, you need to use '-elapsed' as well, to 
get a better estimate.

Thanks,

Regards,

Roy Arends
Sr. Researcher
Nominet UK


From Rickard.Bondesson at iis.se  Fri Dec 12 12:37:17 2008
From: Rickard.Bondesson at iis.se (Rickard Bondesson)
Date: Fri, 12 Dec 2008 13:37:17 +0100
Subject: [Opendnssec-develop] SoftHSM - Signing speed
In-Reply-To: <OF9FCA4C00.996BA91B-ON8025751D.00436BE8-C125751D.0043EE2B@nominet.org.uk>
References: <69830D4127201D4EBD146B904119971864624F@EXCHANGE.office.nic.se>
	<OFD399614D.D1776874-ON8025751C.005E858B-C125751C.005EE282@nominet.org.uk>
	<C53C219D-0792-4280-9BD0-24FE94852263@kirei.se>
	<OFA815DC01.EDF6DF57-ON8025751C.00758E97-C125751C.00759A17@nominet.org.uk>
	<69830D4127201D4EBD146B9041199718646282@EXCHANGE.office.nic.se>
	<OF9FCA4C00.996BA91B-ON8025751D.00436BE8-C125751D.0043EE2B@nominet.org.uk>
Message-ID: <69830D4127201D4EBD146B9041199718646294@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


> Rickard, the -multi 4 does not really relate to 4 cpu's 
> (though the documentation tells you differently). It 
> basically spawns four processes of the openssl speed 
> application (like the '-f' in hsm-speed). You might want to 
> play with that value. Also, you need to use '-elapsed' as 
> well, to get a better estimate.
> 

Higher number than -multi 4 did not give any significant improvement and no difference with or without -elapsed. 

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSUJa/eCjgaNTdVjaAQh0cggAjYRsgkbfqeKgGxTaWt8E9kL1ZQdF6ytf
GaHRZBQlR4LvPEwG+sTIC/sOTidLDor+U9JSP0LsG1SBCmy2iwrbJke2t7jYmR74
h05C5INlC3h4yUc8eP5dGtdllWYzopl8EF8/ybdG3NOXksk/JFS7qgQDT5Qqxdod
e2JYb4f47NiDdaP9u6A/aTbLgrdymyikxADpDxda+Yc9fRwaacUEnD1dIm+bGb1v
hbkSgQub8c88jr9xK8hEgKN1K1q49N3q6KWKfVbdbh8Ec9uTUbjytGKQA4DdWzZK
5f9FYCQxXk8c3PK+GmS+spDuY4GrgyiHxcyOjRvtAjbMSO//Uf7GhA==
=3lQQ
-----END PGP SIGNATURE-----


From roland.vanrijswijk at surfnet.nl  Sat Dec 13 15:58:24 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Sat, 13 Dec 2008 16:58:24 +0100
Subject: [Opendnssec-develop] SoftHSM back-end database
In-Reply-To: <69830D4127201D4EBD146B9041199718646039@EXCHANGE.office.nic.se>
References: <69830D4127201D4EBD146B9041199718646039@EXCHANGE.office.nic.se>
Message-ID: <4943DBA0.6000105@surfnet.nl>

Hi Rickard,

Sorry for taking so long to respond, I've had a very busy week and a half...

Rickard Bondesson wrote:
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> 
> Hi
> 
> I have designed a back-end database for the SoftHSM which will
> remember the keys and its attributes from time to time. The current
> implementation of SoftHSM store the keys directly on the disc and
> auto generate the attributes. But we had a discussion about having a
> possibility to specify the attributes. So, attached is my design of
> the database with tables and columns. It presents all the possible
> attributes, but some of them are chosen not to be stored in the
> database.
> 
> Any comments or questions?

- What database are you going to use?

- I assume that attributes like CKA_MODULUS, etc. will be derived from 
the X509_public_key field? The same goes for the private key

- The CKA_ID value should not be stored as a string; it is defined as a 
byte array, so storing at as a string in a database could cause trouble 
(unless you store it Base64 encoded)

- How are you going to encrypt the PKCS #8?

- Are you really going to limit the possible values of a field such as 
CKA_CLASS?

- I've never seen CKA_WRAP_WITH_TRUSTED being used. So you could make 
that one gray...

- I would propose that you add a general "other attributes" blob, in 
which you can store - for instance in DER encoding - any attributes for 
which you have not created any fields; in this way you don't limit the 
types of attributes that can be stored without having to create fields 
for all possible attributes.

Hope this helps.

Cheers,

Roland.

-- 
-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From roland.vanrijswijk at surfnet.nl  Sun Dec 14 16:34:03 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Sun, 14 Dec 2008 17:34:03 +0100
Subject: [Opendnssec-develop] PKCS #11 compliance tool
In-Reply-To: <87601193-81E0-46DC-82D7-EE4548F76428@NLnetLabs.nl>
References: <OFD7B3696C.4A0E4A01-ON8025750F.003EC220-C125750F.005A58C6@nominet.org.uk>
	<87601193-81E0-46DC-82D7-EE4548F76428@NLnetLabs.nl>
Message-ID: <4945357B.7050700@surfnet.nl>

Hi all,

As discussed previously on this list with Roy, I've started work on the 
skeleton for a PKCS #11 compliance tool that will test whether a PKCS 
#11 module supports the functionality required to integrate with OpenDNSSEC.

For this I would like to ask for your input. Can anyone contribute a 
lists of the following:

- Required/optional attribute types
- Required/optional functions
- Required/optional mechanisms

Another question I have is whether there is a shared subversion 
repository that I can use to manage my sources...

Cheers,

Roland.

-- 
-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From Rickard.Bondesson at iis.se  Mon Dec 15 08:39:13 2008
From: Rickard.Bondesson at iis.se (Rickard Bondesson)
Date: Mon, 15 Dec 2008 09:39:13 +0100
Subject: [Opendnssec-develop] SoftHSM back-end database
In-Reply-To: <4943DBA0.6000105@surfnet.nl>
References: <69830D4127201D4EBD146B9041199718646039@EXCHANGE.office.nic.se>
	<4943DBA0.6000105@surfnet.nl>
Message-ID: <69830D4127201D4EBD146B90411997186462FC@EXCHANGE.office.nic.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi

I changed the database design to be more general. One table for object Ids and corresponding hashed PIN. The other table is a general table for the attributes (object id, type, value (blob), length). I am using SQLite3.

The down side is that the attributes for the private keys are unencrypted, thus viewable for any one with access to the database.

// Rickard

> 
> - What database are you going to use?
> 
> - I assume that attributes like CKA_MODULUS, etc. will be 
> derived from the X509_public_key field? The same goes for the 
> private key
> 
> - The CKA_ID value should not be stored as a string; it is 
> defined as a byte array, so storing at as a string in a 
> database could cause trouble (unless you store it Base64 encoded)
> 
> - How are you going to encrypt the PKCS #8?
> 
> - Are you really going to limit the possible values of a 
> field such as CKA_CLASS?
> 
> - I've never seen CKA_WRAP_WITH_TRUSTED being used. So you 
> could make that one gray...
> 
> - I would propose that you add a general "other attributes" 
> blob, in which you can store - for instance in DER encoding - 
> any attributes for which you have not created any fields; in 
> this way you don't limit the types of attributes that can be 
> stored without having to create fields for all possible attributes.
> 
> Hope this helps.
> 
> Cheers,
> 
> Roland.
> 
> --
> -- Roland M. van Rijswijk
> -- SURFnet Middleware Services
> -- t: +31-30-2305388
> -- e: roland.vanrijswijk at surfnet.nl
> 
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSUYXseCjgaNTdVjaAQg/0Af/fA5WrvWs/kIV4ghz/fqw2vIgPx4r8QEW
SyoPekUY6JPKmkwXNu1bDctePFcYFZlmSOogFDwz1HCjgDw5RxF0M+gFLeiXF7qz
Cowf5vB5a69G1FzG8VkUZMM27QZDjfwHs2Rrl5ALjPSKcAY2ByOXwYX+iTNICuHB
E+LRLD6K2syE1xi4jvR5fjkkh48QHoMuz9WAzhMLQLw0xM3a8HvmmeiGY7ZH4v3I
g7Czq+zjhuv5adj2HAf2GcQokrH/DKlBwJ5TiTd9IO0otaqFxt6e/aywqm2Wb4OK
QR/f82cHTKlFA2zAZAUiukDfWsj/HhwuBorKcEk7AYZEZPRcFrfG8A==
=0New
-----END PGP SIGNATURE-----


From matthijs at NLnetLabs.nl  Thu Dec 18 13:22:16 2008
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Thu, 18 Dec 2008 14:22:16 +0100
Subject: [Opendnssec-develop] interaction between the Signer and KASP
Message-ID: <494A4E88.6090109@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

A debate has resulted in some questions and a proposal that affects the
interaction between the Signer and KASP module.

The OpenDNSSEC project designs the Signer as a client to the KASP
module. Whenever the Signer needs to sign stuff, it needs to contact the
KASP module in order to retrieve the security parameters. This might
lead to a lot of traffic between the two modules, since it is expected
that the Signer has to sign a lot. We would like to propose that KASP
signals the Signer in case of any changes had occurred. The KASP already
needs to apply the changes, so we expect that it is little work for the
KASP module to send out a signal after the change is complete. Can we
make that assumption and is there any comment on this proposal?

Furthermore, some questions came to our mind that we could not answer.
Maybe this list can help us out:)

1. From the opendnssec.org website, I assume that the Signer has to
determine the inception and expiration times on signatures. It can
determine this from the refresh interval. (Ok, not a real question:))

2. What's the difference between zone resigning interval and signature
refresh interval? Imho, they are the same, but described differently.

3. What is the priority of changing security parameters? For example, it
could be that the signature validity period has changed. Does this need
to be applied to all signatures directly, or are they applied to
upcoming generated signatures only?

4. What is meant with signature jitter and clockskew? Does this affect
the zone content? If so, in what way?



Regards,

Matthijs Mekking
NLnet Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJSk6IIXqNzxRs6egRAg+BAJwNMidF1GF48b+VLG+GeUvBhmTzrQCePmM8
eMWkLrXG8uODoOq77m761cM=
=tG27
-----END PGP SIGNATURE-----


From jad at jadickinson.co.uk  Thu Dec 18 14:32:17 2008
From: jad at jadickinson.co.uk (John Dickinson)
Date: Thu, 18 Dec 2008 14:32:17 +0000
Subject: [Opendnssec-develop] interaction between the Signer and KASP
In-Reply-To: <494A4E88.6090109@nlnetlabs.nl>
References: <494A4E88.6090109@nlnetlabs.nl>
Message-ID: <A27FBC7F-E0ED-4C76-A19F-6542274F466C@jadickinson.co.uk>


On 18 Dec 2008, at 13:22, Matthijs Mekking wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hi,
>
> A debate has resulted in some questions and a proposal that affects  
> the
> interaction between the Signer and KASP module

My understanding (and what I have started developing) is that the  
enforcer will run as a daemon. It will read KASP, create keys and call  
the signer when ever signing is needed. It will tell the signer:

what zone to sign
what adapter to use to get that zone
what adapter to use publish the signed results with
which keys to use
where the keys are
etc...


> The OpenDNSSEC project designs the Signer as a client to the KASP
> module. Whenever the Signer needs to sign stuff, it needs to contact  
> the
> KASP module in order to retrieve the security parameters. This might
> lead to a lot of traffic between the two modules, since it is expected
> that the Signer has to sign a lot. We would like to propose that KASP
> signals the Signer in case of any changes had occurred. The KASP  
> already
> needs to apply the changes, so we expect that it is little work for  
> the
> KASP module to send out a signal after the change is complete. Can we
> make that assumption and is there any comment on this proposal?
>
> Furthermore, some questions came to our mind that we could not answer.
> Maybe this list can help us out:)
>
> 1. From the opendnssec.org website, I assume that the Signer has to
> determine the inception and expiration times on signatures. It can
> determine this from the refresh interval. (Ok, not a real question:))

It will be told all the information it needs to know by the enforcer.

I thought that in the first instance, the enforcer and signer would be  
separate things but that in a later iteration they would be brought  
together into one modular system.

If this is not what we are developing then I need to know :) Shall we  
have a quick phone call about it? I am available tomorrow all day.

John


From jelte at NLnetLabs.nl  Thu Dec 18 14:50:17 2008
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Thu, 18 Dec 2008 15:50:17 +0100
Subject: [Opendnssec-develop] interaction between the Signer and KASP
In-Reply-To: <A27FBC7F-E0ED-4C76-A19F-6542274F466C@jadickinson.co.uk>
References: <494A4E88.6090109@nlnetlabs.nl>
	<A27FBC7F-E0ED-4C76-A19F-6542274F466C@jadickinson.co.uk>
Message-ID: <494A6329.4060101@NLnetLabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Dickinson wrote:
> 
> On 18 Dec 2008, at 13:22, Matthijs Mekking wrote:
>>
>> A debate has resulted in some questions and a proposal that affects the
>> interaction between the Signer and KASP module
> 
> My understanding (and what I have started developing) is that the
> enforcer will run as a daemon. It will read KASP, create keys and call
> the signer when ever signing is needed. It will tell the signer:
> 

and this is why we need to write this stuff down before we start to
actually do anything.

We were told that the KASP only responded when the signing engine asked
it to (which is of course not practical at all, hence Matthijs' message).

And if it responded it responded with "for zone X use keys Y1 Y2 Y3 with
parameters Z etc".

Since that signer engine is the one handling incoming zone changes it
must always have the current key list available, to name one thing.

> what zone to sign
> what adapter to use to get that zone
> what adapter to use publish the signed results with

this is told by the kasp?

> which keys to use
> where the keys are
> etc...
> 

ok those are a given.

> 
>> 1. From the opendnssec.org website, I assume that the Signer has to
>> determine the inception and expiration times on signatures. It can
>> determine this from the refresh interval. (Ok, not a real question:))
> 
> It will be told all the information it needs to know by the enforcer.
> 

we are trying to figure out exactly what that is :)

> I thought that in the first instance, the enforcer and signer would be
> separate things but that in a later iteration they would be brought
> together into one modular system.
> 

Actually, i am now thinking that we have completely different views on
what the different parts do (and where what intelligence lies).

> If this is not what we are developing then I need to know :) Shall we
> have a quick phone call about it? I am available tomorrow all day.
> 

i think i'm officially done for the year after today, but i could set up
a conference call room if the rest wants to too, apparently we already
have a communication problem :)

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklKYygACgkQ4nZCKsdOncWpQwCg0LHouqD9qreXnrnXtYOBfHjG
zdsAoIMuHO/ZGJpkIMr50XdPd9JQRA3q
=8pGN
-----END PGP SIGNATURE-----


From jad at jadickinson.co.uk  Thu Dec 18 15:14:59 2008
From: jad at jadickinson.co.uk (John Dickinson)
Date: Thu, 18 Dec 2008 15:14:59 +0000
Subject: [Opendnssec-develop] interaction between the Signer and KASP
In-Reply-To: <494A6329.4060101@NLnetLabs.nl>
References: <494A4E88.6090109@nlnetlabs.nl>
	<A27FBC7F-E0ED-4C76-A19F-6542274F466C@jadickinson.co.uk>
	<494A6329.4060101@NLnetLabs.nl>
Message-ID: <BBAD0E3E-4D2A-4F6A-AD88-05B9B4012E18@jadickinson.co.uk>


On 18 Dec 2008, at 14:50, Jelte Jansen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John Dickinson wrote:
>>
>> On 18 Dec 2008, at 13:22, Matthijs Mekking wrote:
>>>
>>> A debate has resulted in some questions and a proposal that  
>>> affects the
>>> interaction between the Signer and KASP module
>>
>> My understanding (and what I have started developing) is that the
>> enforcer will run as a daemon. It will read KASP, create keys and  
>> call
>> the signer when ever signing is needed. It will tell the signer:
>>
>
> and this is why we need to write this stuff down before we start to
> actually do anything.

Yes :)

>
>
> We were told that the KASP only responded when the signing engine  
> asked
> it to (which is of course not practical at all, hence Matthijs'  
> message).
>
> And if it responded it responded with "for zone X use keys Y1 Y2 Y3  
> with
> parameters Z etc".
>
> Since that signer engine is the one handling incoming zone changes it
> must always have the current key list available, to name one thing.
>
>> what zone to sign
>> what adapter to use to get that zone
>> what adapter to use publish the signed results with
>
> this is told by the kasp?

I thought it was part of the policy. But now that I look that isn't  
written down anywhere other than in passing in the DB schema I sent  
round the other week.


>>
>>> 1. From the opendnssec.org website, I assume that the Signer has to
>>> determine the inception and expiration times on signatures. It can
>>> determine this from the refresh interval. (Ok, not a real  
>>> question:))
>>
>> It will be told all the information it needs to know by the enforcer.
>>
>
> we are trying to figure out exactly what that is :)
>
>> I thought that in the first instance, the enforcer and signer would  
>> be
>> separate things but that in a later iteration they would be brought
>> together into one modular system.
>>
>
> Actually, i am now thinking that we have completely different views on
> what the different parts do (and where what intelligence lies).
>
>> If this is not what we are developing then I need to know :) Shall we
>> have a quick phone call about it? I am available tomorrow all day.
>>
>
> i think i'm officially done for the year after today, but i could  
> set up
> a conference call room if the rest wants to too, apparently we already
> have a communication problem :)

Yes - I am happy to have the call in the new year if that if easier  
for everyone. I wasn't planning to do much more this year except send  
santa a list of gadgets that I need :)

Over the holiday, I will write up a short document describing what I  
think the different parts are, what they do and how they link  
together. I will send that round and maybe we can use it as the basis  
for some discussion in the new year.

John


From jelte at NLnetLabs.nl  Thu Dec 18 15:24:09 2008
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Thu, 18 Dec 2008 16:24:09 +0100
Subject: [Opendnssec-develop] interaction between the Signer and KASP
In-Reply-To: <BBAD0E3E-4D2A-4F6A-AD88-05B9B4012E18@jadickinson.co.uk>
References: <494A4E88.6090109@nlnetlabs.nl>	<A27FBC7F-E0ED-4C76-A19F-6542274F466C@jadickinson.co.uk>	<494A6329.4060101@NLnetLabs.nl>
	<BBAD0E3E-4D2A-4F6A-AD88-05B9B4012E18@jadickinson.co.uk>
Message-ID: <494A6B19.3080005@NLnetLabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Dickinson wrote:
>>
>> and this is why we need to write this stuff down before we start to
>> actually do anything.
> 
> Yes :)
> 

To be fair, something has in fact been written down, at

http://www.opendnssec.org/wiki/Signer/Architecture

and the pages linked from there, but we have some open questions left
before we can even have a first draft of our design doc

>> this is told by the kasp?
> 
> I thought it was part of the policy. But now that I look that isn't
> written down anywhere other than in passing in the DB schema I sent
> round the other week.
> 

it seemed to me that they both need, in their 'own' databases (could be
a shared one!) what zones there are...

otherwise even what little documentation we have is contradicting itself.

> Yes - I am happy to have the call in the new year if that if easier for
> everyone. I wasn't planning to do much more this year except send santa
> a list of gadgets that I need :)
> 
> Over the holiday, I will write up a short document describing what I
> think the different parts are, what they do and how they link together.
> I will send that round and maybe we can use it as the basis for some
> discussion in the new year.
> 

I'll be back up and running on the fifth, i'd say give me one or two
days to get going and hold a conference call on wednesday or thursday?

(btw i think roy wanted to plan a face2face meeting somewhere later in
january, which i already thought was a good idea, and now i think it is
an absolute necessity)

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklKaxkACgkQ4nZCKsdOncU61wCgnBslSFckBwFvRW74bqdV+Ats
qnQAoK9QgDJemz6d0e1tXtqk1906WIBv
=JoTS
-----END PGP SIGNATURE-----