Subject: [pkix] Self-signed cert wording in draft-ietf-pkix-rfc5280-clarifications-06.txt

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jul 2012 17:06:15 -0700

The very latest wording:

|  In some cases, a self-signed certificate that does not contain a
|  BasicConstraints extension (and thus is implicitly an EE certificate)
|  is used to convey a public key. Such a certificate (i.e., a self-
|  signed certificate not marked as a CA certificate) is not compatible
|  with the path validation rules described in Section 6, or the
|  definitions in the paragraph above. This document RECOMMENDS that
|  self-signed certificates used to convey trust anchor data be marked
|  (see Section 4.2.1.9) as CA certificates, but acknowledges that this
|  convention is often not adopted in practice. Other uses of self-
|  signed EE certificates are outside the scope of this specification.

This seems fine to me, and solves the problem that we encountered in the DANE WG. A slight proposed rewording for clarity with no semantic changes:

A self-signed certificate that does not contain a BasicConstraints
extension is implicitly an EE certificate, and is explicitly not
marked as a CA certificate. Such a certificate is used to convey a
public key in some environments. Such a certificate is not
compatible wth the path validation ...

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 24 Jul 2012 17:14:33 -0700

> compatible wth the path validation ...

This text looks clearer to me.

--Richard

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 25 Jul 2012 10:12:39 -0400

This text in the clarification as well as Paul's modifications are self-contradictory and inconsistent with 5280.  I propose the following replacement:

| This document RECOMMENDS that  
| self-signed certificates used to convey trust anchor data be marked  
| (see Section 4.2.1.9) as CA certificates, but acknowledges that this  
| convention is sometimes not adopted in practice. Uses of self-  
| signed EE certificates are outside the scope of this specification.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Tuesday, July 24, 2012 8:06 PM
To: IETF PKIX
Subject: [pkix] Self-signed cert wording in draft-ietf-pkix-rfc5280-clarifications-06.txt

The very latest wording:

A self-signed certificate that does not contain a BasicConstraints extension is implicitly an EE certificate, and is explicitly not marked as a CA certificate. Such a certificate is used to convey a public key in some environments. Such a certificate is not compatible wth the path validation ...

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Jul 2012 08:08:01 -0700

On Jul 25, 2012, at 7:12 AM, Santosh Chokhani wrote:

> This text in the clarification as well as Paul's modifications are self-contradictory and inconsistent with 5280.  

You jumbled three assertions in that sentence. Separating them out:

- Which two statements in the clarifications draft contradict each other?

- Which two statements in my proposed wording contradict each other?

- Of course they are "inconsistent with 5280": this draft updates RFC 5280. 

> I propose the following replacement:
> 

You are proposing to remove the text that actually describes the certificates we are discussing. Serious question: in what way does removing that description *help* the reader of the document?

Replacing "often" for "sometimes" doesn't indicate a contradiction; your guess as the the frequency is as good as anyone else's.

--Paul Hoffman

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 25 Jul 2012 11:33:32 -0400

Paul,

Before I made my posted, I word searched 5280 for "self signed" and "self-signed" and I found that aside from C.2, self-signed was used only for starting certification path validation context.  So, simply stating that its use for EE is outside the scope of the standard seems the right thing. 

As to contradiction:
"Such a certificate (i.e., a self-
|  signed certificate not marked as a CA certificate) is not compatible
|  with the path validation rules described in Section 6, or the
|  definitions in the paragraph above."  is incorrect.  Section 6 is fine with a TA that is not marked as a CA certificate.

Also, stating "other uses of self-signed EE" implies you have discussed at least one use.  Neither the RFC nor the clarification identify what that use is.  Do you mean using EE certificate as trust anchor?

"sometimes" "often" change was made to give a realistic impression of the frequency.

Finally, what problem not having this text or the text I propose does not solve.  If you tell me that, maybe we can converge on better wording.

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2012 11:08 AM
To: Santosh Chokhani
Cc: IETF PKIX
Subject: Re: [pkix] Self-signed cert wording in draft-ietf-pkix-rfc5280-clarifications-06.txt

--Paul Hoffman

---

From: Russ Housley <[email-masked]>
Date: Wed, 25 Jul 2012 13:31:52 -0400

There are two cases, and I think that the confusion is that people have tried to handle them in one paragraph.  I think we need a separate paragraph for each case.

(1) the self-signed certificate is providing a trust anchor that will be used on path validation.

(2) the self-signed certificate is providing a trusted end-entity public key, and no path validation is needed.

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 25 Jul 2012 14:50:58 -0400

Russ,

