Subject: [pkix] New Draft about X.509extension with Security Information

From: 刘玉婷 <[email-masked]>
Date: Fri, 15 Oct 2010 18:19:39 +0800

Dear all,

We have submitted a new Internet draft entitled "X.509extension with
Security Information"
It can be accessed at:
http://www.ietf.org/id/draft-chen-pkix-securityinfo-00.txt
Any comments are welcome. Thanks.

Abstract:
This document defines an X.509v3 certificate extension. It binds a list of
security information to the subject of a certificate, which may be used to
cognize the security posture of the subject.

Best Regards,
Yuting Liu

-- 
Best regards,
刘玉婷 Vivi
Phone:13488659413
Email: [email-masked]
MINE | Mobile LIfe and New Media LAB
BUPT | Beijing University of Posts and Telecommunications

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 15 Oct 2010 09:53:11 -0400

(Sorry about the HTML mail, but I can't seem to make OWA bend to my will today.)

2 questions:

1) Why can't attribute certificates fill this need?

2) What was wrong with stuffing this data in the existing Subject Directory Attributes extension?  Why do you need to define a new extension?

-- Tim

________________________________
From: [email-masked] [[email-masked]] On Behalf Of 刘玉婷 [[email-masked]]
Sent: Friday, October 15, 2010 5:19 AM
To: [email-masked]
Subject: [pkix] New Draft about X.509extension with Security Information

Dear all,

We have submitted a new Internet draft entitled "X.509extension with Security Information"
It can be accessed at:
http://www.ietf.org/id/draft-chen-pkix-securityinfo-00.txt
Any comments are welcome. Thanks.

Abstract:
This document defines an X.509v3 certificate extension. It binds a list of security information to the subject of a certificate, which may be used to cognize the security posture of the subject.

Best Regards,
Yuting Liu

--
Best regards,
刘玉婷 Vivi
Phone:13488659413
Email: [email-masked]<mailto:[email-masked]>
MINE | Mobile LIfe and New Media LAB
BUPT | Beijing University of Posts and Telecommunications

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 15 Oct 2010 12:22:34 -0400

Hi all,

I do agree with Tim in that it is usually a bad idea embedding authorization
information in authentication certificates.. so I would totally use some other
form of authenticated source (eg., an attribute certificate, a signed data
blob, etc..).

Another reason why not to embed this information in the user's id cert is
that the "security posture" may change in time (e.g., Antivirus enabled/
disabled/updated, OS updated/changed/downgraded). Also, the security
information you talk about are really difficult to verify.. the liability
could be too strong for a CA.

Another viable approach would be to use Proxy Certificates carrying some
sort of attestation information (e.g., local attestation). Have you
consider this approach ? In this way, the liability would fall on the
subject, not on the CA. If the attestation is correctly performed, the
info in the certificate can be "easily" verified...

my 2 cents..

Cheers,
Max

