headers
Moshe Litvin | 1 Apr 1998 09:14
Picon
Favicon

Re: Questions about PKCS #10 and cert extensions

Peter Gutmann wrote:
>
> Moshe Litvin <moshe <at> CHECKPOINT.COM> writes:
> >Peter Gutmann wrote:
> >>Since including certain extensions like
> >>basicConstraints, keyUsage, certificatePolicies, and a few others is
> >>pointless unless they're marked critical, I'm thinking of recommending that
> >>if used, these extensions must be marked critical.  What do people think
> >>about this?
>
> >I think that this prove the point, marking an extension as critical will
> >render it useless for a lot of software, you don't want to do it unless you
> >have a VERY good reason to do so.
>
> But if an extension isn't marked critical then by implication it's marked
> useless, because an implementation is free to ignore it.  For example:

Critical does not necessary mean important. The critical flag was meant
to be a backward compatibility flag - a way to add information to a
certificate without breaking existing applications.

Unless explicitly specified an application must process any extension it
understands regardless of the criticality flag. The criticality flag is
meant only for application that does not understand the specific
extension.

>
> >I suggest the we will should say that the the basicConstraints shouldn't be
> >marked critical on a CA's certificate.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Jueneman | 1 Apr 1998 15:52
Picon
Favicon

Re: Questions about PKCS #10 and cert extensions

I disagree.
>
>>>> Moshe Litvin <moshe <at> CheckPoint.COM> 04/01 12:14 AM >>>

>> But if an extension isn't marked critical then by implication it's marked
>> useless, because an implementation is free to ignore it.  For example:
>
>Critical does not necessary mean important. The critical flag was meant
>to be a backward compatibility flag - a way to add information to a
>certificate without breaking existing applications.

I STRONGLY disagree. From my perspective, one of the most important
reasons for defining the Critical flag was to force applications to reject
a certificate if they didn't understand some attribute which the subscriber
or CA thought was particularly important.. In particular, a user notice field,
a reliance limit field, or some other constraint which either
the CA or the subscriber feels is absolutely crucial for her protection.

The various constraints, of course, potentially fall into that category, but
there are interoperability  issues with existing software that have to be
taken into account.
>
>Unless explicitly specified an application must process any extension it
>understands regardless of the criticality flag. The criticality flag is
>meant only for application that does not understand the specific
>extension.

>> PKIX part 1 requires that compliant implementations handle a number of
>> important constraint extensions, so there shouldn't be any problem in
>> requiring that various constraints are marked critical.  At the moment the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Moshe Litvin | 1 Apr 1998 18:37
Picon
Favicon

Re: Questions about PKCS #10 and cert extensions

Just to be on the same page PKIX part 1 specify in section 4.2:

   Each extension in a certificate may be designated as crit-
   ical or non-critical.  A certificate using system (an application
   validating a certificate) must reject the certificate if it
   encounters a critical extension it does not recognize.

That is the draft gives permission to ignore the extension only if you
don't understand it.

Bob Jueneman wrote:
>
> I disagree.
> >
> >>>> Moshe Litvin <moshe <at> CheckPoint.COM> 04/01 12:14 AM >>>
>
> >> But if an extension isn't marked critical then by implication it's marked
> >> useless, because an implementation is free to ignore it.  For example:
> >
> >Critical does not necessary mean important. The critical flag was meant
> >to be a backward compatibility flag - a way to add information to a
> >certificate without breaking existing applications.
>
> I STRONGLY disagree. From my perspective, one of the most important
> reasons for defining the Critical flag was to force applications to reject
> a certificate if they didn't understand some attribute which the subscriber
> or CA thought was particularly important.. In particular, a user notice field,
> a reliance limit field, or some other constraint which either
> the CA or the subscriber feels is absolutely crucial for her protection.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 1 Apr 1998 20:12
Picon
Picon
Picon
Favicon

Re: Questions about PKCS #10 and cert extensions

Moshe Litvin <moshe <at> CHECKPOINT.COM> writes:

>Unless explicitly specified an application must process any extension it
>understands regardless of the criticality flag.

This isn't expressed very clearly in the current PKIX text.  What it says
(section 4.2) is that "CA's are required to support <various constraint
extensions>", but the degree of support is left open, and this only covers what
CA's can do.  The following paragraph says that implementations "shall
recognise extensions", and the X.509v3 draft says (in various places) that the
extensions are advisory only.  In either case it implies that you can recognise
whatever you like, but there's no requirement to act on it.  It would help if
the degree of "support" for an extension were made explicit in the text, ie
explicitly state that conformant implementations must enforce any constraint
extensions which are present, and perhaps point out that this differs markedly
from X.509v3 in which the requirement to enforce the constraint is absent.

