W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

Re: X509CRL discord

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Mon, 14 May 2001 14:21:33 -0400
Message-Id: <200105141821.OAA0000005320@torque.pothole.com>
To: merlin <merlin@baltimore.ie>
cc: w3c-ietf-xmldsig@w3.org, lde008@dma.isg.mot.com
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.


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
>I note that in the thread:
>(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>
>This imposes no constraints other than our verbal ones.
>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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:04 UTC