Re: gpgsm as a CA
On Wed, 28 Feb 2018 18:57, andr...@andrewg.com said: > Is there any support for using gpgsm as a certificate authority? There is some basic support to create certificates: The format of the parameter file is described in the manual under "Unattended Usage". [...] This parameter file was used to create the STEED CA: Key-Type: RSA Key-Length: 1024 Key-Grip: 68A638998DFABAC510EA645CE34F9686B2EDF7EA Key-Usage: cert Serial: 1 Name-DN: CN=The STEED Self-Signing Nonthority Not-Before: 2011-11-11 Not-After: 2106-02-06 Subject-Key-Id: 68A638998DFABAC510EA645CE34F9686B2EDF7EA Extension: 2.5.29.19 c 30060101ff020101 Extension: 1.3.6.1.4.1.11591.2.2.2 n 0101ff Signing-Key: 68A638998DFABAC510EA645CE34F9686B2EDF7EA %commit Here a Root CA certificate is created. However, the Signing-Key parameter is a generic feature and thus it can also be used to let this CA sign another key. What's missing in gpgsm are a parser for the CSR and code to filter the values of a CSR into a new certificate. The parser can be quite easily added the other stuff needs some thinking. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpAESnHaFLLb.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm as a CA
> Hi, all. > > Is there any support for using gpgsm as a certificate authority? Hi, FWIW I have put up a guide recently on how I achieved this with gpgsm + an OpenPGP card for private key handling. You can drop the card thing if you don't intend using and keep the private key instead. https://github.com/jymigeon/gpgsm-as-ca It is still a bit rough, I expect to expand it a bit in a few days. All certificates I issue through this method work with the openssl stacks we have around, so it is working from my PoV. Did not investigate how to handle the CRL part though, and the X.509 extensions need a bit more work to be user-friendly, but you can safely figure this out via openssl asn1parse. -- Jean-Yves Migeon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpgsm as a CA
Hi, all. Is there any support for using gpgsm as a certificate authority? -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
Werner Koch [EMAIL PROTECTED] writes:
Thus we have an extra NULL and that is the reason that it does not
verify. I am too tired to read pkcs#1 know; will do that tomorrow.
Anyway it is the first case that I noticed such a pkcs#1 encoding.
Ah, I see. Whether the parameters should be NULL or absent seem to be
a frequent interop problem.
Hi,
whether the optional parameter of the AlgorithmIdentifier is really
optional has changed over time. My ASN.1 derived from the German Sphinx
profile state:
AlgorithmIdentifier ::= SEQUENCE {
algorithmOBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
-- should be used but set to NULL
}
rfc3280 (X.509) does not have this remark. Peter Gutmann's X.509 guide
explains this issue:
Another pitfall to be aware of is that algorithms which have no
parameters have this specified as a NULL value rather than omitting
the parameters field entirely. The reason for this is that when the
1988 syntax for AlgorithmIdentifier was translated into the 1997
syntax, the OPTIONAL associated with the AlgorithmIdentifier
parameters got lost. Later it was recovered via a defect report, but
by then everyone thought that algorithm parameters were mandatory.
Because of this the algorithm parameters should be specified as NULL,
regardless of what you read elsewhere.
How did you create this certificate?
With GnuTLS' certtool.
RFC 3280 references RFC 3279 on this, and it says:
When any of these three OIDs appears within the ASN.1 type
AlgorithmIdentifier, the parameters component of that type SHALL be
the ASN.1 type NULL.
RFC 3279 is updated by RFC 4055 which says in section 2.1 (in
particular the second paragraph):
There are two possible encodings for the AlgorithmIdentifier
parameters field associated with these object identifiers. The two
alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax. Later the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory. Because of this
history some implementations encode parameters as a NULL element
while others omit them entirely. The correct encoding is to omit the
parameters field; however, when RSASSA-PSS and RSAES-OAEP were
defined, it was done using the NULL parameters rather than absent
parameters.
All implementations MUST accept both NULL and absent parameters as
legal and equivalent encodings.
To be clear, the following algorithm identifiers are used when a NULL
parameter MUST be present:
sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL }
sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL }
sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL }
sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL }
Although it may be argued that RFC 4055 only applies to RSA-PSS,
although this particular section is not clear that it only applies to
RSA-PSS.
I should probably change GnuTLS here.
/Simon
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
On Wed, 18 Apr 2007 11:39, [EMAIL PROTECTED] said: RFC 3279 is updated by RFC 4055 which says in section 2.1 (in particular the second paragraph): Which is actually Peter's text but with a different suggestion. Although it may be argued that RFC 4055 only applies to RSA-PSS, although this particular section is not clear that it only applies to RSA-PSS. The problem is that allowing for different encodings will require a complete DER (or well for some old specs even BER) parser in libgcrypt. Not long ago most crypto libraries showed implementaion flaws in that - libgcrypt didn't suffer from this due its poor man's and simple approach to checkthe RSA signature. Given that the code in gpgsm/libgcrypt has passed several compatibility tests I doubnt that it is a good idea to change it now and open the way to introduce new bugs. I should probably change GnuTLS here. I'd appreciate that. If it later turns out that too many gnutls created certificates are in use we might consider to add a hack to gpgsm just for the SHA-1 case. Shalom-Salam, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
Werner Koch [EMAIL PROTECTED] writes: Although it may be argued that RFC 4055 only applies to RSA-PSS, although this particular section is not clear that it only applies to RSA-PSS. The problem is that allowing for different encodings will require a complete DER (or well for some old specs even BER) parser in libgcrypt. Not long ago most crypto libraries showed implementaion flaws in that - libgcrypt didn't suffer from this due its poor man's and simple approach to checkthe RSA signature. Given that the code in gpgsm/libgcrypt has passed several compatibility tests I doubnt that it is a good idea to change it now and open the way to introduce new bugs. It is possible to avoid a DER/BER decoder if you generate two structures, one with NULL parameters and one with absent parameters, and compare both against what's in the decrypted signatures. I should probably change GnuTLS here. I'd appreciate that. If it later turns out that too many gnutls created certificates are in use we might consider to add a hack to gpgsm just for the SHA-1 case. GnuTLS accepts both variants, so I made the change. I'll release an updated stable version to help get it out as soon as possible. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
On Wed, 18 Apr 2007 14:11, [EMAIL PROTECTED] said: It is possible to avoid a DER/BER decoder if you generate two structures, one with NULL parameters and one with absent parameters, and compare both against what's in the decrypted signatures. There is a plan tomove pkcs#1 decoding into libgcrypt. This would allow us to do a second compare without too much changes. I'll put it onto my todo list but don't expect it to happen anytime soon. GnuTLS accepts both variants, so I made the change. I'll release an updated stable version to help get it out as soon as possible. Would it be sufficient to do that just for SHA-1? In that case a hack in cipher/rsa.c would do the trick without too much fear of regression. Salam-Shalom, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
Werner Koch [EMAIL PROTECTED] writes: On Wed, 18 Apr 2007 14:11, [EMAIL PROTECTED] said: It is possible to avoid a DER/BER decoder if you generate two structures, one with NULL parameters and one with absent parameters, and compare both against what's in the decrypted signatures. There is a plan tomove pkcs#1 decoding into libgcrypt. This would allow us to do a second compare without too much changes. I'll put it onto my todo list but don't expect it to happen anytime soon. Doing PKCS#1 in libgcrypt would be useful for GnuTLS too. I'd like to remove that code in the long run... OTOH, it seems likely that GnuTLS will use some assuan-like protocol and an agent to do private key signing operations, so maybe this concern will be moot. GnuTLS accepts both variants, so I made the change. I'll release an updated stable version to help get it out as soon as possible. Would it be sufficient to do that just for SHA-1? In that case a hack in cipher/rsa.c would do the trick without too much fear of regression. I don't know. If you do it for SHA-1, that will cover many practical situations and that may be enough. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
On Tue, 17 Apr 2007 20:14, [EMAIL PROTECTED] said:
As far as I can tell, there is nothing wrong with this certificate.
Ideas?
If you look at the pkcs#1 encoding, you get:
Your certificate:
0 30 31: SEQUENCE {
2 307: SEQUENCE {
4 065: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
: }
11 04 20: OCTET STRING
: 2D E8 78 BE 21 E4 F4 3F FE 26 9F F3 20 20 9C BC
: D3 CE E6 23
: }
gpgsm constructs this pkcs#1 to compare it against yours:
0 30 33: SEQUENCE {
2 309: SEQUENCE {
4 065: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
11 050: NULL
: }
13 04 20: OCTET STRING
: 2D E8 78 BE 21 E4 F4 3F FE 26 9F F3 20 20 9C BC
: D3 CE E6 23
: }
Thus we have an extra NULL and that is the reason that it does not
verify. I am too tired to read pkcs#1 know; will do that tomorrow.
Anyway it is the first case that I noticed such a pkcs#1 encoding.
I don't know if it is relevant, but the list of 'Supported algorithms'
seems rather short:
Well there is no routine yet to print them. It would actually be a long
list given all the OIDs you may use to tell taht it is RSA or SHA1 or
whatever.
Salam-Shalom,
Werner
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