I can see that this is going to take a long writeup in the style guide to cover
the intricacies of extension handling and straight X.509v3 vs PKIX.

>Consider a basicConstraint extension with ca=TRUE and no pathLenConstraint.
>This extension means no constraints at all. The ONLY effect of marking it as
>critical is to stop applications that don't recognize that extension from
>processing the certificate, and since that particular extension represent no
>constraint - why on earth would you want that ??

Presumably a ca=TRUE basicConstraint will be accompanied by a
keyUsage=keyCertSign | crlSign constraint (I would hope that a CA's cert
signing key isn't goint to be used for, say, key exchange purposes).  If you
follow the X.509v3 text, you're free to ignore this and use it for key
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Gutmann | 2 Apr 1998 08:18
Picon
Picon
Picon
Favicon

Re: Questions about PKCS #10 and cert extensions

After getting a number of responses to my comments on cert extension handling,
and finding that for n respondents there are about n+3 interpretations of how
extensions should be handled, I've updated the style guide to include the
following on cert extensions.  As usual, I'd welcome comments on this.

Peter.

Extensions
----------

Extensions ::= SEQUENCE OF Extension

Extension ::= SEQUENCE {
    extnid                  OBJECT IDENTIFIER,
    critical                BOOLEAN DEFAULT FALSE,
    extnValue               OCTETSTRING
    }

X.509 certificate extensions are like a LISP property list: an
ISO-standardised place to store crufties.  Extensions can consist of key and
policy information, certificate subject and issuer attributes, certificate
path constraints, CRL distribution points, and private extensions.

X.509 Amendment 1 of 30 June 1996 and the X.509v3 draft of June 1997 contains
the ASN.1 formats for the standard V3 Certificate, V2 CRL and V2 CRLEntry
extensions.  In theory you should be able to handle all of these, but there
are large numbers of them and some may not be in active use, or may be
meaningless in some contexts.

                    'It's called a shovel,' said the Senior Wrangler.  'I've
(Continue reading)

Permalink | Reply | 0 comments |
headers
Moshe Litvin | 2 Apr 1998 08:32
Picon
Favicon

Re: Questions about PKCS #10 and cert extensions

Peter Gutmann wrote:
>
> Moshe Litvin <moshe <at> CHECKPOINT.COM> writes:
>
> >Unless explicitly specified an application must process any extension it
> >understands regardless of the criticality flag.
>
> This isn't expressed very clearly in the current PKIX text.

Indeed.

>  What it says
> (section 4.2) is that "CA's are required to support <various constraint
> extensions>",

It is not all that it says.When section 4.2 defines the critical flag al
l it says two things about it:

1. A certificate using system (an application
   validating a certificate) must reject the certificate if it
   encounters a critical extension it does not recognize.
2 A non-critical extension may be ignored if it is not recognized.

(the numbering is not from the draft).

Both sentences apply to application that do not recognize an extension,
I havn't seen in PKIX permision for an application to disregard a known
extension just because it is marked not-critical.

> The X.509v3 draft says (in various places) that the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Jueneman | 2 Apr 1998 17:19
Picon
Favicon

Critical flag processing (was: Re: RE: Signed Label )

Russ,

I just recently joined this list, and I am not at all up to speed with the context, but
I believe that throwing out all Critical attributes, either in certificates or
elsewhere, would be like throwing the baby out with the bath water.

My view of the Critical flag is that it important to protect the interests of the CA
or the signer of a message, or both, against unwarranted assumptions of
validity made on the basis of software which does not implement some
particular attribute. (Since NONE of the ietf standards in this area have done
a very good job of defining minimally, average, and fully compliant suites of
functions, implementors who cannot swallow everything whole all at once
are forced to pick and choose features without much guidance. And
unfortunately, the one or two ubiquitous browsers end up setting de facto
standards.  Hopefully now that Netscape has released their source code
into the public domain, some of these incompatibility issues can be
resolved more quickly.)

In particular, the various constraints, together with the CPS and user notice fields,
serve a very important purpose -- they are the equivalent of a legal notice or
caveat -- sort of a Miranda warning to the relying party.

In addition to the 'standard' attributes (which are confusing and sometimes
fluid enough), there is also the issue of propritetary attributes which may be
defined by some organization, and may or may not ever be well accepted
by the general vendor population. Without the Critical flag, a user who
believes that some attribute was particuarly important has no legal defense
against a relying party whose software ignores that attribute.

Take a Reliance Limit, of example.  I don't intend to get into a debate as to
(Continue reading)

Permalink | Reply | 501 comments |
headers
Gatto_Giorgio | 2 Apr 1998 20:29
Picon

Suspended Certificate in CRL

>From IPKI documents (draft-ietf-pkix-ipki3cmp-05.txt), I can't figure
out how suspension and subsequent reactivation of a certificate shall be
managed in a CRL.

I understand that certificate extensions
(draft-ietf-pkix-ipki-part1-06.txt par. 5.3.2) can dictate how a
suspended certificate shall be handled  by a relying party.   

Furthermore, draft-ietf-pkix-ipki-part4-02.txt par.4.4.4 mentions
certificate suspension among operational requirements to be addressed by
a policy or CPS:
 ...
 * Circumstances under which a certificate may be suspended;
 * Who can request the suspension of a certificate;
 * Procedures to request certificate suspension;
 * How long the suspension may last;
  ...

My questions are:
a) shall a certificate be removed from a CRL when its suspension period
expires or after its reactivation?
b) why hasn't made provision for a reactivation message?

