Subject: Re: [pkix] Certification path

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 1 Aug 2011 14:24:27 -0700

On Jul 20, 2011, at 2:02 AM, Kyle Hamilton wrote:

>> I think that there should be a mandatory to support TA format for PKIX,
>> and that should be X.509.
> 
> There are additional ways that trust anchors can be encoded, such as OpenPGP.  I'm also wary of MUST-encoding policies into technical standards, as I suggest above.
> 
> You can't know what the next generation of protocol improvements is going to entail, and after 3 or 4 iterations still being required to support the legacy X.509 format when there were alternative, preferable ways of encoding the same information in common use.  (also, there's the concept of "how much and for what do we have to trust the CA?"  I think it's 'authoritative identity'.)

I was going to ask if there were any reason *NOT* to encode a TA in an X.509 cert.  I guess this is one answer to the question.

However I don't find it a convincing one.  If the primary goal of interoperability is to be achieved, then I think *some* mandatory-to-implement format for a TA is needed.  If it means supporting a deprecated format long after a better alternative is available, well, everyone else has to deal with that too.  Why should PKIX be exempt from the pain of success?
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 1 Aug 2011 20:25:06 -0700 (Pacific Daylight Time)

> I was going to ask if there were any reason *NOT* to encode a TA in an X.509 cert.  I guess this is one answer to the question.

Is there any reason *TO* mandate that conforming implementations accept an X.509-formatted trust anchor?

> However I don't find it a convincing one.  If the primary goal of interoperability is to be achieved, then I think *some* mandatory-to-implement format for a TA is needed.  If it means supporting a…

I don't find any convincing arguments to do so, particularly as it mandates additional coding -- that is, expense to private industry -- at the suggestion of US federal government.

Said government not-so-coincidentally also thinks that it has an interest in preventing private and confidential communications that it can't read (c.f. the Clipper chip and Skipjack).

As for "why should PKIX be exempt from the pain of success?", I suggest that perhaps we can actually learn from the mistakes of the past and not fall into the same pitfalls.

There is already no way to support every MUST in every PKIX protocol without breaking some piece of the gearing.  There already exist needs which are not met by PKIX protocols -- the perennial example is that we need "this certificate was issued and is not revoked", not "we never revoked this certificate (possibly because we never issued it)".  The more MUSTs in a standard that are ignored by implementations (for good reasons!), the less standardized the standard actually is.

I expect that implementations will implement X.509 trust anchors when, where, and how they are appropriate for the implementation, and I expect that they will drop support when and if it's no longer useful.  PKIX has already altered the unalterable, changed the immutable, altered the semantics of OIDs which were already specified, and forced us into unsustainable and utterly useless paradigms by mandating policy in technical standards.

Policy-based MUSTs in PKIX's technical standards, informed by the statist viewpoint of "this is simply how things are", have inhibited or completely prevented the adoption *and evolution* of security technologies that are useful to the largest segment of Internet users: the private individual.  I've found enough reasons to ignore policy-based MUSTs as a matter of principle.

There exist good reasons why ARPA/DARPA, the US government as a whole, and the ITU-T don't have control over the Internet standards processes, and one of them is this kind of closed-minded "good idea to mandate" that turns around to bite us all.

For more information on this, and additional thoughts on why the state of PKI is so messed up, I direct you to https://kyanha.net/wordpress/?p=83 .

-Kyle H

---

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Aug 2011 16:04:46 -0400

