EldoS | Feel safer!

Software components for data protection, secure storage and transfer

CMS missing location information

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
#10742
Posted: 08/05/2009 03:34:49
by Dominik Foucauld (Standard support level)
Joined: 07/07/2009
Posts: 6

Hi there,

I am currently using SecureBlackBox 7.1 to work with signatures and certificate from other products/platforms. I have come across a problem. When I open a CMS Message using the TElSignedCMSMessage object and although the object is opened correctly, the signed information is missing in the signature objects, i.e. the property SignerLocation has an object but its values are empty.

I can see that the TElPKCS7Signer that the signature object (TElCMSSignature) internally has, does have the signing location among its authenticated attributes (1.2.840.113549.1.9.16.2.17) and sure enough if I open the message using the simpler TElPKCS7Message class I can access all information as expected.

The question then is twofold: If I continue using the CMS classes, could you expose the internal TElPKCS7Signer or the authenticated attributes in the TElCMSSignature class.

And then, if I were to use the TElPKCS7Message how do I obtain the signed digest to match against the data digest? I know that the digest could be found among the authenticated attributes, but how do I deal with it when it is not found there? I have tried working the the EncryptedDigest property of the ElPKCS7Signer class but have had no success in decrypting it. I presume I need to use the Verify method from the ElPublicKeyCrypto classes created from the corresponding algorithm and obtainning the KeyMaterial from the signer's certificate but I always get a pkvrFailure result with no further explanation.

Thanks for your time in helping me with this issue and sorry for the long post.
#10743
Posted: 08/05/2009 04:34:50
by Ken Ivanov (EldoS Corp.)

Thank you for contacting us and for detailed explanation of the issue.

TElCMSSignature should understand signer location attribute correctly. First of all, can you please check the values of the following properties:
TElCMSSignature.SignerLocation.Included,
TElCMSSignature.SignerLocation.Signed?

It is not a good idea to check signatures manually. This procedure is often not as easy as comparing the message digests, so it would be reasonable to leave this task for PKIBlackbox. I am sure that we together will be able to resolve the signer location issue you are encountering, so you would not have a need to use low-level TElPKCS7Message class.
#10744
Posted: 08/05/2009 05:02:18
by Dominik Foucauld (Standard support level)
Joined: 07/07/2009
Posts: 6

Thanks for the prompt answer.

I have checked the values of the properties and they are both true.

TElCMSSignature.SignerLocation.Included = true
TElCMSSignature.SignerLocation.Signed = true

However:

signature.SignerLocation.LocalityName
{SBCMS.TElASN1DirectoryString}
Encoding: dsePrintableString
Value: ""

signature.SignerLocation.CountryName
{SBCMS.TElASN1DirectoryString}
Encoding: dsePrintableString
Value: ""

signature.SignerLocation.PostalAddressLineCount
0

The location attribute however has the following bytes as expected:
[0]: 48
[1]: 22
[2]: 19
[3]: 11
[4]: 83
[5]: 119
[6]: 105
[7]: 116
[8]: 122
[9]: 101
[10]: 114
[11]: 108
[12]: 97
[13]: 110
[14]: 100
[15]: 19
[16]: 5
[17]: 66
[18]: 97
[19]: 115
[20]: 101
[21]: 108
[22]: 5
[23]: 0
#10745
Posted: 08/05/2009 08:47:53
by Ken Ivanov (EldoS Corp.)

This is an incorrect encoding of SignerLocation attribute. The latter is defined in the following way:

SignerLocation ::= SEQUENCE {
-- at least one of the following shall be present:
countryName [0] DirectoryString OPTIONAL,
-- As used to name a Country in X.500
localityName [1] DirectoryString OPTIONAL,
-- As used to name a locality in X.500
postalAdddress [2] PostalAddress OPTIONAL }

The data you have posted is missing [0] and [1] tags, and that's why no values can be read through LocalityName and CountryName properties of the object (the code considers the value of the attribute to be incorrect). I suppose we will add a workaround to the code to make it read such incorrectly formatted attributes.

BTW, what exactly software product was used to create such a signature?
#10746
Posted: 08/05/2009 09:42:31
by Dominik Foucauld (Standard support level)
Joined: 07/07/2009
Posts: 6

The software product used was Entrust Java Toolkit.

Is there any workaround that I can use in the meantime to have access to the AuthenticatedAttributes contained in the internal ElPKCS7Signer object that the signature has or any other way to obtain the raw value from the signing location?
#10747
Posted: 08/05/2009 10:06:16
by Ken Ivanov (EldoS Corp.)

Thank you.

Unfortunately, there's no "quick-and-dirty" workaround, sorry. As an option, you can load the signature into the TElPKCS7Message object and get a raw value of the attribute from it.

The official workaround will be available with the future build update, which is likely to be available in 10-14 days. We can also provide you with a CVS snapshot build once the workaround is ready, just in case if you need it faster.
#10748
Posted: 08/05/2009 10:41:06
by Dominik Foucauld (Standard support level)
Joined: 07/07/2009
Posts: 6

I can wait untill the build update is ready if it is expected in the time frame that you mentioned.

Is it possible to obtain the source code for the Secure BlackBox toolkit?
#10749
Posted: 08/05/2009 11:06:50
by Ken Ivanov (EldoS Corp.)

The source code download (along with other downloads corresponding to your license) is available in My Control Center panel.
#10778
Posted: 08/11/2009 02:54:23
by Dominik Foucauld (Standard support level)
Joined: 07/07/2009
Posts: 6

Sorry for the delay in this response.

I have reviewed the way that the signature that I am verifying was built and the RFC 3126 where the Signer-location attribute is defined. I believe that you may have an incorrect interpretation of the standard that you quoted.

Both countryName and localityName,if present, should be in the form of strings and not as attributes, i.e. the values are directly stored in the SEQUENCE order specified.

In order to further clarify you can take for comparison purposes the definition of the signer-attributes attribute where the attributes are defined as a SEQUENCE OF CHOICE like so:

SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes
}

and then
ClaimedAttributes ::= SEQUENCE OF Attribute

CertifiedAttributes ::= AttributeCertificate

whereas

SignerLocation ::= SEQUENCE {
-- at least one of the following must be present
countryName [0] DirectoryString OPTIONAL,
-- as used to name a Country in X.500
localityName [1] DirectoryString OPTIONAL,
-- as used to name a locality in X.500
postalAdddress [2] PostalAddress OPTIONAL
}

Thanks again for your time, and I await your feedback.
#10780
Posted: 08/11/2009 06:01:02
by Ken Ivanov (EldoS Corp.)

The "[0]", "[1]" and "[2]" elements preceding field types in the SignerLocation SEQUENCE are so-called user-defined tags. As CMS ASN.1 module uses explicit tagging as the default tagging type, the declaration is equal to the below one:

SignerLocation ::= SEQUENCE {
-- at least one of the following must be present
countryName [0] EXPLICIT DirectoryString OPTIONAL,
-- as used to name a Country in X.500
localityName [1] EXPLICIT DirectoryString OPTIONAL,
-- as used to name a locality in X.500
postalAdddress [2] EXPLICIT PostalAddress OPTIONAL
}

And this, in turn, means that each of the countryName, localityName and postalAddress fields must be enveloped with the outer [0], [1] and [2] tags.

Actually, enveloping the fields of the attribute into the additional user-defined tags is quite natural. Imagine that you have received the signature containing the following signer location attribute value:

SEQUENCE {
"Mexico" DirectoryString
}

As both countryName and localityName fields are optional (according to the declaration), you cannot say for sure if Mexico refers to the country or to the city in this case. Additional user-defined tags make the signer encode the attribute in the following way, removing the ambiguity:

SEQUENCE {
[0] {
"Mexico" DirectoryString
}
}

Hope I answered your question.
Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.

Reply

Statistics

Topic viewed 2136 times

Number of guests: 2, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!