On 10/15/2010 09:53 AM, Miller, Timothy J. wrote:
> 2) What was wrong with stuffing this data in the existing Subject 
> Directory Attributes extension? Why do you need to define a new extension?

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [email-masked]
                                                 [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

---

From: Stephen Hanna <[email-masked]>
Date: Sat, 16 Oct 2010 17:14:52 -0400

Yuting,

Thanks for your interesting contribution.

Are you familiar with the work of the IETF NEA WG? We are defining protocols for remote assessment of endpoint posture. One of the features called out in our requirements document (RFC 5209) is the Assertion Attribute, reusable evidence of the results of an assessment. We have not yet defined any standard Assertion Attributes but a certificate with your suggested extension or some variant thereof could serve as an Assertion Attribute. Microsoft has implemented a similar concept in their Network Access Protection (NAP) system. They call it a Health Certificate.

Since this work is mainly concerned with endpoint assessment and only peripherally with X.509 certificates, I suggest that you come talk to the NEA Working Group, where we have a lot of experience with endpoint posture assessment. For example, we already have a standard (RFC 5792) for conveying information about endpoint posture (e.g. anti-virus status). This should be beneficial in your efforts. It would ease matters for implementers and avoid the need to reinvent things. If any posture attributes are missing from RFC 5792, we have a well-defined way to add them.

Will you be coming to the IETF 79 meeting in Beijing? If so, I would invite you to present your draft at the NEA WG meeting there and to discuss how your draft can be reconciled with the NEA documents.

Thanks,

Steve Hanna
NEA WG Co-Chair

From: [email-masked] [mailto:[email-masked]] On Behalf Of ???
Sent: Friday, October 15, 2010 6:20 AM
To: [email-masked]
Subject: [pkix] New Draft about X.509extension with Security Information

Dear all,

Abstract:

Best Regards,
Yuting Liu

---

From: 刘玉婷 <[email-masked]>
Date: Wed, 20 Oct 2010 13:00:07 +0800

Hi,all

 1) About the attribute certificates

   We have considered this before.Theoretically ,attribute certification is
more resonable, but we seldom see implementation of PMI in practice.Usually
the server or user does need an PKC, and authorization information in AC
also needs to be bound to an identity .
 From this point of view,we add information as an extension of identity
certification.
   This extension may  increase the workload to CA for the update , which we
have put forward in the draft. Appropriate update mechanism
is under consideration.

2)About Subject Directory Attributes extension

   We think security is a relatively independent and important topic
.It's better to discuss it separately.

3) About verify

 As our draft metioned ,we don't want CA to provide security assessment.
Security information will provided by trust third party.
 And thank you for your suggestion about PA .It is feasible. We will take
that into consideration.

Yuting Liu

2010/10/15 Miller, Timothy J. <[email-masked]>

> 2) What was wrong with stuffing this data in the existing Subject Directory
> Attributes extension?  Why do you need to define a new extension?
>
> -- Tim
>
>
>  ------------------------------
> *From:* [email-masked] [[email-masked]] On Behalf Of 刘玉婷 [
> [email-masked]]
> *Sent:* Friday, October 15, 2010 5:19 AM
> *To:* [email-masked]
> *Subject:* [pkix] New Draft about X.509extension with Security Information
>
>  Dear all,
>

---

From: 刘玉婷 <[email-masked]>
Date: Wed, 20 Oct 2010 13:13:20 +0800

Hi,

   We will attend IETF 79 meeting in Beijing.

   We have read NEA WG documents, and we can discuss the reconcile things
then.It would be our pleasure if we can make any contribution.

   Thanks.

Yuting Liu

2010/10/17 Stephen Hanna <[email-masked]>

> Are you familiar with the work of the IETF NEA WG? We are defining
> protocols for remote assessment of endpoint posture. One of the features
> called out in our requirements document (RFC 5209) is the Assertion
> Attribute, reusable evidence of the results of an assessment. We have not
> yet defined any standard Assertion Attributes but a certificate with your
> suggested extension or some variant thereof could serve as an Assertion
> Attribute. Microsoft has implemented a similar concept in their Network
> Access Protection (NAP) system. They call it a Health Certificate.
>
>
>
> Since this work is mainly concerned with endpoint assessment and only
> peripherally with X.509 certificates, I suggest that you come talk to the
> NEA Working Group, where we have a lot of experience with endpoint posture
> assessment. For example, we already have a standard (RFC 5792) for conveying
> information about endpoint posture (e.g. anti-virus status). This should be
> beneficial in your efforts. It would ease matters for implementers and avoid
> the need to reinvent things. If any posture attributes are missing from RFC
> 5792, we have a well-defined way to add them.
>
>
>
> Will you be coming to the IETF 79 meeting in Beijing? If so, I would invite
> you to present your draft at the NEA WG meeting there and to discuss how
> your draft can be reconciled with the NEA documents.
>
>
>
> Thanks,
>
>
>
> Steve Hanna
>
> NEA WG Co-Chair
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *???
> *Sent:* Friday, October 15, 2010 6:20 AM
> *To:* [email-masked]