At 2:24 PM -0700 8/1/11, Henry B. Hotz wrote:
>>  There are additional ways that trust anchors can be encoded, such 
>>as OpenPGP.  I'm also wary of MUST-encoding policies into technical 
>>standards, as I suggest above.
>>
>>  You can't know what the next generation of protocol improvements 
>>is going to entail, and after 3 or 4 iterations still being 
>>required to support the legacy X.509 format when there were 
>>alternative, preferable ways of encoding the same information in 
>>common use.  (also, there's the concept of "how much and for what 
>>do we have to trust the CA?"  I think it's 'authoritative 
>>identity'.)
>
>I was going to ask if there were any reason *NOT* to encode a TA in 
>an X.509 cert.  I guess this is one answer to the question.
>
>However I don't find it a convincing one.  If the primary goal of 
>interoperability is to be achieved, then I think *some* 
>mandatory-to-implement format for a TA is needed.  If it means 
>supporting a deprecated format long after a better alternative is 
>available, well, everyone else has to deal with that too.  Why 
>should PKIX be exempt from the pain of success?

Henry,

We also do not have a mandatory to implement set of algorithms, and that
is intentional. Absent a universal alg suite mandate, there is no
need for a mandated TA format either, as the second would not guarantee
interoperability without the first.

Steve

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 2 Aug 2011 14:54:38 -0700

On Aug 2, 2011, at 1:04 PM, Stephen Kent wrote:

> is intentional.

I have to say that sounds really weird to me.  It means that you're writing spec's which are deliberately insufficient to guarantee interoperability.  I thought interoperability was the whole point of the IETF.

Pragmatically, there must be some small set of algorithms which are mandatory to implement in the real world or PKIX and TLS wouldn't work.  If we abdicate responsibility for documenting what those are, then we also abdicate authority for coordinating improvements, do we not?

> Absent a universal alg suite mandate, there is no

No argument in general, but one could (and probably should) write a TA spec which delegates the algorithm suite to other, more appropriate spec's.

---

From: Russ Housley <[email-masked]>
Date: Tue, 2 Aug 2011 18:02:50 -0400

> I have to say that sounds really weird to me.  It means that you're writing spec's which are deliberately insufficient to guarantee interoperability.  I thought interoperability was the whole point…

PKIX is used in other applications, and those applications sate the mandatory to implement.  Consider S/MIME as one example.  This approach allows the same signature algorithm to be mandatory for the message signature and the certificate signature.

Russ

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Aug 2011 00:09:30 +0200 (MEST)

> interoperability without the first.

Such a rationale for a lack of mandatory to implement trust anchor
format scores "lame" on my personal scorecard.

PKIX has a mandatory certificate (X.509), so it is far from unusal
to mandate that this format is supported for trust anchors as well.

(keep in mind that mandatory to implement is not the same as mandatory
 to use for the consumers of the technology).

The algorithms issue is a whole different can of worms.
... but actuallly recommending what algorithms might be sensible
to support for obtaining interop with the majority of installed base
would not hurt, either -- even if the "mandatory to implement"
part is skipped.

The current defacto interoperable algorithms are

   rsaEncryption          { 1, 2, 840, 113549, 1, 1, 1 }
   sha1                   { 1, 3, 14, 3, 2, 26 }
   sha1WithRsaEncryption  { 1, 2, 840, 113549, 1, 1, 5 }

and it would probably be sensible to also include

   sha256                    { 2,16,840,1,101,3,4,2,1 }
   sha256WithRsaencryption   { 1, 2, 840, 113549, 1, 1, 11 }

in all newly shipped products and product updates & fixes

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 15:12:22 -0700

> format scores "lame" on my personal scorecard.

And your -00 draft of such a document is where? :-) Seriously, though, it sounds like some people want this, and it could be useful to have a specific target to discuss.

--Paul Hoffman

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 2 Aug 2011 17:02:22 -0700

So it's intentional in order to allow (for example) m-t-i for S/MIME to be different from m-t-i for TLS?  That's at least potentially reasonable.  

But what if I want to deploy client certs that are good for both S/MIME and TLS?  Is that an intentionally unsupported use case?  I'll grant that the world is a complex place and there are a lot of different things in it.  A cert identifying a phone must have different requirements from one identifying a person from one identifying a service.  The supportable applications for those are also different.

However I think there is still an interoperability argument.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 2 Aug 2011 17:44:59 -0700

> in all newly shipped products and product updates & fixes

I'm in no position to help, but I think a BCP which specifies rsaEncryption, sha256, and sha256WithRsaencryption as m-t-i for PKIX would be a good thing.  Add some weasel-words allowing applications to further specify if they have reason.

Absent PKIX guidance, are there some saag doc's which kick in?  I'm guessing not, but have to ask.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 3 Aug 2011 09:32:16 -0400

> However I think there is still an interoperability argument.

Stop that!  Thinking like an Enterprise Architect is verboten!  (Plus it will get you nothing but high blood pressure and thinning hair.  :)

-- T

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Aug 2011 13:16:23 -0400

At 2:54 PM -0700 8/2/11, Henry B. Hotz wrote:
>O...
>I have to say that sounds really weird to me.  It means that you're 
>writing spec's which are deliberately insufficient to guarantee 
>interoperability.  I thought interoperability was the whole point of 
>the IETF.

PKIX defines PKI specs for a very wide range of apps, which is why we
do not mandate any alg suite.  Different apps may use different alg suites.
TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for itself.

>Pragmatically, there must be some small set of algorithms which are 
>mandatory to implement in the real world or PKIX and TLS wouldn't 
>work.  If we abdicate responsibility for documenting what those are, 
>then we also abdicate authority for coordinating improvements, do we 
>not?

Note that you cited one, of many, security protocols above.  That's the catch,
i.e., each app gets to make these decisions.

>No argument in general, but one could (and probably should) write a 
>TA spec which delegates the algorithm suite to other, more 
>appropriate spec's.
>

We have a TA format spec: RFC 5914.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Aug 2011 13:12:42 -0400

...
>to mandate that this format is supported for trust anchors as well.

not very high on my scorecord :-).

>  to use for the consumers of the technology).

I've been involved with te development of Internet standards since 
before the IETF was created, so I have a pretty good grasp of that 
subtle difference.

>would not hurt, either -- even if the "mandatory to implement"

no.

Steve

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 3 Aug 2011 14:40:59 -0400

> i.e., each app gets to make these decisions.

Let's be clear:  Each standard, protocol, or implementation importing PKIX definitions makes these decisions in part because PKIX intentionally does not.  

