I need to know when someone signed a key. I mean those key signatures displayed with --list-sig.
It seems they do not show the date of the signing. No information on if it's possible to verify them too.
This signature date is already listed:
pub 8192R/0x4E1F799AA4FF2279 2012-12-25
uid Jens Erat (born 1988-01-19 in Stuttgart, Germany)
sig 3 0x4E1F799AA4FF2279 2012-12-26 Jens Erat (born 1988-01-19 in Stuttgart, Germany)
sig 3 0x4E1F799AA4FF2279 2012-12-25 Jens Erat (born 1988-01-19 in Stuttgart, Germany)
sig 3 0xCBC2613CD745722B 2012-12-26 Jens Erat <email#jenserat.de>
sig P X 0xD2BB0D0165D0FD58 2012-12-26 CA Cert Signing Authority (Root CA) <gpg#cacert.org>
[snip]
^^^^^^^^^^
signature creation time
You cannot take it for sure or even verify it, this is juts the date the signer claims to have signed the key on. The signature date can be arbitrarily set, for example by setting the system time or using the handy tool faketime.
Related
I have a public key pubkey.asc.
Also I have a file file.txt and its detached signature file.txt.asc.
I want to check the following steps:
file.txt.asc is a signature for file.txt
file.txt.asc was created using secret key from a keyring with public key pubkey.asc
I can do the 1st step using gpg --verify file.txt.asc file.txt. This command outputs public key fingerprint which was used to create a signature:
gpg: Signature made <date and time>
gpg: using RSA key <fingerprint>
...
I can see pubkey.asc fingerprint just by running gpg pubkey.asc.
Can I use this information and just check if fingerprints are equal to perform 2nd step? If not, how can I verify a file signature with given public key?
I saw this question about how to verify if signature matches public key, but it only works if key has extension .gpg which is not my case.
OpenPGP key's fingerprint is a SHA1 hash of public key itself plus some additional data, and it uniquely identifies the key (excluding collision cases, which are not known yet for OpenPGP key fingerprints).
So, yeah, seeing 'good signature made by key [fingerprint]' is enough to rely on fact that signature is made by the aforementioned key.
i have self-signed certificate signed by SHA1withECDSA algorithm using BouncyCastle.
Under BC i can verify it easily, but when i`m doing it on JavaCard it send me false everytime(Curve secp192r1 from NIST). Certificate hold sign in plain (non X9.62 mean just r+s without any TAGs).
There is my code to verify it (with values putted as constant - for tests of course).
byte[] certdata = {...}
Signature signature = Signature.getInstance(Signature.ALG_ECDSA_SHA, false);
ECPublicKey ecpk = (ECPublicKey) KeyBuilder.buildKey(KeyBuilder.TYPE_EC_FP_PUBLIC, KeyBuilder.LENGTH_EC_FP_192, true);
ecpk.setA(new byte[]{...}, (short)0, (short)0x0018);
ecpk.setB(new byte[]{...}, (short)0, (short)0x0018);
ecpk.setG(new byte[]{...}, (short)0, (short)0x0031);
//Point format: uncompressed tag(0x04), x, y
ecpk.setK((short)0x0001);
ecpk.setR(new byte[]{}, (short)0, (short)0x0018);
ecpk.setW(new byte[]{}, (short)0, (short)0x31);
ecpk.setFieldFP(new byte[]{}, (short)0, (short)0x0018);
signature.init(ecpk, Signature.MODE_VERIFY);
boolean result = signature.verify(certdata, (short)0, (short)certdata.length, signtab, (short)0, (short)signtab.length);
if(result) ISOException.throwIt((short)0x0001);
else ISOException.throwIt((short)0x0002);
}
'...' instead of bytes for clear view (192bits curve can do big mess).
Certificate with TAGS explanation on pastebin:
http://pastebin.com/gvqYzm2g
Thanks for any help
sevar
edit:
New tests:
All tests re on same data (PublicKey, PrivateKey, Message to be signed)
sign is randomized so i ll use 2 sign (signT - sign generated by Terminal (BC), signC - sign generated by Chip)
signT cant be verified on CHIP but can be verified on Terminal.
signC is verified on CHIP & Terminal
so I checked cross between API
Cross Relation directed to BC works well
Cross Relation directed to CHIP isn't work
pair of key generated well because when i put PrivateKey and PublicKey generated by BC to CHIP, then signature generated on the CHIP can be verified by CHIP.
KeyPair generated well
I have no idea what i should check now. Problem probably can be with filling array in ECDSA step e = SHA1(Message). Whats happen with array after hash(hash is shorter than curve and card needs to declare size of array before copy)
Signing and verification of ECDSAwithSHA-1 with Prime192v1 from Bouncy Castle to JavaCard works fine for me.
Your problem is probably format of the signature itself.
Signature is a DER encoded structure, it is a sequence (tag 0x30) of two integers (tag 0x02). In JavaCard, 56 bytes are always expected: two coordinates of length 25 plus 6 bytes of DER headers. JavaCard always expects leading zeros in each coordinate. However, BC often produces signatures without leading zeros in coordinates, so the signature can be shorter than 56 bytes and that is why JavaCard is confused.
The opposite direction is always OK, because BC can handle leading zeros, although it does not add them when creating signature.
What you should do: wrap the BC signing mechanism with your own code and ALWAYS add leading zeros to coordinates in your BC signature. If you do so, you will be able to verify the signature both in BC and JavaCard.
I would like to post my code, but unfortunately it is a part of a commercial security project...
I had a problem with verifinge a ECDSA singature (generated on JavaCard 192r1) using BouncyCastle and i found a solution. I hope that it will be useful
Verify javacard signature ALG_ECDSA_SHA on bouncy castle
I did a example code to understand how to get a CRMF (mozilla certificate request) to convert it into a CSR more similar to PKCS#10
I got the Base 64 CRMFRequest as a ASN1InputStream type.
I convert it into a CertReqMsg type (Bouncycastle)
when I debug, I realize the CertReqMsg have the public key, another data like Subject (CN, O, OU, etc)and other, but more important, it has a signature and an AlgoritmIdentifier.
but the object doesn't have getters
How I extract the signature as a DERBitString...? I need it to use as parameter to the CertificationRequest object (which returns the CSR as I want it)
by the way, the CertificationRequest need a CertificationRequestInfo object as parameter. and inside it (CertificationRequestInfo ), it receives Attributes as parameter . I supose to this attributes are of the kind of:
distributionPoint, unotice, policyOID, subjectAlternativeNameDN
I know that it start with a
ASN1Set attributes = null;
attributes = new DERSet();
But I don't know how to fill this paramethers to
CertificationRequestInfo info = new CertificationRequestInfo(subject, infoPublicKey, attributes);
Sorry if some question seems obvious... but I can't find the solve..
Thanks in advance
You won't be able to convert the CRMF format into a PKCS#10 CSR.
The CSR is structured like this and signed by the subject's private key:
CertificationRequest ::= SEQUENCE {
certificationRequestInfo CertificationRequestInfo,
signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
signature BIT STRING
}
(Essentially, it's very similar to a self-signed X.509 certificate, without issuer and validity dates.)
Since when you get the CRMF request, you won't have the subject's private key, you won't be able to make this signature.
If you're writing some sort of CA software, you don't really need this. Processing a CRMF request and a CSR request is more or less equivalent. A CA shouldn't really do what the CSR wants blindly anyway, so it would have to vet the attributes it associates with the public key and identity some other way anyway.
Are all the parts of the DN in a X.509 optional?
From RFC3280:
Implementations of this specification MUST be prepared to receive
the following standard attribute types in issuer and subject
(section 4.1.2.6) names:
* country,
* organization,
* organizational-unit,
* distinguished name qualifier,
* state or province name,
* common name (e.g., "Susan Housley"), and
* serial number.
I could not find if any of these is mandatory.
I am asking because I am seeing a certificate that is signed by a trusted CA but in the issuer's field the CN is missing (and the C but I don't think that's important).
I was expecting that CN is mandatory. Is it?
Is there any security implications of the omission of theCN from the issuer's field?
As #Bruno says, there is no requirement in RFC3280 for an Issuer DN to have a CN.
RFC3280 states:
The issuer field MUST contain a non-empty distinguished name (DN).
However, RFC3280 does not make any requirement on which RDN(s) should be present. Most CAs do include a CN in the Issuer DN, but some don't, such as this Equifax CA.
OU = Equifax Secure Certificate Authority,O = Equifax,C = US
Or this Verisign CA.
OU = VeriSign Trust Network,OU = "(c) 1998 VeriSign, Inc. - For
authorized use only",OU = Class 3 Public Primary Certification
Authority - G2,O = "VeriSign, Inc.",C = US
Path building and validation using RFC3280 does not require a CN in the Issuer DN.
The RFC says that the name of the subject may be present in Subject Alternative Name extension. Section 4.2.1.7 says the following (which must be your case):
Further, if the only subject identity included in the certificate is
an alternative name form (e.g., an electronic mail address), then the
subject distinguished name MUST be empty (an empty sequence), and the
subjectAltName extension MUST be present. If the subject field
contains an empty sequence, the subjectAltName extension MUST be
marked critical.
X509 certificates should compare the whole dn. That is
Dn1 == Dn2
Two distinguished names DN1 and DN2 match if they
have the same number of RDNs, for each RDN in DN1 there is a matching
RDN in DN2, and the matching RDNs appear in the same order in both
DNs.
Each component is optional, they may be repeated. However a match requires all the fields match.
From ietf rfc5280
I was looking at GnuPG manual (Manual) and came across below section at page 18:
chloe% gpg -edit-key chloe#cyb.org
Secret key is available.
pub 1024D/26B6AAE1 created: 1999-06-15 expires: never trust: -/u
sub 2048g/0CF8CB7A created: 1999-06-15 expires: never
sub 1792G/08224617 created: 1999-06-15 expires: 2002-06-14
sub 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14
(1) Chloe (Jester) <chloe#cyb.org>
(2) Chloe (Plebian) <chloe#tel.net>
It says: The keyword pub identifies the public master signing key, and the keyword sub identifies a public subordinate
key.
I am not understanding, what is subordinate key for? Any help?
Short version: keys are tagged and used for different types of functions. For example, the primary key must be a signing key. Subordinate keys allow for additional functions (ie encryption).
Long Version: From the GNUPG site:In a public-key system, each user has a pair of keys consisting of a private key and a public key.... GnuPG uses a somewhat more sophisticated scheme in which a user has a primary keypair and then zero or more additional subordinate keypairs. The primary and subordinate keypairs are bundled to facilitate key management and the bundle can often be considered simply as one keypair.
...
GnuPG is able to create several different types of keypairs, but a primary key must be capable of making signatures. There are therefore only three options. Option 1 actually creates two keypairs. A DSA keypair is the primary keypair usable only for making signatures. An ElGamal subordinate keypair is also created for encryption
...
it is possible to later add additional subkeys for encryption and signing.