Kind regards,
Arkadius
max pritikin <pritikin@xxxxxxxxx>
12.10.2009 20:50
An
max pritikin <pritikin@xxxxxxxxx>
Kopie
Arkadius Litwinczuk <arkadius.litwinczuk@xxxxxx>
Thema
Re: Antwort: Re: one more SCEP draft 19, getNextCA question
Arkadius,
fyi-
With the clarity of a monday morning I've gone back and looked at our
reference implementation and reviewed the document in this area. I
think the original text may have been more confusing but more
accurate.
In particular it is difficult to respond with a CertRep since a
CertRep MUST include the following attributes:
• the transactionID attribute copied from the
request we are
responding to
• a messageType attribute set to CertRep
• a senderNonce attribute
• a recipientNonce attribute copied from the
senderNonce from the
request we are responding to.
• a pkiStatus set to the status of the reply.
But a CerReq was not used to initiate this response and thus the
transactionID, and senderNonce are unknown.
- max
On Oct 9, 2009, at 11:34 AM, max pritikin wrote:
>
> On Oct 8, 2009, at 7:11 AM, Arkadius Litwinczuk wrote:
>
>>
>> Hi Max,
>>
>> alright I try to clarify my question. In 5.2.1.1.1and 5.2.1.1.2 the
>> getCA responses are not in anyway secured, and are also not
>> encapsulated in a SCEP pkiMessage, that requires transaction id and
>> messageType and so on.
>
> Agreed.
>
>> The return message for getNextCA on the other hand has to be
signed,
>
> Agreed.
>
>> else you could simply accept any certificate as a trusted
>> certificate so this can't be right. The whole idea is to have a
>> secure manner to get the nextCA certificate to a client, and not
>> being required to install it manually. At least that is what I'm
>> hopping for. So the response message is in fact different from a
>> getCA response or it should be, it has a pkcs#7 envelope with all
>> required SCEP fields doesn't it ?
>
> The response is defined in 4.6.1:
>
>> The response consists of a SignedData PKCS#7 [RFC2315], signed by
>> the current CA (or RA) signing key.
>>
>> Clients MUST validate the signature on the the SignedData PKCS#7
>> [RFC2315] before accepting any of its contents.
>>
>> The content of the SignedData PKCS#7 [RFC2315] is a degenerate
>> certificates-only Signed-data message containing the new CA
>> certificate and any new RA certificates, as defined in Section
>> 5.2.1.1.2, to be used when the current CA certificate expires.
>>
>
> I neglected to point out this layering in my initial response below.
>
>> in 3.1.1.2 :
>> The messageType attribute specifies the type of operation
>> performed by the transaction. This attribute MUST be included in
>> all PKI messages.
>>
>> So in my opinion there should be a messageType defined for
>> getNextCA to stay correct, it is a full signed SCEP pkiMessage
>> envelope for signed data, in fact the most important data at all.
>
> It looks like the text of 4.6.1 should directly reference 3.2.2
> (CertRep) instead of referencing 5.2.1.1.2. The resulting first
> three paragraphs would look like:
> "The response consists of a SignedData PKCS#7 [RFC2315], signed by
> the current CA (or RA) signing key.
>
> Clients MUST validate the signature on the the SignedData PKCS#7
> [RFC2315] before accepting any of its contents.
>
> The content of the SignedData PKCS#7 [RFC2315] is a CertRep as
> defined in Section 3.2.2, containing the new CA certificate and
> optional RA certificates to be used when the current CA certificate
> expires."
>
> I think this is clearer. Does it make sense to you as well?
>
>> But also I would like to explain a problem or better vulnerability
>> at this point.
>> In a normal setup you would have the root certificate securely
>> distributed (mostly during the setup), the RA certificate this
>> would be the SCEP server certificate, would be send as signer
>> certificate in the message. The client can verify this certificate
>> against the root since it issued it and verifies it's trusted. So
>> far so good, but other certificates signed by the same CA are also
>> valid. If the attacker has a valid certificate issued by the same
>> CA he could spoof the connection, and inject a rogue CA.
>> If the setup has a 1st level root CA and lets say 2nd level Server
>> CA and user CA, the problem is the same, the RA certificate would
>> be most likely issued by the server CA .
>> The only way how to really secure this would be to sign the new
>> root CA with the old root CA. Or in this case sign the SCEM message
>> with the old root CA. This and a little more complex is also
>> described in the CMP protocol.
>> The problem is now that a root CA should not be used for digital
>> signature. Regardless this is only a policy problem and would be
>> great if it could be optionally required to sign this nextCA
>> message by the old CA. To really have a secure distribution for the
>> next root CA.
>
> I agree and recommend only using RA mode for all SCEP servers. Thus
> the RA cert is used instead of the CA cert. See Section 8.2.
>
> - max
>
>>
>> Let me know your thoughts on this.
>>
>> Kind regards,
>>
>> Arkadius
>>
>>
>>
>>
>>
>>
>>
>> max pritikin <pritikin@xxxxxxxxx>
>> Gesendet von: owner-scep@xxxxxxxxxxxxx
>> 08.10.2009 02:42
>>
>> An
>> Arkadius Litwinczuk <arkadius.litwinczuk@xxxxxx>
>> Kopie
>> scep@xxxxxxxx
>> Thema
>> Re: one more SCEP draft 19, getNextCA question
>>
>>
>>
>>
>>
>>
>>
>> Arkadius,
>>
>> On Oct 7, 2009, at 6:29 AM, Arkadius Litwinczuk wrote:
>>
>> >
>> > Hi Max,
>> >
>> > I have an other question regarding the getNextCA operation. We
>> > cleared the MIME type but,
>>
>> The current draft text indicates "application/x-x509-next-ca-cert"
>> but
>> the figure erroneously indicated the wrong mime type. I've updated
>> this for the next draft.
>>
>> > the current version also does not specify the SCEP messageType
does
>> > it ? Is it CertRep so the corresponding decimal 3 ?
>>
>> Section 5.2.6.1 references the GetNextCACert response definition in
>> section 4.6.1. This in turn clarifies that the response format is
>> equivalent to the CA and RA certificates response which is
defined in
>> 5.2.1.1.2 which was introduced in 4.1.1.2. A confusing trail but
>> ultimately accurate (I think).
>>
>> There is no indication of the messageType attribute value being set
>> at
>> all; much like how there is none set for GetCACert.
>>
>>
>> > Also I assume that the response
>> > "Content-Type:application/x-x509-next-ca-certt\n\n"
>> > <BER-encoded SignedData<BER-encoded degenerate PKCS7>>
>> > is also a base64 and DER encoded right? Only to clarify sorry
if I
>> > missed something in the draft describing this.
>>
>> As with the GetCACert response (section 4.1.1.2) this would be a
>> binary response without the base64 encoding.
>>
>> Does this help answer your questions?
>>
>> - max
>>
>> >
>> > Kind regards,
>> >
>> > Arkadius
>> >
>> >
>> >
>> > --
>> >
>> > Informationen (einschließlich Pflichtangaben) zu einzelnen,
>> > innerhalb der EU tätigen Gesellschaften und Zweigniederlassungen
>> des
>> > Konzerns Deutsche Bank finden Sie unter http://www.db.com/de/content/pflichtangaben.htm
>> > . Diese E-Mail enthält vertrauliche und/ oder rechtlich
geschützte
>> > Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese
>> > E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort
den
>> > Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren
>> > sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
>> >
>> > Please refer to http://www.db.com/en/content/eu_disclosures.htm
for
>> > information (including mandatory corporate particulars) on
selected
>> > Deutsche Bank branches and group companies registered or
>> > incorporated in the European Union. This e-mail may contain
>> > confidential and/or privileged information. If you are not the
>> > intended recipient (or have received this e-mail in error) please
>> > notify the sender immediately and delete this e-mail. Any
>> > unauthorized copying, disclosure or distribution of the
material in
>> > this e-mail is strictly forbidden.
>>
>>
>>
>> --
>>
>> Informationen (einschließlich Pflichtangaben) zu einzelnen,
>> innerhalb der EU tätigen Gesellschaften und Zweigniederlassungen
>> des Konzerns Deutsche Bank finden Sie unter http://www.db.com/de/content/pflichtangaben.htm
>> . Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte
>> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
>> E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
>> Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren
>> sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
>>
>> Please refer to http://www.db.com/en/content/eu_disclosures.htm for
>> information (including mandatory corporate particulars) on selected
>> Deutsche Bank branches and group companies registered or
>> incorporated in the European Union. This e-mail may contain
>> confidential and/or privileged information. If you are not the
>> intended recipient (or have received this e-mail in error) please
>> notify the sender immediately and delete this e-mail. Any
>> unauthorized copying, disclosure or distribution of the material in
>> this e-mail is strictly forbidden.
>
--
Informationen (einschließlich Pflichtangaben) zu einzelnen,
innerhalb der EU tätigen Gesellschaften und Zweigniederlassungen des
Konzerns Deutsche Bank finden Sie unter http://www.db.com/de/content/pflichtangaben.htm
. Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren
sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
Please refer to http://www.db.com/en/content/eu_disclosures.htm for
information (including mandatory corporate particulars) on selected
Deutsche Bank branches and group companies registered or
incorporated in the European Union. This e-mail may contain
confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.