This choice can be made differently.  Whether other WGs would follow such a change is still their decision, but the guidance could be helpful to implementors if no-one else.

-- T

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Aug 2011 14:47:33 -0400

At 2:40 PM -0400 8/3/11, Miller, Timothy J. wrote:
>Let's be clear:  Each standard, protocol, or implementation 
>importing PKIX definitions makes these decisions in part because 
>PKIX intentionally does not.

true, but we intentionally do not because we believe that no single 
alg suite fits all. The same is true for EKUs.

>This choice can be made differently.  Whether other WGs would follow 
>such a change is still their decision, but the guidance could be 
>helpful to implementors if no-one else.

If you ask prior Sec ADs, several of whom were very active PKIX members
(including one co-chair), I think you'll find that they endorse this
separation of protocol specs vs. mandatory to implement alg suites.

Steve

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Aug 2011 21:15:03 +0200 (MEST)

> We have a TA format spec: RFC 5914.

But that is about as lame as TLSv1.0 mandating the DH-DSS cipher suite
(fixed in TLSv1.1), i.e. completely ignoring the installed base.

-Martin

---

From: Carl Wallace <[email-masked]>
Date: Wed, 03 Aug 2011 15:18:22 -0400

>(fixed in TLSv1.1), i.e. completely ignoring the installed base.

The default untagged trust anchor option is a certificate.  How is that
ignoring the installed base?

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Aug 2011 21:58:18 +0200 (MEST)

Stephen Kent wrote:
> Henry B. Hotz wrote:

You probably know pretty well that there is a significant difference
between the alg suites used by specific protocols such as TLS, S/Mime,
IPsec, etc.  and the alg suites used by the certificate path validation
algorithm described in Section 6.1 of RFC-5280.

Normally, these algorithms should be cleanly seperated in order to
minimized negative consequences and allow code modularization and
independent maintenance of the stuff that performs certificate path
validation according to PKIX and the stuff that runs protocols such
as TLS, S/Mime, IPsec, etc.

You might be aware that Microsoft updated the Crypto-API components
of Windows XP to allow sha256WithRsaEncryption for X.509 certificates,
but that does not automatically imply that sha256 is available for
S/Mime in Outlook, for TLS in SChannel or for IPsec on this platform.
Similarly, there is a Hotfix available to make AES available for
TLS/SChannel SSP on Windows2003, but that does _not_ add AES enctypes
to Kerberos SSP.

There is, however one fallacy of RFC on the standards track
(rfc5246, TLSv1.2) with the flawed concept of requiring a cryptographic
algorithm being registered with TLS and assigned a TLS-specific algorithm
code point, before it can be used with TLSv1.2 in the X.509 certificate
path validation of the underlying PKI software.  There is no
such restriction in previous of TLS (v1.0,v1.1) where things work
just fine, and is one of the reasons why 99.9% of the world is still
happily using TLSv1.0&TLSv1.1 3 years later.

There is no problem with recommending (and in some cases mandating)
algorithms for the pupose of interop, but unnecessarily imposing
algorithm dependencies across independent technologies seems like
a very bad idea.

And mandating certain data formats, such as support for X.509 for
trust anchors in PKIX, would be quite sensible, significantly
improve interop and be generally useful.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Aug 2011 22:19:47 +0200 (MEST)

Carl Wallace wrote:
> Martin Rex wrote:

That is a funny way to describe the situation.

I do not see anything like a default, the TrustAnchorChoice
and the accompanying text describes this as three equal options,
and the tags are to make that thing parsable to the ASN.1 decoder.

The tbsCert represents problem number one, and the TrustAnchorInfo
not being able to carry along a regular X.509 certificate is
an even worse problem of that specification.

While you can convert  TBSCertificate <-> TrustAnchorInfo,
converting Certificate -> TBSCertificate and converting
Certificate -> TrustAnchorInfo are clear "one way / no return" routes.
And that is why I consider 5914 broken and generally harmful.

-Martin

---

From: Carl Wallace <[email-masked]>
Date: Wed, 03 Aug 2011 16:42:56 -0400

>and the tags are to make that thing parsable to the ASN.1 decoder.

Default was a poorly chosen word.  The point is that the untagged option
is a certificate, which can be parsed by the installed base.  All
certificates are valid TrustAnchorChoice objects.  The structure was
defined this was specifically because of the installed base.

>an even worse problem of that specification.

Why is the tbsCert option a problem?  It was added at the request of
working group members who wanted to add constraints while reusing existing
parsing logic.  

The TrustAnchorInfo structure can wrap a certificate, in the
TrustAnchorInfo.certPath.certificate field.  Generally, this structure is
a form of "X.509 plus X", which you cited several times but never defined
earlier in this thread.

>And that is why I consider 5914 broken and generally harmful.

