Please find answers in quoted text.
Aleksey Sanin wrote:
Hi, Roumen!
Unfortunatelly, I could not open your diff files by some reasons
Please check http://roumenpetrov.info/tmp/xmlsec/ for the files. About patch: - please review new methods - they are release candidates; - all other is very early release, even before alpha version ;-).
(the folders are there but diff itself is empty). However, from your description I see a problem with this patch. You are using a static variable to determine the format and this seems wrong to me.
:-) Yes this is OPEN ISSUE: which format (<X509Certificate/>, <X509SubjectName/> or <X509IssuerSerial/>) to use method xmlSecOpenSSLKeyDataX509XmlWrite.
- instead of "switch (x509data_type)" we should use right condition (open issue !).
- instead of "case 1/case 2/case 3" we should use defines, as example:
#define xmlSecX509DataTypeUndefined 0
#define xmlSecX509DataTypeCertificate 1
#define xmlSecX509DataTypeSubjectName 2
#define xmlSecX509DataTypeIssuerSerial 3
, but where to put these/similar defines (open issue) ?
xmlsec library has two ways to control the processing: templates and contexts. This allows user to have different processing rules for different threads. Using a static variable breaks this very important feature.
I would think that the right way to achieve your goal would be to put control in templates. For example, xmlsec could read the <X509Data/> node from template and write back: 1) <X509Certificate/> if there is no child elements 2) subject name/issuer/certificate if there is corresponding child node in the <X509Data/> template
good idea, but "merlin-xmldsig-twenty-three/signature-x509-is.tmpl" has only <X509Data/>, i.e. elements format in X509Data should be specified from command line and/or environment. Of course when template contain "<X509Data><X509SubjectName/></X509Data>" we should use 'sn' when element X509Data type is undefined.
In addition to that we should determine when to write CRLs (always?).
No idea. Yes we can send crl, but when signer (one side) has old CRL and verifier (other side) has new CRL we should care for this (especially when new CRL revoke one of certificates). I think is possible new CRL to be issued before expiration date of old CRL. Some CRLs are too big.
Finally, there is a good question about an option to write full
certificate and subject for another one in the same time. Is it possible?
yes. How to specify this from command line ?
My idea is:
$ xmlsec sign --privkey-pem "<KEYFILE>[,[{|crt:|sn:|is:}]<CERT_FILE>...]" ...
or
$ xmlsec sign --privkey-pem "<KEYFILE>[,<CERT_FILE>[#{|crt|sn|is}]...]" ...
, i.e. when certificate file name begin/end with 'sn:/#sn' we should write X509SubjectName, for 'is:/#is' - X509IssuerSerial, 'crt:/#crt' - allways X509Certificate and otherwise default format (X509Certificate when is not specified other).
We can use environment to specify default format:
XMLSEC_X509DATATYPE=sn \
$ xmlsec sign --privkey-pem "<KEYFILE>,[<CERT_FILE>...]" ...
, where allowed values are '{sn|subjectname}' (case insensitive) for <X509SubjectName/>, '{is|issuerserial}' for <X509IssuerSerial/> and all other for <X509Certificate/>
or command line:
$ xmlsec sign --with-x509datatype=<SAME_VALUES_AS_IN_ENVIRONMENT> --privkey-pem "<KEYFILE>,[<CERT_FILE>...]" ...
or from template:
....<X509Data><X509SubjectName/></X509Data>....
Note: command line must take precedence over environment settings, and template over all other settings.
Other ideas ?
Can you suggest a good simple scheme to control this?
I'm not familiar with xmlsec enough. After one, two months... ;-)
Aleksey
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