---

From: Alan Sill <[email-masked]>
Date: Wed, 20 Oct 2010 07:18:53 +0200

Hi Yuting,

Thanks for your message and notice of your proposed IETF draft, http://www.ietf.org/id/draft-chen-pkix-securityinfo-00.txt

I wish to call to your attention the the VOMS extended attribute certificate format.  This is an extremely popular authorization component in large-scale grids that make use of extended attribute certificates to convey membership, rights and privileges.  Although well established as a working method, it has not up to now been documented as a published standard.

The document for this is currently working its way through review within the Open Grid Forum and is available at the following location.  

  https://forge.gridforum.org/sf/sfmain/do/go/artf6312?nav=1&selectedTab=attachments

I would appreciate you looking at this to determine whether this format for extended AC usage would meet your needs, and how you see this in comparison to the proposed draft you have submitted.  Since essentially all working grids now accept the VOMS extended attribute certificate format, it would seem to me to be more useful to complete documentation and extend the usage of this format into other areas (for example, cloud computing) rather than pursue a new method to approach this essentially solved problem.

I am including in this e-mail a cc to Jens Jensen, the OGF Security Area Director, who may be interested in communicating either privately or publicly with you to understand your use case, and would be personally interested in your response.

Thanks very much,

Alan Sill
OGF VP of Standards

On Oct 20, 2010, at 7:00 AM, 刘玉婷 wrote:

>    We have considered this before.Theoretically ,attribute certification is more resonable, but we seldom see implementation of PMI in practice.Usually the server or user does need an PKC, and authorization information in AC also needs to be bound to an identity .
>  From this point of view,we add information as an extension of identity certification. 
>    This extension may  increase the workload to CA for the update , which we have put forward in the draft. Appropriate update mechanism
> is under consideration.
> 
>    We think security is a relatively independent and important topic .It's better to discuss it separately.
> 
> 3) About verify
> 
>  As our draft metioned ,we don't want CA to provide security assessment. Security information will provided by trust third party.
>  And thank you for your suggestion about PA .It is feasible. We will take that into consideration.
> 
> 
> Yuting Liu
> 
> 
> 
> <ATT00001..txt>

Alan Sill, Ph.D
Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics, TTU

VP of Standards
Open Grid Forum

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: [email-masked]   ph. 806-742-4350  fax 806-742-4358  :
====================================================================

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 20 Oct 2010 09:49:23 -0400

If subject directory attributes is capable of carrying your data (and IMHO from scanning your draft I see no reason why it can't), then I see no reason to adopt *yet another* extension.

-- Tim

________________________________
From: 刘玉婷 [[email-masked]]
Sent: Wednesday, October 20, 2010 12:00 AM
To: Miller, Timothy J.
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] New Draft about X.509extension with Security Information

Hi,all

3) About verify

Yuting Liu

2010/10/15 Miller, Timothy J. <[email-masked]<mailto:[email-masked]>>
(Sorry about the HTML mail, but I can't seem to make OWA bend to my will today.)

2 questions:

-- Tim

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of 刘玉婷 [[email-masked]<mailto:[email-masked]>]
Sent: Friday, October 15, 2010 5:19 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [pkix] New Draft about X.509extension with Security Information

Dear all,

Abstract:

Best Regards,
Yuting Liu

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 22 Oct 2010 11:04:26 -0400

Given the assertion of frequent change in subject security posture, SDA is not advisable.

Attribute certificate or short life health identity certificate using SDA may be the way to go.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
Sent: Wednesday, October 20, 2010 9:49 AM
To: 刘玉婷
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] New Draft about X.509extension with Security Information

-- Tim

Hi,all 

is under consideration.