If you want to preserve the certificate, wrap it inside a TrustAnchorInfo
don't convert it.  Why is that harmful?  The whole point is to enable the
relying party to express and enforce some constraints.  You can't do that
without making some form of a change.  This spec provides two ways to add
constraints.  Simply issuing a certificate from a TA you control is
another available option.  Including constraints in a self-signed cert is
another way.  What are you looking for that cannot be satisfied with these
options?

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 3 Aug 2011 16:45:29 -0400

> S/Mime in Outlook, for TLS in SChannel or for IPsec on this platform.

Which MS, nevertheless, set as the default for Outlook 2010.  Just sayin'.  :)

-- T

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Aug 2011 01:05:57 +0200 (MEST)

> working group members who wanted to add constraints while reusing existing

I think it is bad because you can not produce a (valid self-signed)
X.509 cert from just a tbsCert -- but it is easy and straightforward
to extract a tbsCert from an X.509 cert in case that may be necessary
for a specific temporary purpose.

> a form of "X.509 plus X", which you cited several times but never defined

Admittedly, I had not noticed that carefully buried certificate in that
struct.  The certificate element in that structure, however, is tagged
as "OPTIONAL" in ASN.1, so that this is nothing like "X.509 plus X",
it is acutally just "X" (and optionally, if you are very lucky and all
planets line up in a row, there may be a certificate present).

I know that there is still software around which stores trust anchors
as only tbsCert.  But most of that software should support adding
new trust anchors distributed as X.509 (by extracting and persisting
only the tbsCert part from the outer ASN.1 sequence).

The thing that I believe should be banished entirely is the distribution
of trust anchors with _less_ than X.509.  And 5914 fails that.

> don't convert it.  Why is that harmful?

It is harmful to recommend distribution of TrustAnchor information that
is less-than-X.509.  And it was entirely unnecessary.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Aug 2011 01:30:09 +0200 (MEST)

> planets line up in a row, there may be a certificate present).

more precisely, in rfc5914,

  certificate is an OPTIONAL member of CertPathControls,
  which itself is an OPTIONAL member of TrustAnchorInfo.

That is an "Beware of the leopard" approach to deprecate rather
that promote "X.509 plus X" trust anchors.

-Martin

---

From: Carl Wallace <[email-masked]>
Date: Wed, 03 Aug 2011 20:15:02 -0400

>that promote "X.509 plus X" trust anchors.

The TrustAnchorInfo structure serves two purposes, minimal representation
and wrapping constraints around a certificate.  That one purpose does not
require a certificate is not an attempt to deprecate the usage of
certificates.      

On 8/3/11 7:05 PM, "Martin Rex" <[email-masked]> wrote:
<snip>
>for a specific temporary purpose.

Simply cracking out the tbsCert is not a goal.  Enabling the
representation of constraints is a goal.  The signature on the (probably
self-signed) cert is an obstacle.  The spec offers two ways around the
obstacle to achieve this goal: remove the signature and wrap the entire
structure.  

<snip>
>only the tbsCert part from the outer ASN.1 sequence).

I am confident this structure can be used without planetary alignment and
to represent "X.509 plus X".

>of trust anchors with _less_ than X.509.  And 5914 fails that.

5280 requires presentation of a trust anchor name and key as input for
path validation.  The spec aims to align with this minimal representation.

>is less-than-X.509.  And it was entirely unnecessary.

There is no harm in representing a TA as a name and a key, or tbsCert.
Whether or not these structures are an unnecessary components of the spec
is a matter of opinion.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 3 Aug 2011 19:31:06 -0700

> to represent "X.509 plus X".

I think that misses Martin's point.

------

More generally, what I'm getting from this discussion is that the RFCs do in fact allow you to do sensible things, but they fail to provide useful guidance as to what things are sensible in areas where I (for one, anyway) would expect.

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 4 Aug 2011 11:57:08 +0200

Hi,

It seems to me that the PKIX community has some problems in getting to an
agreement whether tbscerts and other non-certs are beneficial for the
community or not. I have made some suggestion for updating X.509 that takes
RFC 5914 into account. We will discuss that at our coming Geneva meeting.
The discussion here on this list may introduce some changes to that
proposal. 

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
http://dk.linkedin.com/in/andersenerik

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af Martin
Rex
Sendt: 4. august 2011 01:06
Til: Carl Wallace
Cc: [email-masked]; [email-masked]
Emne: Re: [pkix] Certification path

-Martin
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 4 Aug 2011 13:10:51 +0200

OK - I am a little confused.

We have definition of a certification path to be: An ordered list of
public-key certificates starting with the public-key certificate to be
validated, optionally followed by an ordered list of CA certificates, the
last one being signed by a trust anchor.

However, if it is important to add restrictions to trust anchor information,
it appears to me that the trust anchor should be part of the certification
path. This a little in conflict with the ASN.1 definition of a certification
path. The ASN.1 could be amended to take trust anchor information into
account.

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af Henry
B. Hotz
Sendt: 4. august 2011 04:31
Til: Carl Wallace
Cc: [email-masked]
Emne: Re: [pkix] Certification path

------

