Subject: Re: [mile] Keeping the HashData@valid attribute?

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 9 Mar 2015 11:39:28 +0900

Hello Roman, Panos, and all,

I do not have any particular opinion on this, but let me ask you one
clarification question to deepen my understanding.

Let us consider a scenario as follows: an incident has occurred by
downloading a malware from a malicious site that provides an invalid
certificate.

How can we describe the above event using IODEF?

I use IODEF for the purpose of sharing security information and asset
information between internal entities (software), though our activity is a
research-oriented one (that pursues security automation).

It would be nice to be able to convey assorted security-related information,
including invalid certificates by some means.

Regards,

Take

2015-03-06 4:48 GMT+09:00 Panos Kampanakis (pkampana) <[email-masked]>:
> Indeed each IODEF implementation can check the validity based on the ds:
X509Data field. So, +1 for dropping it also.
> Panos
>
> -----Original Message-----
> From: mile [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
> Sent: Friday, February 27, 2015 4:39 PM
> To: [email-masked]
> Subject: [mile] Keeping the HashData@valid attribute?
>
> Hello!
>
> The -10 version of 5070bis introduced rewrote the existing ambiguous text
to address Issue #29 [1], clarifying the scope of HashData@valid.  This new
text in Section 3.27 is as follows:
>
>    valid
>       Optional.  Indicates whether a given certificate has a valid
>       signature.  An invalid signature may be due to an invalid
>       certificate chain, a signature not decoding properly, or a
>       certificate contents not matching the hash.
>
>       1.  yes.  The certificate is valid.
>       2.  no.  The certificate is not valid.
>
> At the Honolulu meeting this change prompted discussion summarized as
follows in the meeting minutes [2]:
>
> As to the HashData@valid attribute:
> Q1: (Jim Shot) Why is it there?
> A: (Roman Danyliw) Not sure.
> A: (Jim Shot) Perhaps it should be removed
> A: (Chris Inacio) Might be useful in pDNS because capturing DNS signatures
is expensive and wasteful
> A: (Paul Hoffman) It's an "invalid bit".  Get rid of it.
> A: (David Waltermire) It was intended to convey that a certificate was
found to be invalid.  Concur to drop.
> A: A question as to whether to drop this attribute will be put on the
list.
>
> There has been limited discussion of this issue on the mailing list as
well [3] which requested a better definition.
>
> What does the group want to do?  Could advocacy for keeping the @valid
attribute please respond to the list with better language.  For those that
think we should remove it, can you also let your perspective be known on the
list.
>
> Roman
>
> [1] http://trac.tools.ietf.org/wg/mile/trac/ticket/29
> [2] http://www.ietf.org/proceedings/91/minutes/minutes-91-mile
> [3] http://www.ietf.org/mail-archive/web/mile/current/msg01161.html
>
>
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

-- 
--
Takeshi Takahashi, Ph.D.
+81 80 3490 2971
http://www.taketaka.com/

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 12 Mar 2015 03:15:31 +0000

What I had in mind is that the certificate can be described in IODEF and the validity can be verified by the IODEF consumer. The consumer might trust different cert than the IODEF author.
Panos

From: Takeshi Takahashi [mailto:[email-masked]]
Sent: Sunday, March 08, 2015 10:39 PM
To: Roman D. Danyliw; Panos Kampanakis (pkampana); [email-masked]
Subject: Re: [mile] Keeping the HashData@valid attribute?

I do not have any particular opinion on this, but let me ask you one clarification question to deepen my understanding.

Let us consider a scenario as follows: an incident has occurred by downloading a malware from a malicious site that provides an invalid certificate.
How can we describe the above event using IODEF?

I use IODEF for the purpose of sharing security information and asset information between internal entities (software), though our activity is a research-oriented one (that pursues security automation).
It would be nice to be able to convey assorted security-related information, including invalid certificates by some means.

Regards,
Take

2015-03-06 4:48 GMT+09:00 Panos Kampanakis (pkampana) <[email-masked]<mailto:[email-masked]>>:
> Indeed each IODEF implementation can check the validity based on the ds: X509Data field. So, +1 for dropping it also.
> Panos
>
> To: [email-masked]<mailto:[email-masked]>
> The -10 version of 5070bis introduced rewrote the existing ambiguous text to address Issue #29 [1], clarifying the scope of HashData@valid.  This new text in Section 3.27 is as follows:
>
>    valid
> At the Honolulu meeting this change prompted discussion summarized as follows in the meeting minutes [2]:
>
> A: (Chris Inacio) Might be useful in pDNS because capturing DNS signatures is expensive and wasteful
> A: (David Waltermire) It was intended to convey that a certificate was found to be invalid.  Concur to drop.
> A: A question as to whether to drop this attribute will be put on the list.
>
> There has been limited discussion of this issue on the mailing list as well [3] which requested a better definition.
>
> What does the group want to do?  Could advocacy for keeping the @valid attribute please respond to the list with better language.  For those that think we should remove it, can you also let your perspective be known on the list.
>
> Roman
>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--
--
Takeshi Takahashi, Ph.D.
+81 80 3490 2971
http://www.taketaka.com/