3) About verify

 

Yuting Liu

2 questions:

-- Tim

Dear all,

It can be accessed at:
http://www.ietf.org/id/draft-chen-pkix-securityinfo-00.txt <http://www.ietf.org/id/draft-chen-pkix-securityinfo-00.txt> 
Any comments are welcome. Thanks.

Abstract:

Best Regards,
Yuting Liu

-- 
Best regards,
刘玉婷 Vivi 

Phone:13488659413

-- 
Best regards,
刘玉婷 Vivi 

Phone:13488659413

---

From: Tom Gindin <[email-masked]>
Date: Fri, 22 Oct 2010 18:30:51 -0400

The current ASN.1 isn't legal anyway.  "otherSecData" needs to be 
changed from "[5...MAX] ANY defined security data " to "SEQUENCE OF 
EXTERNAL" or something like that (you can skip one context-specific tag in 
a sequence).  If it were product data it might be SEQUENCE OF BasicInfo. 
Vivi should also change the parentheses on tags to square brackets - e.g. 
(1) becomes [1].  INTERGER is an evident typo for INTEGER.
        Even if they want to use ANY DEFINED BY X, X should be a field in 
the structure rather than the whole structure.  It's normally an integer 
or an object identifier.  I do think that BasicInfo or a slight extension 
of it is a good idea for a product description syntax (in the general 
form, productType might be IA5String, UTF8String, or OID), although 
manufacturer should use UTF8String instead of IA5String.
        Steve's rule of revocation (the expected time before a certificate 
needs to be revoked decreases with each new independent attribute in the 
certificate) probably applies with special force to product version 
numbers.  A PKC with lots of those in it, whether in a separate extension 
or in SDA, probably won't be accurate for many months - and what good is 
an inaccurate certificate?

                Tom Gindin

P.S. - I know that Steve's rule is usually quoted with an actual function, 
but the formulation above doesn't state more than we actually know.  You 
can't call it "Kent's rule of revocation" because searches will pick up 
Chancellor Kent on contract law.

From:
"Santosh Chokhani" <[email-masked]>
To:
"Miller, Timothy J." <[email-masked]>, 刘玉婷 <[email-masked]>
Cc:
[email-masked], [email-masked], [email-masked], 
[email-masked]
Date:
10/22/2010 11:05 AM
Subject:
Re: [pkix] New Draft about X.509extension with Security Information
Sent by:
[email-masked]

Given the assertion of frequent change in subject security posture, SDA is 
not advisable.
 
Attribute certificate or short life health identity certificate using SDA 
may be the way to go.
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Miller, Timothy J.
Sent: Wednesday, October 20, 2010 9:49 AM
To: 刘玉婷
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject: Re: [pkix] New Draft about X.509extension with Security 
Information
 
If subject directory attributes is capable of carrying your data (and IMHO 
from scanning your draft I see no reason why it can't), then I see no 
reason to adopt *yet another* extension.
 
-- Tim

From: 刘玉婷 [[email-masked]]
Sent: Wednesday, October 20, 2010 12:00 AM
To: Miller, Timothy J.
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject: Re: [pkix] New Draft about X.509extension with Security 
Information
Hi,all 

   We have considered this before.Theoretically ,attribute certification 
is more resonable, but we seldom see implementation of PMI in 
practice.Usually the server or user does need an PKC, and authorization 
information in AC also needs to be bound to an identity .
 From this point of view,we add information as an extension of identity 
certification. 
   This extension may  increase the workload to CA for the update , which 
we have put forward in the draft. Appropriate update mechanism
is under consideration.

   We think security is a relatively independent and important topic .It's 
better to discuss it separately.
 
3) About verify

Yuting Liu

2010/10/15 Miller, Timothy J. <[email-masked]>
(Sorry about the HTML mail, but I can't seem to make OWA bend to my will 
today.)
 
2 questions:

