- From: merlin <merlin@baltimore.ie>
- Date: Thu, 10 May 2001 16:48:27 +0100
- To: w3c-ietf-xmldsig@w3.org
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 Thursday, 10 May 2001 11:49:28 UTC