Re: X509CRL discord

Hi Merlin,

I agree with you and believe I have argued that way in the past.  The
current syntax may be left over from much earlier when X509Data was
limited to one certificate. Unless there are significant objections, I
think we should adopt your suggestion.

Donald

From:  merlin <merlin@baltimore.ie>
To:  w3c-ietf-xmldsig@w3.org
Date:  Thu, 10 May 2001 16:48:27 +0100
Message-Id:  <20010510154827.ACEB84477D@yog-sothoth.ie.baltimore.com>

>In response to producing an X.509 CRL example, I just wanted to
>note that I really don't like the lack of harmony in our definition
>of CRL handling within X.509 data.
>
>Forcing the CRL to be placed in a separate X.509 data element from
>the corresponding certificate material simply makes the process of
>identifying association harder.
>
>Additionally, the restriction to just a single CRL per X.509 data
>makes the handling of delta CRLs very unwieldy; we wind up with a
>bunch of different X.509 data, where one would be much more
>straightforward.
>
>I note that in the thread:
>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0254.html
>(and others) several people have argued for more flexibility with
>the CRL, but I've yet to find the argument that was made against
>this flexibility...
>
>For reference, I'd like the definition to be simply
>
><complexType name="X509DataType">
>  <sequence maxOccurs="unbounded">
>    <choice>
>      <element name="X509IssuerSerial" type="ds:X509IssuerSerialType"/>
>      <element name="X509SKI" type="base64Binary"/>
>      <element name="X509SubjectName" type="string"/>
>      <element name="X509Certificate" type="base64Binary"/>
>      <element name="X509CRL" type="base64Binary"/> </choice>
>      <any namespace="##other" processContents="lax"/>
>    </choice>
>  </sequence>
></complexType>
>
>This imposes no constraints other than our verbal ones.
>
>Merlin
>
>r/merlin@baltimore.ie/2001.05.10/15:25:13
>
>
>-----------------------------------------------------------------------------
>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.
>
>In addition, certain Marketing collateral may be added from time to time to
>promote Baltimore Technologies products, services, Global e-Security or
>appearance at trade shows and conferences.
>
>This footnote confirms that this email message has been swept by
>Baltimore MIMEsweeper for Content Security threats, including
>computer viruses.
>   http://www.baltimore.com
>

Received on Monday, 14 May 2001 14:22:23 UTC