Subject: Re: [pkix] Query regarding SCEP GetCert message type !

From: max pritikin <[email-masked]>
Date: Mon, 3 May 2010 11:13:26 -0500

I agree that this is a typo in the v20 draft; likely introduced during  
other cleanup work. Thank you to the folks that pointed this out. It  
has been corrected in v21 (to be published soon).

- max

On Apr 29, 2010, at 11:12 AM, satish lvr wrote:

> Hi All,
>
> In the new draft released by SCEP (draft-nourse-scep-20),  i have  
> following queries :
>
> In the section 3.2.4 GetCert, it has been mentioned that messageType  
> attribute should be set to "PKCSReq".
>
> But there is a messageType available "GetCert" also. Why it is not  
> being used ?
>
> I have checked in draft-nourse-scep-18. In draft-nourse-scep-18, it  
> has been mentioned that messageType should be "GetCert".
>
> I am confused whether it should be "GetCert" or "PKCSReq".
>
> I request some clarifications or any information.
>
> Thank you very much !
>
> Regards
> Satish.
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: satish lvr <[email-masked]>
Date: Mon, 3 May 2010 22:03:02 +0530

Dear Pritikin,

Thanks for the input.

I also have one more query regarding "SCEP pkcsPKIEnvelope".

In section 3.1.2, it has been mentioned like below :

"The message is encrypted using the public key of the recipient of the
message, i.e. the RA or the CA public key (if sent from the
requester), or the requester public key (if sent as a reply to the
requester).".

Here, does message indicates shared key which we will use for encryption of
message ?

because in PKCS7 envelope, we will encrypt the message using shared key and
then encrypt the message

using public key of recipient.

Please correct me if I am missing any point here.

Thank you !

Regards
Satish.

On Mon, May 3, 2010 at 9:43 PM, max pritikin <[email-masked]> wrote:

> other cleanup work. Thank you to the folks that pointed this out. It has
> been corrected in v21 (to be published soon).
>
> - max
>
>
>> But there is a messageType available "GetCert" also. Why it is not being
>> used ?
>>
>> I have checked in draft-nourse-scep-18. In draft-nourse-scep-18, it has
>> been mentioned that messageType should be "GetCert".
>>

---

From: max pritikin <[email-masked]>
Date: Mon, 3 May 2010 13:44:00 -0500

Hi Satish,

Regarding the pkcsPKIEnvelope I have just responded to L Venkat's  
query about the same issue. This is my response to him:

I agree that the wording of this is sloppy shorthand. I've updated the  
text as follows:

"The PKCS#7 [RFC2315] content-encryption key (see Section 10, step 2)  
is encrypted using the public key of the recipient of the message,  
i.e. the RA or the CA public key (if sent from the requester), or the  
requester public key (if sent as a reply to the requester)."

I've also updated the reference to this section from 3.2.1 PKCSReq to  
read:

"The pkcsPKIEnvelope for this message type is protected using the  
public key of the recipient as detailed inSection 3.1.2. For example  
the CA or RA public key."

and from 3.2.2 CertRep to read:

"The pkcsPKIEnvelope for this message type is protected using the  
public key of the recipient as detailed inSection 3.1.2. For example  
if a self-signed certificate was used to send the original request  
then this self-signed certificate's public key is used to encrypt the  
content-encryption key of the SUCCESS response's pkcsPKIEnvelope"

Please let me know if this clarifies things. I very much appreciate  
these, or any other confusions in the text, being brought to our  
attention.

- max

On May 3, 2010, at 11:33 AM, satish lvr wrote:

> Here, does message indicates shared key which we will use for  
> encryption of message ?
>
> because in PKCS7 envelope, we will encrypt the message using shared  
> key and then encrypt the message
>
> I agree that this is a typo in the v20 draft; likely introduced  
> during other cleanup work. Thank you to the folks that pointed this  
> out. It has been corrected in v21 (to be published soon).
>
> - max
>
>