[xmlsec] core methods for write of <X509SubjectName/> and <X509IssuerSerial/>
Roumen Petrov
xmlsec at roumenpetrov.info
Fri Jul 18 02:51:20 PDT 2003
Hi Aleksey,
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
>
More information about the xmlsec
mailing list