Subject: Effect of adding an attribute to CSR

From: Puneet kumar <[email-masked]>
Date: Thu, 14 Oct 2004 04:26:40 -0700 (PDT)

Dear all,
      I need some assistance on a peculiar problem we are facing. 
 
      We are an organisation which acts as the TTP for all CA's operating in our country ,ie, we are the Root CA. So whenverea new CA comes up they send us a CSR (in PKCS#10) which we sign and give back a X.509 base 64 Certificate.
 
We recently received a CSR from a new CA.We added the attribute "cn" to the dn of the CSR (as this is a requirement at our end) and then issued the cert.Now the CA's software is not accpeting the cert and they say that its because we added the cn attribute.We are using a softwrae by Smarttrust (CM)and the CA has an Entrust s/w.
 
Now I have the following queries
 
1.Does adding an attribute to the CSR make any difference towards the acceptability of the cert?
 
2.What options do we have at our end..I mean do we need to revoke the cert? Can we re-certify the cert? Actually I did'nt find the term re-certify in any standardd..certs are either revoked or get expired.Your Comments would be most welcome.
 
3.Is their any setting changes that can be done in the Entrust CA softwrae to allow this cert with the changed distinguished name to be accepted?
 
Request feedback from you guys..
 
Thanks
2.

---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 15 Oct 2004 01:19:12 +1300

Puneet kumar <[email-masked]> writes:

>We recently received a CSR from a new CA.We added the attribute "cn" to the
>dn of the CSR (as this is a requirement at our end) and then issued the
>cert.Now the CA's software is not accpeting the cert and they say that its
>because we added the cn attribute.We are using a softwrae by Smarttrust (CM)
>and the CA has an Entrust s/w.
>

You mean the CA adding an attribute to the cert that isn't in the PKCS #10?
No, not at all, in fact it's quite standard.

>2.What options do we have at our end..I mean do we need to revoke the cert?
>Can we re-certify the cert? 

If you're the CA, it's really up to you.  If it's been explicitly rejected by
the client, I'd revoke it.

>3.Is their any setting changes that can be done in the Entrust CA softwrae to
>allow this cert with the changed distinguished name to be accepted?

You'd have to ask Entrust that.

Peter.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 14 Oct 2004 15:04:28 +0200

Puneet kumar wrote:

> We recently received a CSR from a new CA.We added the attribute "cn" 
> to the dn of the CSR (as this is a requirement at our end) and then 
> issued the cert. [...]
>  

I don't believe any of the IETF standards tries to cover this point, and 
to say explicitly what is the right thing to do in such a situation.
It can be considered a local decision.
This said the CMC RFC 2797 does describe a case where the request 
subject DN is null, and where the CA will generate the correct DN.

Generally talking the format for CSR request enables to requester to 
include many elements, and the CA will have security reasons to filter 
them and keep only what it considers valid.
CA definitively can not accept the elements in request directly, and 
have to either reject requests that don't conform or correct them.

They are many examples on the market of CA that will reformat the DN of 
request, or simply ignore it and use other source to generate the DN of 
the certificate.
They are good reasons for a CA to normalise the DN in input in order to 
avoid problems, some request generating softwares don't put the DN 
component in the normal order, or use invalid string type.
Also if the CA wants to conform fully to RFC3290, it should only emit 
certificate with UTF8String encoding since december 31, 2003.
That's another case where a CA may consider the best solution is to 
reencode in UTF8String format all request before emitting the cert.

> 2.What options do we have at our end..I mean do we need to revoke the 
> cert? Can we re-certify the cert? Actually I did'nt find the term 
> re-certify in any standardd..certs are either revoked or get 
> expired.Your Comments would be most welcome.

It seems to me the easiest solution is to revoke the cert, and ask the 
CA to submit you another request that conforms to your policy for CA's 
DN naming.
When they send you a request that includes a CN, you will not have to 
modify it before emitting the cert and everything will work correctly.

> 3.Is their any setting changes that can be done in the Entrust CA 
> softwrae to allow this cert with the changed distinguished name to be 
> accepted?

That is a question to ask to that specific vendor.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Oct 2004 15:10:47 -0400

At 4:26 AM -0700 10/14/04, Puneet kumar wrote:
>       We are an organisation which acts as the TTP for all CA's 
>operating in our country ,ie, we are the Root CA. So whenverea new 
>CA comes up they send us a CSR (in PKCS#10) which we sign and give 
>back a X.509 base 64 Certificate.
>
>issued the cert.Now the CA's software is not accpeting the cert and 
>they say that its because we added the cn attribute.We are using a 
>softwrae by Smarttrust (CM)and the CA has an Entrust s/w.
>
>2.What options do we have at our end..I mean do we need to revoke 
>the cert? Can we re-certify the cert? Actually I did'nt find the 
>term re-certify in any standardd..certs are either revoked or get 
>softwrae to allow this cert with the changed distinguished name to 
>be accepted?
>

The PKIX standards for cert request/response do not address this 
issue, in the general case.  However, a client (a CA in this case) 
might well compare the returned cert to the one submitted and reject 
the response because of the mismatch.  In your case the "right" 
solution is to have the client resubmit the request with the subject 
name in the form you procedurally require.

Steve