I would think that case 2 can be handled in Section 6.1.1 by add the following "When n = 0, the information in the trust anchor can be used directly without path validation algorithm presented in this section"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Wednesday, July 25, 2012 1:32 PM
To: IETF PKIX
Subject: Re: [pkix] Self-signed cert wording in draft-ietf-pkix-rfc5280-clarifications-06.txt

Russ

On Jul 25, 2012, at 10:12 AM, Santosh Chokhani wrote:

> Subject: [pkix] Self-signed cert wording in 
> draft-ietf-pkix-rfc5280-clarifications-06.txt
> 
> The very latest wording:
> 
> | BasicConstraints extension (and thus is implicitly an EE 
> | certificate) is used to convey a public key. Such a certificate 
> | (i.e., a self- signed certificate not marked as a CA certificate) is 
> | not compatible with the path validation rules described in Section 
> | 6, or the definitions in the paragraph above. This document 
> | RECOMMENDS that self-signed certificates used to convey trust anchor 
> | data be marked (see Section 4.2.1.9) as CA certificates, but 
> | acknowledges that this convention is often not adopted in practice. 
> | Other uses of self- signed EE certificates are outside the scope of this specification.
>

---

From: Tom Gindin <[email-masked]>
Date: Wed, 25 Jul 2012 21:44:47 -0400

Here's mine: Any self-signed certificate intended to convey trust 
anchor data SHOULD contain a basic constraints extension suitable for a CA 
(see Section 4.2.1.9).  A self-signed certificate intended for direct 
trust as an EE SHOULD contain a KeyUsage extension without keyCertSign.
        The rules for classifying a self-signed certificate after a user 
decides to trust it follow from this, but they're out of scope.

Tom Gindin

From:   Santosh Chokhani <[email-masked]>
To:     Russ Housley <[email-masked]>, IETF PKIX <[email-masked]>, 
Date:   07/25/2012 02:53 PM
Subject:        Re: [pkix] Self-signed cert     wording in 
draft-ietf-pkix-rfc5280-clarifications-06.txt
Sent by:        [email-masked]

Russ,

I would think that case 2 can be handled in Section 6.1.1 by add the 
following "When n = 0, the information in the trust anchor can be used 
directly without path validation algorithm presented in this section"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Russ Housley
Sent: Wednesday, July 25, 2012 1:32 PM
To: IETF PKIX
Subject: Re: [pkix] Self-signed cert wording in 
draft-ietf-pkix-rfc5280-clarifications-06.txt

There are two cases, and I think that the confusion is that people have 
tried to handle them in one paragraph.  I think we need a separate 
paragraph for each case.

(1) the self-signed certificate is providing a trust anchor that will be 
used on path validation.

(2) the self-signed certificate is providing a trusted end-entity public 
key, and no path validation is needed.

Russ

On Jul 25, 2012, at 10:12 AM, Santosh Chokhani wrote:

> This text in the clarification as well as Paul's modifications are 
self-contradictory and inconsistent with 5280.  I propose the following 
replacement:
> This seems fine to me, and solves the problem that we encountered in the 
> A self-signed certificate that does not contain a BasicConstraints 
extension is implicitly an EE certificate, and is explicitly not marked as 
a CA certificate. Such a certificate is used to convey a public key in 
some environments. Such a certificate is not compatible wth the path 
validation ...

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 26 Jul 2012 11:01:03 -0400

Paul,

While this draft updates RFC 5280, it does not make changes to
Section 6 that are relevant to this discussion.  The draft say
that use of a self-signed certificate that does not contain a
BasicConstraints extension as the source of trust anchor
information "is not compatible with the path validation rules
described in Section 6."  Yet, there is no basis for that
assertion.  RFC 5280 simply says that "trust anchor information
may be provided to the path processing procedure in the form of a
self-signed certificate."  While RFC 5280 requires conforming CAs
to include certain information, including a BasicConstraints
extension, in self-signed certificates, those requirements are
distinct from the path validation rules in Section 6.  Russ
Housley also noted this:

On 07/14/2012 03:28 PM, Russ Housley
wrote:

The path validation algorithm in Section 6 of RFC 5280 starts with a trust anchor, and self-signed certificates are a convenient way to distribute such trust anchors. However, RFC 5280 does not, and should not, impose any particular approach to trust anchor distribution. This proposed clarification RECOMMENDS that the self-signed certificate include the basic constraints extension with the CA-bit set. Nothing in Section 6 justifies this recommendation.

In fact, Section 6 is quite clear to say that it does not impose any requirements on self-signed certificates that are used to distribute a trust anchor:

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
(Section 6.1.1).

Russ

The text in the draft is also inconsistent with RFC 5280 when it
says:

