Getting a KeyPOST Digital Certificate - Part 1 - Applying

[David Chia]

> 
> The PKAF Task Force and Gatekeeper were both concerned with this - NEVER
> from a 'key escrow' point of view but from it being a 'weak link'
> 
> >>I think you'll find that PKAF right now assumes key generation by the
> >>allocator is vital to ensure standards are met. Not for escrow,
> >>although that is also part of the equation.
> 
> In our PKAF report we said that "A user's public/private key pair may be
> generated by the user or by an entity for the user, provided the key pair
> is generated using a consistent and trusted method. (it continues on
> further - refer 3.3.1)  We were trying to steer people to sufficiently
> 'strong' generation mechanisms.
> 
> Gatekeeper acknowledged self generated keys for non-government users.
> (except for the CAs themselves who require keys from an accredited entity
> in the GPKA).  I think I recall that also mentioned is a requirement, with
> self generated keys, the CAs should have a mechanism, using the presented
> public key,  that would verify that user was the legitimate holder of the
> private key.
> 

I wish the Gatekeeper report had explicitly stated how the DSA key-pair
should be generated, i.e. 'entirely' by the CAs OR 'entirely' by the
cert requester. DSA has a potentially bad third alternative which is
a combination of both, i.e. the PQG parameters supplied by the
CAs is used by the cert requester to generate the key-pair.

I know the Gatekeeper report explicitly disallowed browser generated cert,
but as an example a popular browser uses the third method for DSA cert
generation. There is a report that another larger software vendor is also
interested in using the third method.

> 
> >>And of course, nothing stops you using the auspost key to exchange >>some
> other token you really want to use for crypto, or using it for >>identity
> alone, and doing diffie-helman or elliptic curve to select >>specific keys
> for the crypto.
> 
> Gatekeeper recommends 2 key pairs.  One set for signature only, to "provide
> added protection to the integrity of a user's authentication digital
> signature.  There are no lawful curcumstances where users should be
> required to surrender their signature key pair."  The other would be used
> for key exchange.
> 

Rather than specifying on a fixed number of key pairs, another on my wish
list is that two distinct 'technical' functions be specified, i.e.
authentication and encryption. Current thinking, as reflected in some
ISO and IETF standards is that there should be at least two distinct
'legal' authentication functions, i.e. identification and legal
non-repudiation. That is, 3 key-pairs. With the security state of
current desktop operating system I tend to agree that the awardance
of legal non-repudiation status should be properly managed. With
experience there could be other 'legal' requirements when the
technology is better understood.


David Chia, RMIT University