More generally, what I'm getting from this discussion is that the RFCs do in
fact allow you to do sensible things, but they fail to provide useful
guidance as to what things are sensible in areas where I (for one, anyway)
would expect.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Carl Wallace <[email-masked]>
Date: Thu, 04 Aug 2011 07:20:39 -0400

>path. The ASN.1 could be amended to take trust anchor information into

The trust anchor resides in the relying parties environment and need not
be encoded in a certification path that is transmitted with a message.  TA
constraints are similar to the inputs to the path validation algorithm.

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 4 Aug 2011 14:29:22 +0200

Hi Carl,

Thanks for the clarification. So, the trust anchor information is not part
of the certification path, but the trust anchor information still has to be
considered by the validation procedure. 

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

---

From: [email-masked]
Date: Tue, 9 Aug 2011 10:24:37 +0200

A few comments about this thread.

1) Since a certification path, as currently defined, does not include the 
trust anchor, 
it would be useful to define and name a new ASN.1 construct which would 
allow 
to incorporate the trust anchor. 

A strawman proposal for the name would be: "certification chain".

A strawman proposal for the format would be  :

CertificationChain  ::= SEQUENCE OF Certificate 

but this does not say whether the path is forward or backwards. Since 
X.509 defines:

CertificationPath    ::= SEQUENCE { 
  userCertificate        Certificate, 
  theCACertificates      SEQUENCE OF CertificatePair OPTIONAL } 

An alternative  strawman proposal for the format would be  :

CertificationChain    ::= SEQUENCE { 
  certificationPath      CertificationPath, 
  trustAnchor                    Certificate }

The certificate of the trust anchor would be either a self-signed CA 
certificate or an intermediate CA certificate.

Once (or if) there would be some consensus  on some approach, then it 
would be worthwhile to draft a proposal.

2) It is good to maintain the separation of data formats from algorithms: 
data formats last longer than algorithms.

Denis

De :    Paul Hoffman <[email-masked]>
A :     [email-masked]
Cc :    PKIX <[email-masked]>
Date :  03/08/2011 00:12
Objet : Re: [pkix] Certification pathx
Envoyé par :    [email-masked]

> format scores "lame" on my personal scorecard.

And your -00 draft of such a document is where? :-) 
Seriously, though, it sounds like some people want this, and it could be 
useful to have a specific target to discuss.

--Paul Hoffman

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 9 Aug 2011 10:43:13 +0200

Hi Denis,

I like your proposal, but you seem to ignore RFC 5914. Is that intentional?

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: [email-masked]

Skype: andersen-erik

 <http://www.x500.eu/> http://www.x500.eu/

 <http://www.x500standard.com/> http://www.x500standard.com/

 <http://dk.linkedin.com/in/andersenerik>
http://dk.linkedin.com/in/andersenerik

Fra: [email-masked] [mailto:[email-masked]] På vegne af
[email-masked]
Sendt: 9. august 2011 10:25
Til: PKIX
Emne: Re: [pkix] Certification pathx

but this does not say whether the path is forward or backwards. Since X.509
defines: 

Once (or if) there would be some consensus  on some approach, then it would
be worthwhile to draft a proposal. 

Denis 

  _____  

--Paul Hoffman

_______________________________________________
pkix mailing list
[email-masked]
 <https://www.ietf.org/mailman/listinfo/pkix>
https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked]
Date: Tue, 9 Aug 2011 11:24:04 +0200

Hi Erik,

It's good to know that you like the proposal.

I am well aware of RFC 5914 and at several times I have mentioned on the 
PKIX list 
why the content of this document was not (IMO) adequate. This is why I 
have not proposed 
to import any data structure defined in RFC 5914.

Denis

De :    "Erik Andersen" <[email-masked]>
A :     "PKIX" <[email-masked]>
Date :  09/08/2011 10:43
Objet : Re: [pkix] Certification pathx
Envoyé par :    [email-masked]

Hi Denis,
 
I like your proposal, but you seem to ignore RFC 5914. Is that 
intentional?
 
Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

Denis 

--Paul Hoffman

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 9 Aug 2011 12:52:44 +0200

Hi Denis,

You are not the only one express concern with RFC 5914. I wonder whether it
should be mentioned in X.509 at all. We will take that discussion up in
Geneva.

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: [email-masked]

Skype: andersen-erik

Fra: [email-masked] [mailto:[email-masked]] På vegne af
[email-masked]
Sendt: 9. august 2011 11:24
Til: PKIX
Emne: Re: [pkix] Certification pathx

Hi Erik, 

I am well aware of RFC 5914 and at several times I have mentioned on the
PKIX list 
why the content of this document was not (IMO) adequate. This is why I have
not proposed 
to import any data structure defined in RFC 5914. 

Denis 

  _____  

Hi Denis, 

Erik Andersen 
Andersen's L-Service 
Elsevej 48, 
DK-3500 Vaerloese 
Denmark 
Mobile: +45 2097 1490 
e-amail: [email-masked] 
Skype: andersen-erik 
  
