Subject: RE: Indicating How Private Keys are Generated/Stored (was RE: A R eal Rationale for Dedicated Keys)

From: [email-masked]
Date: Fri, 21 Jul 2000 13:03:19 -0400

Bob,

Yes the Novell Security Attributes keyQuality and cryptoProcessQuality from
Section 4 of your document seem to contain the basis of the information that
the subscriber (i.e. the key generation device in my case) could put in the
registration information in CRMF of a certificate request message. However,
a common standardised method would have to be supported by the IETF.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

P.S. Although the URL mentions the v1.0 for this Novell document, once
downloaded it is only version 0.998 of Aug 98.

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Friday, July 21, 2000 11:40 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Indicating How Private Keys are Generated/Stored (was RE: A
Real Rationale for Dedicated Keys)

Francois,

I completely agree.

All certificates issue by Novell, or created using Novell Certificate
Server, contain a X.509 extension called the Novell Security Attributes. An
important component of these attributes is the notion of a "certificate
quality indicator", and one of the factors of the certificate quality is an
indication of how the key was created (both the computer security and
cryptographic security of the creating process, e.g., the TCSEC, ITSEC, or
Common Criteria rating of the computing platform, together with the FIPS
140-1 rating). But in addition, it is necessary to have either a
representation from the subscriber as to how the key will be used in the
future (same parameters), and where and how the key will be stored in the
meantime.

Ideally, these representations should be enforced as constraints, with a bit
provide to indicate that fact.

For the details , including the ASN.1 encoding, see
http://developer.novell.com/repository/attributes/certattrs_v10.htm

Bob

>>><[email-masked]> 07/21/00 09:20AM >>>

Hi Simon,

I totally agree with you that if a key generation device had its own private
key that is trusted by a CA and this key was used to sign a certificate
request for a newly generated end user's key pair, this would certainly
provide more confidence for this CA to certify the end user's public key for
NR.

Currently neither the CMP protocol [RFC2510] nor the CMC protocol [RFC2797]
include a standard way for a key generation device to explicitly indicate in
a certificate request the quality of remotely generated key pair and also
how the private key will be stored and protected in the future. However,
both CMP and CMC use CRMF [RFC2511] and Section 3 on the certificate request
message indicates that the optional registration information field can
contain supplementary information related to the context of the
certification request when such information is required to fulfil a
certification request.

Wouldn't it make sense to define additional type(s) for the registration
information in CRMF for this particular purpose of indicating the quality of
remotely generated key pair and also how the private key will be stored and
protected in the future? Certificate request messages containing this new
registration information and the end user's public key would then be signed
with the private key of the key generation device, which would acting as an
RA in this case, and be forwarded to another RA or directly to the CA to be
certified. What do others think about this suggestion?

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked] Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com Fax. (613) 723-5078

-----Original Message-----
From: Simon McMahon [mailto:[email-masked] 
Sent: Friday, July 21, 2000 12:15 AM
To: Aram Perez; [email-masked] 
Subject: Re: A Real Rationale for Dedicated Keys

>
> Without the owner physically showing up, how can a CA know whether or not

> key pair was "generated and the private part is stored to some minimum
> standard"?
>
The key generation device has its own private key and signs the cert request
for the newly generated user key pair. The CA then knows that the key pair
originated in a device it (the CA) trusts and probably provides as part of
its service. The CA certifies the public key of the device so it can verify
the device's cert requests.

Such a device is obviously not cheap but without such a device the CA cannot
control the quality of remotely generated keys or how the private key is
stored and protected from duplication (necessary for NR).
Much more likely is that the owner *will* show up to the CA or one of its
RAs to get a NR certificate. Anything less will probably fail to meet the
legal requirements for NR and be worth no more than a NR=0 cert.

Simon McMahon
ERACOM Pty. Ltd.