[x500standard] Re: [Spam] Re: Lack of clarity in X.509
- From: "Erik Andersen" <era@xxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>
- Date: Wed, 25 Jun 2008 15:10:07 +0200
Hi,
We have a small logistic problem. We plan to have the sixth edition out
at the September meeting. There is less than three months meaning we do
not have time for a Draft Technical Corrigendum ballot before then. A
clarifying text will therefore be (a part of) a Corrigendum to the sixth
edition, rather than being integrated into the sixth edition.
Erik Andersen
Andersen's L-Service
Mobile: +45 20 97 14 90
e-mail: era@xxxxxxx
http://www.x500.eu
http://www.x500standard.com/
-----Original Message-----
From: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of Santosh Chokhani
Sent: 25. juni 2008 01:19
To: x500standard@xxxxxxxxxxxxx
Cc: Carl Wallace
Subject: [Spam] [x500standard] Re: Lack of clarity in X.509
Dave,
I have not objection to clarifying. I will be happy to develop or
review the text.
BTW, on SAN, it is not required that it understand all name forms on
which name constraint is imposed. That is because, if a name constraint
occurred on a name form not understood, the certificate and path will
already have been rejected.
-----Original Message-----
From: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of David Chadwick
Sent: Tuesday, June 24, 2008 7:03 AM
To: x500standard@xxxxxxxxxxxxx
Cc: Carl Wallace
Subject: [x500standard] Re: Lack of clarity in X.509
Hi Santosh
thankyou for responding. Whilst you have found text that applies to
non-critical extensions, I dont believe there is any that applies
directly to critical ones. It is always dangerous to assume firstly
that people can correctly work out what the inferences are, and secondly
that they can work out the correct inferences, from a standard piece of
text. Clearly browser manufacturers today cannot. Explicit statements
are always preferred to implicit ones.
If this list can agree amongst itself what the correct inferences are
for unknown bits of critical extensions, then I would suggest a short
paragraph be inserted in the standard to explicitly state these. If, as
Santosh seems to be implying, there is no single correct inference, and
each extension has to explicitly state it on a case by case basis, then
the standards should insert a sentence along the following lines.
"If unknown elements appear in a recognised extension that is marked
critical, then the interpretation of the known and unknown elements is
extension specific and is documented in each extension".
regards
David
Santosh Chokhani wrote:
> David,
>
> I found the following in X.509:
> "If unknown elements appear within the extension, and the extension is
> not marked critical, those unknown elements shall be ignored according
> to the rules of extensibility documented in 12.2.2 in ITU T Rec. X.519
|
> ISO/IEC 9594-5".
>
> I would say that this implies through corollary that if there are
> elements that can not be processed in a critical extension, the
> certificate must be rejected.
>
> That said, you have to be logical about this stuff.
>
> For example, for EKU, if your EKU is present, even if you do not
> recognize others, you should use the certificate.
>
> The standard has specific language regarding unrecognized name forms
in
> the SAN extension. I would say that the guidance is incomplete. If a
> name form is not recognized and that name form is constrained via
prior
> certificates in the certification path, you must reject the
certificate.
>
> You must be able to process all the name forms asserted in the name
> constraints extension.
>
> In general, I think the rule in X.509 may be generic and specific
fields
> have rules except that SAN rule may be incomplete.
>
> -----Original Message-----
> From: x500standard-bounce@xxxxxxxxxxxxx
> [mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of David Chadwick
> Sent: Monday, June 23, 2008 4:34 AM
> To: x500standard@xxxxxxxxxxxxx
> Subject: [x500standard] Lack of clarity in X.509
>
> Dear All
>
> A colleague has been testing how various browsers behave when faced
with
> SSL certificates with various extensions marked critical or
> not-critical. He has found that the browsers behave in different ways.
> He says that one of the problems is that the standard is not specific
> enough on how the browsers should behave in all circumstances.
>
> Here is one scenario to consider. An extension is marked critical and
> the RP software understands the extension but only implements part of
it
> (say it has an OID for describing elements of it, or it is a set of
> choices). Does the text in X.509 say how the RP should handle this? I
> think not. Should the unknown parts of the extension be ignored or
> should the entire certificate be rejected? e.g. the extension is
Subject
> Alt Names and some of the names are understood and some are not.
>
> As a side issue, an RP can decide to accept any certificate,
regardless
> of what the CA says in the certificate (and some browsers allow the
user
> to do this). In this case the CA wont accept any liability and the RP
is
> acting outside the standard. But is this stated clearly enough in the
> standard?
>
> regards
>
> David
>
--
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@xxxxxxxxxx
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site:
http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************
-----
www.x500standard.com: The central source for information on the X.500
Directory Standard.
-----
www.x500standard.com: The central source for information on the X.500
Directory Standard.
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
