Re: CRL in DSig interop test set

      As far as I know, when signature validation is defined as an
application it normally incorporates certificate path validation, as an
optional feature if not a mandatory one.  Since the principal reason to
include a CRL in a signed document is to allow path validation without
requiring the validator to go find revocation status, it doesn't seem that
great a burden to exercise it.
      There is no definition in the specification of the processing of the
X509CRL element, although in RFC 2459 one is expected to process a CRL or
equivalent for every certificate in the chain.  Minimally, for any X509CRL
which matches one or more of the X509Certificate's in the same SignedData
structure (the match is between the certificate's issuer field and the
CRL's IssuerName field  if the certificate does not have a
DistributionPoint with a cRLIssuer field and between the CRL's IssuerName
field and the DistributionPoint's cRLIssuer field if it does), you verify
the signature of the CRL and then look for an entry with the certificate's
serial number in revokedCertificates.  The parenthetical matching rule
above is basically similar to the current PKIX draft, but I've omitted the
"indirectCRL" check when the cRLIssuer field is used.

            Tom Gindin


merlin <merlin@baltimore.ie>@w3.org on 04/19/2002 05:10:02 PM

Sent by:    w3c-ietf-xmldsig-request@w3.org


To:    Ari Kermaier <arik@phaos.com>
cc:    w3c-ietf-xmldsig@w3.org
Subject:    Re: CRL in DSig interop test set



The reason for that example (in fact, all those X.509 examples)
is that I was under the impression that this working group was
required to demonstrate interoperability among all of our defined
syntax, which includes X509CRL. I don't think that inclusion of a
CRL is particularly useful; it is just part of our syntax.

RFC 2026, 4.1.2 Draft Standard (presuming that is our goal)

 The requirement for at least two independent and interoperable
 implementations applies to all of the options and features of the
 specification.  In cases in which one or more options or features
 have not been demonstrated in at least two interoperable
 implementations, the specification may advance to the Draft Standard
 level only if those options or features are removed.

Merlin

r/arik@phaos.com/2002.04.19/15:14:59
>Dear All,
>
>In the new interop test set, merlin-xmldsig-twenty-three, there is one
test
>signature that troubles me a little. The one called
>signature-x509-crt-crl.xml implies signature validation processing that
>isn't really described by the specification. It's all well and good that
>the X509Data element can be used to transport a CRL. However, actually
>using the CRL should be part of certificate path validation, rather than
>signature validation per se. I mean, we might as well be testing whether
>DSig implementations can correctly parse an AuthorityInfoAccess extension
>in the certificate and execute an OCSP lookup based on the contents. So,
>IMHO, deciding to check a certificate against a CRL is
application-specific
>functionality that shouldn't really be introduced into interop testing for

>the DSig spec in general.
>
>Cheers,
>
>Ari
>
>
>Ari Kermaier    arik@phaos.com
>Senior Software Engineer
>Phaos Technology Corp.    http://www.phaos.com/
>


-----------------------------------------------------------------------------

The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The
unauthorised use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com

Received on Tuesday, 23 April 2002 08:10:39 UTC