Fra: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]] På vegne af [email-masked]
Sendt: 9. august 2011 10:25
Til: PKIX
Emne: Re: [pkix] Certification pathx 

Denis 

  _____  

--Paul Hoffman

_______________________________________________
pkix mailing list
[email-masked]
 <https://www.ietf.org/mailman/listinfo/pkix>
https://www.ietf.org/mailman/listinfo/pkix__________________________________
_____________
pkix mailing list
[email-masked]
 <https://www.ietf.org/mailman/listinfo/pkix>
https://www.ietf.org/mailman/listinfo/pkix

---

From: Martin Rex <[email-masked]>
Date: Tue, 9 Aug 2011 16:17:45 +0200 (MEST)

[email-masked] wrote:
>    trust anchor, it would be useful to define and name a new ASN.1
>    construct which would allow to incorporate the trust anchor. 
> 

There is a newer definition:  X509PKIPathv1
-- which is described in X.509 Defect Report 279 and is already used by
the Web Service Security -- Security Token Profile.

e.g. http://ftp.sunet.se/pub/security/dfnpca/docs/X509/DefectResolution/DefectReports/X.509andRelated/DR_279Rev1.pdf

  a) In clause 7, add the following immediately after the
     ASN.1 CrossCertificates production:

         PkiPath ::= SEQUENCE OF Certificate

     PkiPath is used to represent a certification path. Within the sequence,
     the order of certificates is such that the subject of the first
     certificate is the issuer of the second certificate, etc.

-Martin

---

From: [email-masked]
Date: Tue, 9 Aug 2011 16:27:31 +0200

Martin,

PkiPath does not solve the concern, since the text states: 
pkiPath is used to represent a certification path
The use of the wording "certification path"  mandates 
that the certificate of the trust anchor is NOT included.

Here we are looking for a structure which includes it.

Denis

De :    Martin Rex <[email-masked]>
A :     [email-masked]
Cc :    [email-masked]
Date :  09/08/2011 16:17
Objet : Re: [pkix] Certification pathx

e.g. 
http://ftp.sunet.se/pub/security/dfnpca/docs/X509/DefectResolution/DefectReports/X.509andRelated/DR_279Rev1.pdf

     PkiPath is used to represent a certification path. Within the 
sequence,
     the order of certificates is such that the subject of the first
     certificate is the issuer of the second certificate, etc.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 9 Aug 2011 16:40:58 +0200 (MEST)

> that the certificate of the trust anchor is NOT included.

Primarily I want to completely avoid the CertificatePair nonsense.

I don't have access to the X.509 spec itself, but the Defect Report
itself does _not_ contain words to the effect that a TA cert is not
allowed as the first certificate in the path.

Which of the missing parts of X.509 explicitly requires that there must
not be a self-signed certificate included as the first cert in PkiPath?

> Here we are looking for a structure which includes it.

You could still compose a sequence from X509PKIPathv1 plus a TA cert.

-Martin

---

From: "Erik Andersen" <[email-masked]>
Date: Wed, 10 Aug 2011 09:45:48 +0200

Hi Martin,

As to your question about self-signed certificate. I do not see that
restriction in X.509. However, a to-be-signed certificate cannot be included
using the current definition. Neither can the structure defined in RFC 5914.

One problem with PkiPath is that it points in the opposite direction than
our current definition (down vs. up).

I also have a problem with CertificatePair. If not coded correctly, the path
could be broken.

