Subject: [pkix] CMC question

From: [email-masked]
Date: Thu, 10 Sep 2009 12:25:44 -0700 (PDT)

On page 25 of RFC 5272 it recommends the following for an enveloped PKI req/rsp:

  Normal              Option 1                  Option 2
   ------              --------                  --------
   SignedData          EnvelopedData             SignedData
    PKIData             SignedData                EnvelopedData
                         PKIData                   SignedData
                                                    PKIData

Suppose a PKI Request is encoded as in option 2. What should the RA do if SignedData passes muster, but the RA does not support the ContentEncryptionAlgorithmIdentifier in the EnvelopedData?

One option is to silently discard the request, but this provides no feedback to the submitter.

Another option is to return a PKI response containing the original request, with CMCFailInfo set to badAlg, but one might argue that since the enveloped data was not decrypted, it is not clear that it really is a PKI Request -- so a PKI Response may be inappropriate.

Since the request was protected by SignedData, and the RA has certain expectations of anyone capable of producing a valid SignedData (e.g., that they are authorized to enroll, even if they *are* using the wrong encryption algorithm for the envelope), it seems reasonable to send the PKI response and assume that they can interpret it.

This seems like a judgement call that has limited security implications. Does anyone think otherwise?

Thanks,

Scott

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 11 Sep 2009 15:53:50 +0200

[email-masked] wrote:
> What should the RA do if SignedData passes muster, but the RA does
> not  support the ContentEncryptionAlgorithmIdentifier in the EnvelopedData?

What do you mean by SignedData "passes muster" ?

As you say below, it can not be decrypted.
So the only available info about it is the value of ContentType inside 
EncryptedContentInfo. Which is not authentified.

> This seems like a judgement call that has limited security
> implications. Does anyone think otherwise?

If you sign your answer to such messages that anyone can forge, it will 
be a little easier for an attaquer to overload your service.

But if you drop them, such a case will be significantly harder to debug.

I think there's not much more to say.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 11 Sep 2009 07:50:28 -0700

Hi Jean-Marc,

Thanks for taking the time to answer. Clarifications inline below...

Jean-Marc Desperrier wrote:
> As you say below, it can not be decrypted. So the only available info
> about it is the value of ContentType inside EncryptedContentInfo.
> Which is not authentified.

I think you misunderstood. From the original message,

 > On page 25 of RFC 5272 it recommends the following for an enveloped > 
 > PKI req/rsp:
 >
 >   Normal              Option 1                  Option 2
 >    ------              --------                  --------
 > Suppose a PKI Request is encoded as in option 2.

Since it is option 2, the outer SignedData has been verified prior to 
detecting that the ContentEncryptionAlgorithmIdentifier us not supported.

Since the SignedData is verified, chances of a DoS attack based on this 
are small and manageable.

--Scott

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 11 Sep 2009 14:21:56 -0700

My opinion is that if the algorithm is not supported, then badMessageCheck
should be returned (as per section 3.2.1.3.3)

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, September 10, 2009 12:26 PM
> To: [email-masked]
> Subject: [pkix] CMC question
> 
> Suppose a PKI Request is encoded as in option 2. What should the RA do
> if SignedData passes muster, but the RA does not support the
> ContentEncryptionAlgorithmIdentifier in the EnvelopedData?
> 
> Another option is to return a PKI response containing the original
> request, with CMCFailInfo set to badAlg, but one might argue that since
> the enveloped data was not decrypted, it is not clear that it really is
> a PKI Request -- so a PKI Response may be inappropriate.
> 
> Since the request was protected by SignedData, and the RA has certain
> expectations of anyone capable of producing a valid SignedData (e.g.,
> that they are authorized to enroll, even if they *are* using the wrong
> encryption algorithm for the envelope), it seems reasonable to send the
> PKI response and assume that they can interpret it.
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 12 Sep 2009 22:30:51 +1200

"Scott G. Kelly" <[email-masked]> writes:

> Since the SignedData is verified, chances of a DoS attack based on this are
> small and manageable.

Why would the presence of a valid signature indicate that the sender had your
best interests at heart?

(This is a serious question, I'm just curious about the reasoning.  One in ten
digitally signed binaries on Windows PCs are malware, a signature doesn't tell
you anything about the intentions of the sender).

Peter.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Sat, 12 Sep 2009 07:32:00 -0700

Hi Peter,

> you anything about the intentions of the sender).

Good point. The current primary use cases for this enrollment protocol 
are in relatively closed environments, and that's what I had in mind 
when I said "small and manageable". But you are right.

--Scott