2) What was wrong with stuffing this data in the existing Subject 
Directory Attributes extension?  Why do you need to define a new 
extension?
 
-- Tim

From: [email-masked] [[email-masked]] On Behalf Of 刘玉婷 [
[email-masked]]
Sent: Friday, October 15, 2010 5:19 AM
To: [email-masked]
Subject: [pkix] New Draft about X.509extension with Security Information
Dear all,

Abstract:

Best Regards,
Yuting Liu

-- 
Best regards,
刘玉婷 Vivi 
Phone:13488659413
Email: [email-masked]
MINE | Mobile LIfe and New Media LAB  
BUPT | Beijing University of Posts and Telecommunications
 _______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Alan Sill <[email-masked]>
Date: Sat, 23 Oct 2010 00:58:22 +0200

Good observation, Tom.  However, I believe that we might be getting lost in the details before understanding the problem to be solved.

I really think that we need to understand the use case for the creation and presentation of this information by a given server or client machine before thinking further about how it would be best for the proponents to proceed.  let me explain my earlier reference to extended attribute certificates and see if we can reason out how such a certificate (most likely through a proxy) would be used.

One can assume that the certification of a machine as having passed the relevant tests as listed in the structure proposed would not be able to sign the certificate only with its own private key.  A machine that had been compromised could not be viewed as a trusted signer of such assertions.  The only thing that I can imagine that would make sense in a security context would be to allow a client or server to run an executable that had been signed by an external trusted source, and not to be able to view or alter, without destroying the internally generated signature, the output of such a trusted program.  In some possible use cases, it would perhaps be best if in fact it were not possible for anyone except the signer of the original diagnostic program to be able to read its output; otherwise security holes of the nature of "this machine has not been updated to protect against known exploit X" would arise.

So without knowing any more details of the proposed implementation, it can be inferred that a trusted external source would sign the diagnostic executable, and that the period of validity of the resulting timestamp would be set by the external source.  That leads still to some instances of the type of "not-certified-against-X" timestamp security information leakage mentioned above, but we can leave the details of that issue to the proponents to work out.  What is essential to understand is that a third machine, separate from the one providing the service and the one trying to consume it, is required.  (It is possible to imagine collapsing the source of the diagnostic probe to one side of this transaction or the other, but hard to see how this can be made secure against exploit probing of the sort that I mentioned above without a third verification server being involved, most likely run by a very trusted service.)

This leads naturally to the VOMS model, which is a completely fleshed-out working example that has widespread usage in such settings, in this case to establish authorization attributes for membership, groups and/or roles in a virtual organization and presented either by an x.509 extended attribute certificate as decoration to a proxy certificate, or in some use cases as an alternative, as direct SAML assertions.  This model has exactly the characteristics needed to perform checks of the sort mentioned above: an external proxy with a period of validity can be generated and used to sign and optionally to encrypt a diagnostic executable program, which can be transmitted to the system under test and can, also optionally, return encrypted output.  A given user or process can be granted permission to run, but because of the above features, optionally not to view or alter the output of the diagnostic check, and the results returned to the highly trusted and cryptographically identified diagnostic service.  In any case, regardless of the latter details, the certification can be presented as an extended attribute certificate valid to the end of the period of validity of the original proxy.

There are even fields in the current VOMS format that could be used for this purpose.  Regardless of whether this particular format is used, it seems to me that this model is a better match to the projected use cases that can be imagined (absent a reply from the original proponents) for the use of this proposed extension.  In fact, I do not see at all why definition of a new extension is required.

Alan

Alan Sill, Ph.D

VP of Standards
Open Grid Forum

---

From: 刘玉婷 <[email-masked]>
Date: Tue, 26 Oct 2010 10:00:29 +0800

Hi , Tom
      Thank you for your comments on syntax and semantics.I will correct and
make them clearer.

Yuting

2010/10/23 Tom Gindin <[email-masked]>