X.509 may be freely downloaded
(http://www.itu.int/rec/T-REC-X.509-200811-I/en).

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af Martin
Rex
Sendt: 9. august 2011 16:41
Til: [email-masked]
Cc: [email-masked]
Emne: Re: [pkix] Certification pathx

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Aug 2011 12:09:45 -0400

At 9:45 AM +0200 8/10/11, Erik Andersen wrote:
>restriction in X.509.

no, but a cert path is processed relative to the cert path validation alg,
and that alg starts at a TA.

Steve

---

From: Martin Rex <[email-masked]>
Date: Wed, 10 Aug 2011 21:13:08 +0200 (MEST)

> As to your question about self-signed certificate. I do not see that

Great!

>
> However, a to-be-signed certificate cannot be included using the
> current definition. Neither can the structure defined in RFC 5914.

I believe it would be unreasonable to include anything else than
a valid self-signed certificate in the PkiPath.  "TrustAnchor" is
a purely local concept.

When including a self-signed certificate as first element in a PkiPath,
it just makes the path complete while the data is still integrity protected
(and covers the situation where the communication peer might be using
a self-signed X.509 certificate, so that trust can not be derived from
any CAs at all.

Neither the TBSCertificate nor the TrustAnchorInfo data is
integrity protected, so it would be pretty useless to make _that_
data part of pkiPath.  The only sensible information to include
is a self-signed X.509 TA cert -- which for the purpose of pkiPath
is just a cert with integrity-self-protection, not a TrustAnchor.

If the recipient of the pkiPath does not recognize a TrustAnchor
identified by the selfsigned TA cert, there two options to proceed
involving human interaction, either perform an out-of-band
validation, like checking the public key fingerprint of the TA cert
or checking the TA cert certificate fingerprint, or make the TA cert
a valid TrustAnchor in a leap-of-faith (similar to how PGP, SSH and
most software distribution does key bootstrapping).

> our current definition (down vs. up).

While I personally also favor the TLS approach (signer cert first) to the
pkiPath approach, I don't think that should be show-stopper.
Adding another ASN.1 structure (SEQUENCE OF Certificate) with the
opposite direction will probably make things worse.  http://xkcd.com/927/

> (http://www.itu.int/rec/T-REC-X.509-200811-I/en).

Big Thanks for that URL!!

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Aug 2011 15:13:11 -0400

>is less-than-X.509.  And it was entirely unnecessary.

IF RPs were required to make use of the various fields & extensions in a
self-signed cert as constraints in path validation, your assertion might
be appropriate. But, the base X.509 and PKIX standards do not mandate that.
(RFC 5914 addresses this issue and provides a basis for use of such 
data.) Moreover, implementations are quite varied in their support for
making use of these values (in path validation). Thus there is no 
solid basis for arguing that a self-signed cert is the MUST be 
supported TA format.

Steve

---

From: Martin Rex <[email-masked]>
Date: Wed, 10 Aug 2011 21:32:19 +0200 (MEST)

> and that alg starts at a TA.

The description of the path validation algorithm is significantly
and needlessly convoluted in that area, that it ought to be fixed
anyway.

While rfc5280 Section 6.1 says that the path validation starts
with a prospective(!!) certification path, and policy and constraints
processing does not seem to have a problem specifying to skip
self-issued certs on the _prospective_ path, the algorithm as
described in rfc5280 Section 6.1 fails to provide a sensible guidance
how to deal with a TA cert appearing at the beginning of a prospective
certification path.

  http://tools.ietf.org/html/rfc5280#page-73

   To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n
   certificates) satisfies the following conditions:

      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
           the issuer of certificate x+1;

      (b)  certificate 1 is issued by the trust anchor;

      (c)  certificate n is the certificate to be validated (i.e., the
           target certificate); and

      (d)  for all x in {1, ..., n}, the certificate was valid at the
           time in question.

   A certificate MUST NOT appear more than once in a prospective
   certification path.

   When the trust anchor is provided in the form of a self-signed
   certificate, this self-signed certificate is not included as part of
   the prospective certification path.  Information about trust anchors
   is provided as inputs to the certification path validation algorithm

But this flaw _only_ affects the description of the algorithm in rfc5280,
implementations of this algorithm, such as TLS clients, seem to cope with
that situation sensibly do not exhibit a problem.

The words "this self-signed certificate is not included as part of
the prospective certification path" is not only non-sensical, but
also self-contradictory for an algorithm(!!) that is supposed to
describe processing of a prospective(!!!) certification path.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 10 Aug 2011 21:46:12 +0200 (MEST)

> solid basis for arguing that a self-signed cert is the MUST be 

That description is confusing things considerably.

As I just wrote in a previous Email, rfc5280 Section 6.1 describes an
(evendentally incomplete/flawed) algorithm to process a prospective
certification path, and while the processing of policies and constraints
special cases processing of self-issued certificates, the processing
of TA certs that might appear at the beginning of a prospective(!!)
certification path are obviously underspecified (in the document),
although implementations seem to cope with the situation quite well.

Mandating that a trust anchor be distributed as X.509 plus X
(in a trust anchor distribution protocol) is entirely independent
from the processing of any potential TA cert appearing as the first 
certificate of a prospective certification path.  Just as it seemed
useful or necessary to specify skipping of self-issued certs under
certain conditions in policy and constraints processing, it should
be a no-brainer to exempt a TA cert at the beginning of a _prospective_
certification path from processing.

-Martin

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 10 Aug 2011 16:21:38 -0400

Martin,

Are you saying that you believe that the path validation algorithm in 
Section 6 needs to include a statement similar to the one that appears 
in X.509:

     X.509, Clause 10.5.1: The following checks are applied to a 
certificate.
                Self-signed certificates, if encountered in the path, 
are ignored.

     X.509, Clause 10.5.2: For an intermediate certificate, the following
                constraint recording actions are then performed, in order
                correctly to set up the state variables for the 
processing of the
                next certificate. Self-signed certificates, if 
encountered in the
                path, are ignored.

The closest text that seems to appear in RFC 5280 is:

      When the trust anchor is provided in the form of a self-signed
      certificate, this self-signed certificate is not included as part of
      the prospective certification path.

The main difference is really just that RFC 5280 doesn't seem to 
consider the possibility that a self-signed certificate might be 
encountered in the middle of a certification path.  Otherwise, RFC 5280 
obtains the same result as X.509 by imposing a pre-processing 
requirement to ensure that the first certificate in the prospective 
certification path isn't a self-signed certificate.  Is there anything 
wrong with that?  Is it really any different than:

On 08/10/2011 03:46 PM, Martin Rex wrote:
>> IF RPs were required to make use of the various fields&  extensions in a

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 10 Aug 2011 16:24:24 -0400

Dave,

Do you mean self-issued?  Why would you encounter or use a self-signed certificate in a path?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David A. Cooper
Sent: Wednesday, August 10, 2011 4:22 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] Certification path

Martin,

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 10 Aug 2011 16:38:40 -0400

On 08/10/2011 04:24 PM, Santosh Chokhani wrote:
> Do you mean self-issued?

No, I mean self-signed.  The discussion was about TA certificates (which 
I take to mean self-signed certificates) appearing in a prospective 
certification path.

> Why would you encounter or use a self-signed certificate in a path?

You wouldn't use them, which is why X.509 says to ignore them if they 
are encountered in a prospective certification path.  I don't know why 
you'd encounter a self-signed certificate in a path, but Martin's 
objection appears to be that RFC 5280 doesn't say what to do if a 
self-signed certificate appears at the beginning of a prospective 
certification path (it just says that self-signed certificates are not 
to appear at the beginning of a prospective certification path).

> .

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Aug 2011 16:53:04 -0400

>and needlessly convoluted in that area, that it ought to be fixed

Thanks for your suggestion.

>how to deal with a TA cert appearing at the beginning of a prospective

because a TA (which need not be represented by a cert!) does not appear
in the path. That's intentional.

>that situation sensibly do not exhibit a problem.

Many TLS clients do a lot of things that do not comply with 5280 :-), 
so it's odd to use the phrase "... implementations of this algorithm, 
such as TLS clients ..."

