[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CMC issue - CA identification
Jim,
What I would like, is to let the CMC client automatically identify the
self-signed certificate and thus eliminate the manual approval required for
the same purpose.
This operation is suggested to occur as part of the response, to replace the
manual action that sometimes can be done only afterwards, when the chain
with the self-signed certificate arrives in the response.
In the case of RA the same method is used. The RA takes the same buffer of
self-signed certificate as the value to be validated. We need here two
things:
1. Verify that the server, may it be the CA or RA, knows the shared secret.
This may be achieved by creating the HMAC-SHA1 of any agreed upon buffer.
2. Approve the self-signed certificate.
These needs are both achieved by the suggested way.
Avi
-----Original Message-----
From: Jim Schaad [mailto:jimsch@xxxxxxxxxx]
Sent: Thursday, September 13, 2001 3:24 AM
To: 'Avi Gozlan'; ietf-pkix@xxxxxxx
Subject: RE: CMC issue - CA identification
Avi,
Based on the discussion below, I am going to assume that the reason you
want to give the CA the ablitiy to prove it's identity is so that it can
successfully distribute a "Trust Anchor". Are you suggesting that this
occur before the client sends a certificate request to the CA or that it
be part of the response?
Also how do you think that the identify proof would need to be changed
so that an RA rather than a CA could prove it's identity?
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Avi Gozlan
> Sent: Tuesday, September 11, 2001 12:33 AM
> To: ietf-pkix@xxxxxxx
> Subject: CMC issue - CA identification
>
>
>
> Hello,
>
> CMC supplies the identityProof mechanism, by which a CA can
> immidiately and
> automatically identify a CMC client. However, there are no
> means by which
> the CA identifies itself to the CMC client. According to
> section 4.4 of RFC
> 2797, clients must explicitly approve trust of the included
> self-signed
> certificate.
>
> In the cases where the identityProof machanism is used the
> end entity and
> the CA share a secret. The secret can be used to authenticate
> the reply as
> well as the request.
>
> Following is a proposal that utilizes this mechanism in the reply.
>
> This way of authentication has some advantages:
> - Same strength of authentication on the client side as on the CA side
> - More secure - users are not always familiar with approving
> a CA or its
> fingerprint
> - Easier to use, no user intervention is required for CA
> identification
>
> Is it possible that such an automatic identification proof
> will be added to
> CMC (or descendant)?
>
> Here is the proposal:
>
> 1. The buffer of the self-signed certificate in the
> "certificate" portion of
> the signedData is the value to be validated
> 2. A SHA1 hash of the token is computed.
> 3. An HMAC-SHA1 value is then computed over the value
> produced in Step 1,
> using the hash of the token from Step 2 as the shared secret value
> 4. The 160-bit-HMAC-SHA1 result from Step 3 is then encoded
> as the value of
> the identityProof attribute.
>
> When the client verifies the identityProof attribute, it extracts the
> self-signed certificate from the chain included in the
> "certificate" portion
> of the signedData. It then computes the HMAC-SHA1 value in
> the same way and
> compares it to the identityProof attribute contained in the enrollment
> request.
>
> Thanks,
>
> Avi Gozlan
> PKI team
> Check Point Software Technologies LTD.
>