This document RECOMMENDS that self-signed certificates
used to convey trust anchor data be marked (see Section 4.2.1.9)
as CA certificates

While not entirely clear, this statement seems to be directed at
the issuers of the certificates, and Section 4.2.1.9 already says
that conforming CAs MUST include a BasicConstraints extension.

In fact that paragraph in Section 4.2.1.9 says:

Conforming CAs MUST include this extension in all CA
certificates that contain public keys used to validate digital
signatures on certificates and MUST mark the extension as
critical in such certificates.  This extension MAY appear as
a critical or non-critical extension in CA certificates
that contain public keys used exclusively for purposes other
than validating digital signatures on certificates.  Such CA
certificates include ones that contain public keys used
exclusively for validating digital signatures on CRLs and ones
that contain key management public keys used with certificate
enrollment protocols.

So this paragraph, which also appeared in RFC 3280, refers to CA
certificates that do not contain a BasicConstraints extension.
So, the text in the draft is inconsistent with this when it refers
to any certificate that does not contain a BasicConstraints
extension as an EE certificate.  And, as I noted earlier, it is
also inconsistent with X.509, since X.509 defines an EE
certificate as a certificate issued to an end-entity and defines
an end entity as a certificate subject that uses its private key
for purposes other than signing certificates.  Meanwhile it
defines a CA as an authority trusted by one or more users to
create and assigned public-key certificates.  So, if the public
key in the self-signed certificate is used as a trust anchor for
certification path validation, then the issuer of the certificate
is a CA and not an EE and certificate is not an EE certificate.

I also agree with Santosh that it is inappropriate to state that
something "is often not adopted in practice" if "your guess as the
the frequency is as good as anyone else's."  Given that we know of
self-signed certificate used to convey trust anchor information
that do not include BasicContraints extensions, we can say that
the inclusion of the extension is "sometimes not adopted in
practice" or is "not always adopted in practice," but let's not
say "often" unless we know that it's often.

Dave

On 07/25/2012 11:08 AM, Paul Hoffman wrote:

--Paul Hoffman

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 26 Jul 2012 11:42:51 -0400

On 07/25/2012 01:31 PM, Russ Housley
wrote:

Russ,

I thought case (1) was already adequately covered in RFC 5280.
Section 4 of RFC 5280 imposes requirements on conforming CAs (e.g.,
inclusion of BasicConstraints, keyUsage, and subjectKeyIdentifier
extensions) and Section 6 discusses their use as the source of trust
anchor information (and, optionally, using information the in
certificates as the basis for choosing values for the other inputs
to the path validation algorithm).

Case (2) is the one that I tried to address in the -04 draft when I
was tasked to discuss self-signed EE certificates:

In some cases, a self-signed certificate is used to
convey a public key that is not intended to be used to begin
certification paths.  Such a self-signed certificate is commonly
referred to as a self-signed end-entity certificate.  While
Section 6.2 notes that implementations are not required to process
extensions that appear in self-signed certificates, self-signed
end-entity certificates SHOULD NOT include a BasicConstraints
extension that asserts the cA boolean.  The use of self-signed
certificates for purposes other than to convey a public key for
use to begin certification paths is outside the scope of this
specification.

As I noted in my previous message, X.509 defines an end-entity
certificate as a certificate issued to an entity that uses its
private key for purposes other than signing certificates, and so
that is what the -04 draft addresses: self-signed certificates in
which the subject public key is used for purposes other than
verifying signatures on certificates.  Prior to writing this text, I
also read some of the messages on the DANE listed that people
referred me to and this seemed to be the topic.

As someone else noted, part of the problem we're having it that
there has been no clear statement of what the topic is that needs to
be addressed.  We've been told that it is "self-signed EE
certificates" but apparently some people interpret that to mean
self-signed certificates that do not contain a BasicConstraints
extension, even though that is inconsistent with both X.509 and RFC
5280.  We've heard people say about different pieces of text that
has been proposed that it either "solves the problem that we
encountered in the DANE WG" or "is not the subject of this text,"
but we haven't been given a clear statement of what the text is
supposed to address.  When Steve Kent responded to a comment on the
list by saying that that "is not the subject of this text," I asked
him to then explain what was the subject of the text
(http://www.ietf.org/mail-archive/web/pkix/current/msg30902.html),
but he never responded.  How can the WG come to consensus on text
that "solves the problem that we encountered in the DANE WG" if no
one can clearly explain to this WG what that problem was?

Dave

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Jul 2012 11:25:33 -0700

The comments from David and Santosh bring us around yet again on the difference between:
a) a CA certificate
b) a certificate that can be used as a trust anchor
c) a self-issued certificate that is used only to convey a public key

My reading of RFC 5280 is that (a) and (b) are sometimes used interchangeably, and sometimes not. This sloppiness might or might not be able to be cleared up through WG consensus on a document such as draft-ietf-pkix-rfc5280-clarifications.

Regardless of clarifying (a) and (b), the only thing I care about for draft-ietf-pkix-rfc5280-clarifications is making it clear that (c) is allowed by this update. I do not believe that either of Santosh's suggestions for new wording for this draft, regardless of whether or not they are correct, make this last point clear.

--Paul Hoffman

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 26 Jul 2012 14:31:35 -0400

Paul,

Why does not the following addition to Section 6.1.1 not do the trick?

"When n = 0, the information in the trust anchor can be used directly without invoking the path validation algorithm presented in this section"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Thursday, July 26, 2012 2:26 PM
To: IETF PKIX
Subject: Re: [pkix] Self-signed cert wording in draft-ietf-pkix-rfc5280-clarifications-06.txt

--Paul Hoffman

---

From: "Art Allison" <[email-masked]>
Date: Thu, 26 Jul 2012 14:33:28 -0400

Newbie here.. can someone explain how a 'clarifications' document can be true to that label when it prohibits a previously optional coding? <i.e., is technically not backwards compatible>?

I am not currently questioning the decision to prohibit that option... as I do not know the impact or lack thereof... just the characterization... this seems to be a revision at least.

Art

Art Allison 
Senior Director Advanced Engineering, Technology 
National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418
Fax  202 775 4981 
www.nab.org 
Advocacy  Education  Innovation 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Thursday, July 26, 2012 2:26 PM
To: IETF PKIX
Subject: Re: [pkix] Self-signed cert wording indraft-ietf-pkix-rfc5280-clarifications-06.txt

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Jul 2012 12:25:28 -0700

> "When n = 0, the information in the trust anchor can be used directly without invoking the path validation algorithm presented in this section"

Because it does not mention that the self-issued certificate is used only to convey a public key, nor does it even say "self-issued certificate". *You* might understand that rule, but this document is also supposed to clarify for PKIX non-experts.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Jul 2012 12:29:01 -0700

> Newbie here.. can someone explain how a 'clarifications' document can be true to that label when it prohibits a previously optional coding? <i.e., is technically not backwards compatible>?

"clarifications" appears in the file name, but not the title of the actual document. (The file name will disappear when this is published as an RFC.)
        Updates to the Internet X.509 Public Key Infrastructure
       Certificate and Certificate Revocation List (CRL) Profile 
The first sentence of the Abstract drives home the "updates" point:
   This document updates RFC 5280, the Internet X.509 Public Key
   Infrastructure Certificate and Certificate Revocation List (CRL)
   Profile.

--Paul Hoffman

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 26 Jul 2012 15:30:55 -0400

Paul,

I assume we are talking about "self-signed" and not "self-issued"?

Why is it important to say it is used to convey a public key only?  What else is a certificate used for?  If you mean one should not being a path using this certificate as a trust anchor, there is nothing in the certificate that prevents it.   This is all in the user context and outside the scope of 5280.  User decide what each public key they trust for.  5280 does not address that.

If you want to make a claim to clarify self-signed, the following revision will help"

"When n = 0, the information in the trust anchor (e.g., a self-signed certificate) can be used directly without invoking the path validation algorithm presented in this section"

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Thursday, July 26, 2012 3:25 PM
To: Santosh Chokhani
Cc: IETF PKIX
Subject: Re: [pkix] Self-signed cert wording in draft-ietf-pkix-rfc5280-clarifications-06.txt

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Jul 2012 12:40:00 -0700

> I assume we are talking about "self-signed" and not "self-issued"?

That is a bad assumption. For the purpose of simply conveying a public key, a certificate might be either self-signed or self-issued: it is irrelevant.

> Why is it important to say it is used to convey a public key only?  

Because that's what the use case I (and many others) care about here. If you don't care about it, that's fine, but that doesn't make our use case go away.

> What else is a certificate used for?  

Associating a public key with an identifier. Saying who authenticated the association. The rest of the glop in RFC 5280.

> If you mean one should not being a path using this certificate as a trust anchor, there is nothing in the certificate that prevents it.   

Wait wait wait. *You're* the one who was trying to tie this into the Section 6.1 wording, not me, remember?

> This is all in the user context and outside the scope of 5280.  User decide what each public key they trust for.  5280 does not address that.

Others might disagree.

> "When n = 0, the information in the trust anchor (e.g., a self-signed certificate) can be used directly without invoking the path validation algorithm presented in this section"

This does not help, given its location in the spec.

--Paul Hoffman

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 26 Jul 2012 15:51:54 -0400

Paul,

See in-line.

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Thursday, July 26, 2012 3:40 PM
To: Santosh Chokhani
Cc: IETF PKIX
Subject: Re: [pkix] Self-signed cert wording in draft-ietf-pkix-rfc5280-clarifications-06.txt

That is a bad assumption. For the purpose of simply conveying a public key, a certificate might be either self-signed or self-issued: it is irrelevant.
[Santosh] It is not irrelevant.  Self-signed means you implicitly trust the public key.  The clarification you supported was addressing self-signed only

Because that's what the use case I (and many others) care about here. If you don't care about it, that's fine, but that doesn't make our use case go away.
[Santosh] My point is that all X.509 public key certificates are used to convey public key and hence saying that is unnecessary.

Associating a public key with an identifier. Saying who authenticated the association. The rest of the glop in RFC 5280.
[Santosh] That goes without saying.

Wait wait wait. *You're* the one who was trying to tie this into the Section 6.1 wording, not me, remember?
[Santosh] If you use 5280 concept and trust a self-signed certificate, that public key is unconstrained from 5280 viewpoint.

> This is all in the user context and outside the scope of 5280.  User decide what each public key they trust for.  5280 does not address that.

Others might disagree.
[Santosh] Tell me where in 5280 they scope trusted public key.

This does not help, given its location in the spec.
[Santosh] So, the text is fine except for the location?  If so, put it in 6.1.1 and add the following to a location of your choice:

"The public key in a trust anchor (e.g., a self-signed certificate) can be used directly by the relying party for their intended purpose without invoking the path validation algorithm presented in Section 6."

--Paul Hoffman

---

From: [email-masked] (Martin Rex)
Date: Thu, 26 Jul 2012 22:18:10 +0200 (CEST)

Paul Hoffman wrote:
> My reading of RFC 5280 is that (a) and (b) are sometimes used
> interchangeably, and sometimes not.  This sloppiness might or
> might not be able to be cleared up through WG consensus on a
> document such as draft-ietf-pkix-rfc5280-clarifications.

While it should be possible with reasonable implementations of PKIX
to make _any_ CA certficate a trust anchor, there is a non-marginal
amount of broken PKI software in the installed base where trying
to make a non-self-signed CA certificate a trust anchor will not
give you the expected result, in particular if you decide to make
a non-self-signed CA cert a trust anchor due to the lack of a rootCA cert.

> 
> Regardless of clarifying (a) and (b),

What exactly do you want to have clarified for (b): what rfc5280 intended
to mean (and imply), or what kind of unexpected interop problems exist
in the installed base?  I believe that doing the former without the
latter would widen the gap between expectations and installed base.

>
> the only thing I care about for draft-ietf-pkix-rfc5280-clarifications
> is making it clear that (c) is allowed by this update.

But you do realize that this has always been allowed by rfc5280 and its
predecessors?  The X.509 spec is clearer by spelling out explicitly that
self-signed non-CA certificates are outside the scope of the X.509 spec.

(I quoted this before from X.509 11/2008)

  3.4.61  self-signed certificate

    [...]

    NOTE Use of self-issued certificates and self-signed certificates
    issued by other than CAs are outside the scope of this
    Recommendation | International Standard.

I believe that the most honest reaction would be to spell out something
similar in rfc5280-clarifications.

All of the requirements on certificate (attributes) described in
rfc5280 Section 4 and Section 5 apply explicitly to "certificates issued
by conforming CA".

And the certificate path validation described in Section 6 also applies
only to certificates issued by a CA (whose public key&name is used as
trust anchor to verify the signature on a certification path.

>From the top of my head I can not think of anything in rfc5280 that can
be said to apply to a self-signed certificate created by a non-CA entity.

I know pretty well that most if not all PKI implementations can deal
with self-signed certificates created by non-CA entities, and their use
is actually pretty common.

It would probably be sensible to write an information document seperate
from PKIX to describe how self-signed certificates created by non-CA
entities are typically used in the installed base with PKI(X)
implementations.  Adding a few words to rfc5280 that create the
impression "PKIX doesn't mind when you use self-signed non-CA certs",
may create unjustified expectations about their usefulness and
(lack of) interference with the normal PKIX machinery.  And I had the
impression that there are folks on the pkix mailing list who strongly
dislike these certs...  ;-)

-Martin

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 26 Jul 2012 16:35:27 -0400

Martin Rex wrote:
>>   a) ...
>>   b) ...
>> [...] the only thing I care about for draft-ietf-pkix-rfc5280-clarifications

+1

Regards,

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691