>describe processing of a prospective(!!!) certification path.

The alg is intended to describe how to validate a sequence of certs
that is initialized with data from a TA, i.e, cert #1 is issued under 
a TA. So there is nothing nonsensical about the wording.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Aug 2011 16:51:51 -0400

>although implementations seem to cope with the situation quite well.

the alg is not flawed, but your understanding may be :-).
TAs are not part of a cert path; they are initialization data for 
path processing.

Steve

---

From: Martin Rex <[email-masked]>
Date: Wed, 10 Aug 2011 23:56:20 +0200 (MEST)

> to appear at the beginning of a prospective certification path).

(Maybe we're just differing in opinion whether dealing sensibly
 with TA certs appearing at the beginning of a pkiPath should be
 dealt with in "certificate path validation" or require
 a full-fledged "certificate path discovery" (what some TLS implementations
 seem to be doing).

I'm neither happy with either X.509-2008, 10.5.1, first sentence

  The following checks are applied to a certificate.
  Self-signed certificates, if encountered in the path, are ignored

nor with rfc5280 Section 6.1

   (Section 6.1.1).

While X.509-2008 is still specifying an algorithm, rfc5280 is
thoroughly lame.

What both specs should do is deal sensibly with the situation that
a pkiPath (prospective certification path) may have a TA cert at
the beginning, and how to cope sensibly with that situation.

First of all, I fully agree that a certificate from the prospective
certification path is _not_ a "trust anchor" for the purpose of
performing the certificate path validation.  It may, however,
match the trust anchor that is used for the certificate path
validation -- and should it match, it should be *ignored*.

IMHO, the guidance in X.509-2008 10.5.1 to unconditionally
ignore all self-signed certificates _anywhere_ in the prospective
certification path is overly broad and misses the point (about
ignoring a possible TA cert at the beginning of the pkiPath).

rfc5280 is flawed, because it does not specify an algorithm to deal
with such a cert, and it makes the non-algorithem implementations
specific on top, because it applies only when the TrustAnchor (and
that refers to the seperate TrustAnchor input) is provided as
a self-signed certificate -- and the way it is worded, this does
_not_ apply when the implementation passes the TrustAnchor as
ToBeSigned or as TrustAnchorInfo to the certificate path validation
algorithm -- which is why I believe this is lame.

Look at the real world.  These days, most commercial CAs have switched
to distributing TrustAnchors with 2048-bit RSA keys.  But when customers
obtain TLS server certificates as cert chains (PKCS#7), they might
receive a "chain" that instead of the 2048-bit RSA self-signed TA cert
contains instead an intermediate cert containing the trustanchors
Subject and public key, but issued&signed by an old 1024-bit RSA
trust anchor.

Now if you get that in a pkiPath as first cert, it is not a self-signed
TA cert, but it is still a "TA cert", because Subject&Public Key usually
matches the Trust Anchor from a new clients trust anchor store.

And I'd really like to see the "certificate path validation" algorithm
to be clarified rather than this question being declared out-of-scoped
and relegated to the black arts of "certificate path construction".

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 11 Aug 2011 10:25:25 -0700

> and relegated to the black arts of "certificate path construction".

+1

I'm not getting the impression that the pragmatically desired behavior is in question, but the quoted specifications don't seem to describe it.