Thanks,
G.
----------------------------------------------
Giorgio Gatto
Finsiel S.p.A.
Via Matteucci 34b
56126 Pisa (Italy)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Gutmann | 3 Apr 1998 01:33
Picon
Picon
Picon
Favicon

Tagging problems

One of the responses I got to my posting yesterday about extensions was a
question about tagging.  The following text is what's currently in the guide
about this subject, I hope this is accurate (the more you look at the tagging
which is used, the more confusing it gets.  Is the Appendix A definition
actually digestible by an ASN.1 parser, and does it produce valid certificate
encodings?).  Anyway, if there are errors in this please let me know, it's
rather difficult to follow the tagging:

-- Snip --

The default tagging for certificates varies depending on which standard you're
using.  The original X.509v3 definition uses the ASN.1 default of explicit
tags.  The PKIX definition is quite confusing because the ASN.1 definitions in
the appendices use TAGS IMPLICIT but mix in X.509v3 definitions which use
explicit tags.  Appendix A has such a mixture of implied implicit and implied
explicit tags that it's not really possible to tell what tagging you're
supposed to use.  Appendix B (which first appeared in draft 7, March 1998) is
better in that it starts with TAGS IMPLICIT, but switches to TAGS EXPLICIT
after the first few definitions (this isn't very obvious, the TBSCertificate
has an 'EXPLICIT' keyword in the definition which means that everything in it
has explicit tagging).  The definitions given in the body of the document use
explicit tags, and the definitions of TBSCertificate and and TBSCertList have
both EXPLICIT and IMPLICIT tags present.  To resolve this, you can either rely
entirely on Appendix B with the 'IMPLICIT TAGS' at the start either removed or
changed to 'EXPLICIT TAGS' (this doesn't change the encoding because nothing in
the section covered by implicit tagging is actually tagged) or use the X.509v3
definitions.  The SET definitions consistently use implicit tags.

-- Snip --
(Continue reading)

Permalink | Reply | 1 comment |
headers
Trevor Freeman | 3 Apr 1998 08:47
Picon
Favicon

Babelfish and names

The prospect of Babelfish technology being available to chain building
software so that it could understand the five ways Vogon's have of writing
the same name is a nonsense. And if it where available it probably would be
imminently patented. I therefore have two suggestion to make, one mildly
radical, the other heresy.
Suggestion one.
If we stop thinking of the subject name as one which a user may understand,
we could easily embody the concept of an internal system name using a single
namespace that the certificate chain building software universally
understands, and an external display name with n namespaces in a certificate
which the user understands. The internal name would be the one used in chain
building by the software, the display name would only be used when
displaying a representation of the certificate to the user.
How do we do that?
Simple.
Mandate that the subject and issuer name be present and in English. That the
subject and issuer alternate names be present and are the default display
name of choice by certificate interpreting UI software and can be in any
language. Now anyone who understands English, just happens to understand the
system namespace but that is coincidence. Vogons would fine the subject DN a
mystery, but would understand the display name(altSubjectName). As long as
the certificate UI software always understands English, you will always be
able to display something about the certificate. If I happen to have the
Vogon version  installed, then I would get the Vogon name. We can define how
we represent the internal and display names in the directory in the LDAP
schema.
Suggestion two
If I have made the split of internal names and display names - why have
English(or any language) in the internal names at all? Software would work
just as well using DN comprising on decimal integers or OID's. e.g. c=US,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane