The URN form ECDSA signature algorithm is
urn:nist-gov:ecdsa.
But I am not able to find a named URN for algorithm SHA1withECDSA.
Up to now I've found the xmldsig URL for SHA1withECDSA:
http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1
And I have the option to generate the URN with its OID, according to RFC3061:
urn:oid:1.2.840.10045.4.1
I could even create my own version of its URN as something like urn:nist-gov:ecdsa-sha1
But, is it a named standard URN for signature algorithm SHA1withECDSA ?
Related
I have a Sun ONE ldap account the dn of which accidentally became base64-encoded after an rdn change. I have tried various ways to delete this account to no avail. I hope there are people here who know a solution and able help me out.
On the Sun ONE ldap server all attributes are encoded in ascii. The attribute used as rdn is uid. The format of uid for user accounts is FIRSTNAME.LASTNAME.
The uid of the account in question was YAZAIRA.DAZ. A utility written in unix shell was used to change the rdn of the account from YAZAIRA.DAZ to YAZAIRA.DIAZ. The utility prompts for both the old uid and the new uid, and takes care of everything else under the hood to get the rdn changed. At the time, the new uid was copied from another system and pasted at the prompt to the utility, which contained a non-ascii character: YAZAIRA.DÍAZ (notice the ' on top of I).
Therefore, under the hood, the ldif was
dn: uid=YAZAIRA.DAZ,OU=People,dc=company,dc=com
change-type: modrdn
newrdn: uid=YAZAIRA.DÍAZ
deleteoldrdn: 1
After the ldif was run, ldapsearch was not able to find the account. Luckily, after many tries, the account entry was eventually returned as one of several when uid=YAZAIRA.* was entered as search criteria. However, its dn is:
dn:: dWlkPVlBWkFJUkEuRM1BWixvdT1QZW9wbGUsZGM9Y29tcGFueSxkYz1jb20=
and all the attributes that contains the new last name are base64 encoded too.
I want to delete this account using ldapdelete with the accompanying file containing the dn. So far I have tried the following dn, but none has worked:
dWlkPVlBWkFJUkEuRM1BWixvdT1QZW9wbGUsZGM9Y29tcGFueSxkYz1jb20=
uid=YAZAIRA.DIAZ,OU=People,dc=company,dc=com
uid=YAZAIRA.DÍAZ,OU=People,dc=company,dc=com
uid=cWUFaQUlSQS5EzUFa,OU=People,dc=company,dc=com
uid=YAZAIRA.RM1BWg==,OU=People,dc=company,dc=com
uid=YAZAIRA.*,OU=People,dc=company,dc=com
Would appreciate it very much if someone knows how to specify the dn to ldapdelete. Or if there are some alternative ways to delete an account by uniquely identifying the account using attributes other than the dn. Or whatever means to get this account deleted.
Have you tried ldapdelete with the following LDIF?
dn:: dWlkPVlBWkFJUkEuRM1BWixvdT1QZW9wbGUsZGM9Y29tcGFueSxkYz1jb20=
changetype: delete
-
I'm trying to validate this message using a public key that I know is good. If I had the code in php or c++, that would be perfect. Ideally, I just need to know the data that is being used from the message.
Below is the sample message.
-----BEGIN TR34_Sample_CA_KRD.p7b-----
MIIDcQYJKoZIhvcNAQcCoIIDYjCCA14CAQExADAPBgkqhkiG9w0BBwGgAgQAoIID
QjCCAz4wggImoAMCAQICBTQAAAAGMA0GCSqGSIb3DQEBCwUAMD8xCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxUUjM0IFNhbXBsZXMxGTAXBgNVBAMTEFRSMzQgU2FtcGxl
IFJvb3QwHhcNMTAxMTAyMDAwMDAwWhcNMjUxMDI4MjM1OTU5WjBBMQswCQYDVQQG
EwJVUzEVMBMGA1UEChMMVFIzNCBTYW1wbGVzMRswGQYDVQQDExJUUjM0IFNhbXBs
ZSBDQSBLUkQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD79+R/P7Ox
9NQVfsmKX8WFTDQpX8a4h29AWw437Z0+WkzplhwTpEcw5OiXqpJ2vSAw80UjuplX
8FZ7oFOpNOyVkj6zkF764ZygA5F4ycHwhGg+JScKc1YW5LoUpV38k7+shAh6Irwp
BxgwM0i+F6LGAVlF/ZoUcF18Q7qUgNdiP7tGjSS2EgRm+fCH49eJuCopHOF4uciv
4wGEp8uHaWIPTsxtIStFOPRumheKssvnrK7PHZEWTtDvWTNARH54UP99eT3EhRKI
TiDgneqACQljhHY1vtPpIXTfqYI4QdDviRLcInujDGgTM2hG2UEkjcDU8OLSWWWC
WO0aAhhHKeLbAgMBAAGjPzA9MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFBI4
bs+2pm7a2/8Jb2W71bBQ+cwNMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQsFAAOC
AQEAayNCRdcgDRQYHWB6xs5zWNl10j2jA/IfVLjeuvemiMtc5QUiMkrdktC4EzF6
vZYa1B0QdXY5qMjWGF3MyN8GPgtdSQayH65BFhyRN1MaicsRmPch5VekqnqijJ6G
mYPwbGlDE0ygJTkoaDreEzZOv8Ikqn4dvCC9h5Fu778A2iAvD0bebvxheOONLJrD
b8mLffrBQLI5YprFYeKE9W0JrhqHjukAfhBZl8XXTRrH+XA8eCskJRjxczCbuboA
qHekeCL8hZ4ePWFfVdEKDFmIRz+lhIZnNj+upKdhKVZasHmNft4aGLpUtgApbM42
MyKEQH/1tzSYfWJcMh5AAE9l4TEA
-----END TR34_Sample_CA_KRD.p7b-----
Answered my own question. Basically, it's the sequence tag and all the data under the sequence tag that's at the same level as the sequence tag containing the signature. Do not include the tags or data above it. Do not include the signature or the sequence tag of the signature.
ASN.1 DECODED DATA
I am trying to migrate my web service client from BO 3.x to BO 4.1 Restful.
The existing implementation of BO 3.x uses BO java SDK to get CUID and doc properties to get the PDF report by using below inputs.
Report Path : path://InfoObjects/Root Folder/Application Name/Report
Name.rpt
Fill Parameter List : Parameter 1, Parameter 2, Parameter 3 etc to identify a report.
I have constructed my client code to get Logon token from RESTful web service. However I am not sure how to retrieve the PDF file now in BO 4.1.
Many of the samples I have seen uses sIDType and iDocID parameters along with Token value to retrieve the document by constructing a URL like below
http://server:port/BOE/OpenDocument/opendoc/openDocument.jsp?token=[LogonToken]&iDocID=[XXXX]&sIDType=CUID
My question : Is it must to have iDocID to retrieve document using URL pattern above or is it possible to construct a URL using report path / CUID and fill parameters ( without using iDocID) to retrieve pdf report from BO Web service.
Please assist me on this. Thanks
Note the &sIDType=CUID parameter in your sample URL -- that indicates that the page is expecting the value of iDocID to be a CUID. Without sIDType=CUID, it would expect the value to be an integer document ID.
That is, you only need the CUID, not the document ID. Also, CUID is unique, so there would be no value in specifying both CUID and path.
Incidentally, instead of specifying a CUID or ID, you can specify the document's path and name. However, this functionality is deprecated in BI4.1.
Prompt values can be supplied to openDocument using the lsS and lsM parameters (for single-select and multi-select prompts, respectively).
See the openDocument documentation here.
I have been going thru X.509 RFCs, and I have issues with domain name matching conventions.
Should the domain name "www.foo.com" match with "foo.com" and ".foo.com" domain names in ssl certificates? please note there is no wildcards.
there is a snippet of section 4.2.1.10 name constraints from RFC 5280, the same restrictions apply alt name extentions.
"DNS name restrictions are expressed as host.example.com. Any DNS
name that can be constructed by simply adding zero or more labels to
the left-hand side of the name satisfies the name constraint. For
example, www.host.example.com would satisfy the constraint but
host1.example.com would not."
unfortunately, if you have a certificate for "www.foo.com", it will not automatically work for "foo.com" unless specified by your certificate provider (or CA). had this same issue before. check the fine prints, something should be listed as "Secures both your www and non-www" or contact their support and ask how it should be done
The section you quote from RFC 5280 (section 4.2.1.10) isn't about host name matching in the sense of what the client should verify when it connects to the server, it's about what CAs are allowed to issue if they use the name constraints extension.
What you see to be after used to be protocol-specific, and defined in RFC 2818 (section 3.1) for HTTPS.
RFC 6125 is more recent and harmonises this across application protocols. (It's not necessarily widely implemented.)
More specifically, www.foo.com will not match foo.com or .foo.com:
6.4.1. Checking of Traditional Domain Names
If the DNS domain name portion of a reference identifier is a
"traditional domain name", then matching of the reference identifier
against the presented identifier is performed by comparing the set of
domain name labels using a case-insensitive ASCII comparison, as
clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased
to "www.example.com" for comparison purposes). Each label MUST match
in order for the names to be considered to match, except as
supplemented by the rule about checking of wildcard labels
(Section 6.4.3).
Generally, if you want a certificate to be valid for www.foo.com and foo.com, it will need to have multiple Subject Alternative Names (even foo.com isn't covered by *.foo.com).
I have one certificate which has "RFC822 Name=null" in "subject alternative name".
Can I know how can we edit this extension so that I can put some value in this field.